A diff tells you the button moved 8 pixels. It does not tell you the button now overlaps the price on a 1280px viewport. Reviewers who only read the diff miss the things that only show up when the branch is running. The fix is to pull the branch, look at the rendered result, and attach what you see to the PR. Done badly, that means a folder of unlabeled PNGs and a comment that says "looks off." Done well, the author opens one link and knows the viewport, the element, and the change you want.
Five practices that hold up when someone actually has to act on your review.
Capture the rendered branch, not the diff
The point of a visual review is to catch what the code does not show. Run the branch locally or on a preview deploy, then capture the screen at the viewport where the problem appears. A comment like "the modal header wraps at 768px" is worth more than three lines of inline diff annotation, because the author can reproduce it in one resize.
The failure mode: you review the diff in isolation, approve it, and the regression ships. CSS changes are the worst offenders. A flexbox tweak that reads fine in the diff can shove a label off-screen on mobile, and nobody sees it until a user files a ticket. Looking at the running build is the whole reason to add screenshots to a pull request review at all.
Tie each screenshot to one specific change
One screenshot, one observation. If a single image carries five problems, the author has to read your comment five times and cross-reference each point against the picture. Split them. With Cobalt Capture, each captured screen becomes its own item with its own comment, so "the spacing under the avatar is doubled" and "the timestamp is the wrong gray" live in separate threads that can be resolved one at a time.
Use a numbered pin to point at the exact spot you mean. "This field" is ambiguous on a form with eight inputs; pin number 3 on the email field is not. The author should never have to guess which element you are talking about.
The failure mode: a wall-of-text comment with six issues stuffed under one image. The author fixes four, misses two, and you reopen the review. Now you both repeat work that one clean split would have prevented.
Say what you expected, not just what is wrong
"This is broken" forces the author to reconstruct your intent. "The CTA should be the primary blue, this renders the disabled gray" tells them the gap and the target in one sentence. State the expected result next to the screenshot of the actual result. Dictation helps here: in Chrome or Edge you can talk through what you see while you look at it, which captures more context than you would bother to type. Reviewers on Firefox type instead, since the browser speech feature is not available there.
The failure mode: vague verdicts. "Doesn't feel right" sends the author into a guessing loop, and they ship a change that is different but not what you wanted. Several of the mistakes that make screen feedback hard to act on come down to describing the symptom without naming the fix.
Give the author a format they can read without a login
The person fixing the PR should open your review in one click, not create an account or install an extension. When you publish, the review gets a short public URL anyone can read. Paste that link directly in the PR thread. If your IT setup blocks browser extensions, this matters more, and a no-extension way to send screen feedback is the only thing that works at all.
If an AI coding agent is doing the work, the same review is available as plain markdown at the review's /markdown URL, which the agent can read directly. You can also export the review as a PDF or Word document for anyone who wants it offline. One capture, several formats, no extra effort on your part. For the full agent path, see how to get feedback into Cursor.
The failure mode: you send a screenshot pasted into a chat tool the author does not check, or a recording they have to scrub through. The feedback exists but it is not where the work happens, so it gets missed.
Review more than the diff touched
A change to a shared component affects every screen that uses it. The PR diff shows the component file; it does not show the four pages that import it. Walk those pages on the branch and capture each one. This is the part automated checks cannot do, and it is the difference between catching a layout break before merge and catching it after a customer does.
The failure mode: you review only the files in the diff and approve. The component change looks correct in isolation but breaks the settings page that reused it three months ago. The broader version of this, looking past the code to the built result, is the heart of reviewing a UI pull request beyond the code diff.
What good looks like in the PR thread
A reviewer who follows these practices leaves a PR thread with one link to a published review. Inside it: five items, each a screenshot pinned to one element, each with a comment naming the actual result and the expected result. The author opens it, fixes each item, and marks comments resolved as they go. No back-and-forth about which button, no guessing about which viewport, no merged regression on a page nobody thought to check.
Start a review on the branch you are about to approve, and put the link in the PR instead of a vague comment. It is free and there is nothing to install.