A PM opening your review at 4:45 on a Friday has about two minutes before the next meeting. If each item is a wall of text with three complaints tangled together, they skim it, promise to look later, and it dies in a tab. The fix is a fixed shape for every item so the reader always knows where to look.
The structure below is three parts per item: one screenshot, one observation, one suggested next step. Nothing else. It works whether the receiver is a PM triaging a build, a developer picking up a ticket, or a coding agent reading the exported markdown. Copy it, fill it in as you walk the screen, and adjust the pieces described here when your situation calls for it.
The three parts of one review item
Keep every item to the same skeleton. The value is not the individual parts, it is the repetition: once the reader learns the shape on item one, every item after that reads faster.
- One screenshot. A single captured still of the exact spot in question, cropped to the area that matters. One screen, one concern. If two problems sit on the same screen, that is two items, not one.
- One observation. What you see and why it is a problem, stated plainly. Not a fix, not a feeling. "The Save button stays disabled after I fill every required field" is an observation. "Save is broken" is not.
- One suggested next step. What you think should happen, phrased so the receiver can accept, reject, or ask a question. "Enable Save once email and password both validate" gives them something to act on or push back against.
That third part is what separates a report someone fixes from a report someone files. A running product review that ends in something the team can act on lives or dies on whether each item names a next step instead of leaving the reader to invent one.
Filling the template as you walk the screen
Do not write the template in a doc and paste screenshots in afterward. Capture while you are looking at the live product, because the observation is sharpest in the moment you notice it.
In Cobalt Capture that flow is one tab. Click Capture screen, share the window, drag a rectangle around the area you mean, and the still becomes an item. Type your observation, or dictate it with the browser's built-in speech recognition if you are in Chrome or Edge. Add the suggested next step in the same comment. Move to the next screen and repeat. There is no install, no extension, and no signup, so a reviewer who has never seen the tool can be productive on the first screen.
When the exact spot is ambiguous, drop a numbered pin on the screenshot and refer to it in the observation: "Pin 1 shows the field that clears itself." Pinning saves a paragraph of "the third input from the top on the left." There is more on pinning the exact spot a reviewer means if your items keep getting misread.
When to bend each part
The skeleton is fixed, but a few situations call for adjusting one of the three parts.
Drop the screenshot for a whole-flow note
Some observations are not about a single screen. "The checkout takes six steps and two of them ask for the same address" is a flow-level point. Make that a free-floating comment with no screenshot. Keep the observation and next step; skip the still. Most items should still carry a screenshot, but forcing one onto a structural note just adds noise.
Soften the next step when you are not the decider
If you are reviewing someone else's product and the call is theirs, phrase the next step as an option, not a directive: "Consider enabling Save on validation, or tell me why it is disabled on purpose." That invites the reply that resolves the item. When the receiver disagrees, they can post a comment on that specific item and you can mark it resolved without a separate thread. This is closer to how a design review on the built product runs than a bug list.
Split the observation when severity varies
Do not bury a blocker inside a paragraph of nitpicks. If one screen has a crash and a spacing issue, that is two items. Lead the observation with the severity in plain words: "Blocker:" or "Minor:" so the PM can triage by scanning the first word of each item.
What the receiver gets
Publish the review and it saves to a short public link anyone can open, no login required. The same review is available as a PDF, a Word document, and clean markdown. A PM reads the link, a stakeholder gets the PDF, and if the work goes to a coding agent, the markdown export drops in as an instruction the agent can parse. One review, several audiences, no reformatting.
Because the structure is consistent, the receiver can also work through it in order and mark each item resolved as they go, which turns a review into a checklist without needing a bug tracker. If your team runs this often, save a blank version of the three-part item as a starting point. A reusable template anyone on the team can copy beats re-explaining the format every round, and reviewers stop guessing how much detail you want.
Open a new review, capture your first screen, and write the three parts on it. The two-minute read is a property of the structure, not the length. Keep every item the same shape and the PM never has to hunt for the point.