The design looked great in Figma. The build is close, but the spacing is off in three places, a button lost its hover state, and the empty state nobody noticed during handoff is now staring at you from staging. You need to flag all of it without scheduling a meeting or writing a 1,500 word doc nobody will read.
Here is a workflow that takes about twenty minutes for a typical page and produces a link the developer can open, read, and start checking off. No install, no extension, no signup. Open a browser tab and go.
Step 1: Open the built page next to the design
Pull up the staging build in one window and the source design in another. Put them on the same monitor if you can. You are looking for differences, so make them easy to compare. Decide upfront which breakpoint you are reviewing. If the design covers desktop, tablet, and mobile, do one pass per breakpoint rather than mixing notes across all three. Mixing them is how reviews end up with comments the developer cannot reproduce.
Outcome: two windows side by side, one breakpoint selected, and a clear scope (which page, which states, which viewport).
Step 2: Open a new review in another tab
In a third tab, start a new review. You do not need an account. An anonymous review stays live for 30 days, which is enough for any normal review cycle, and you can sign in later to claim it permanently if you want it kept. If you already have a Cobalt Capture account, sign in first so the review is attached from the start.
Give the review a title that names the page and the build, like "Checkout v2, staging, desktop pass." Future you will thank present you when there are four review links in Slack and none of them have titles.
Outcome: an empty review open in a tab, ready to receive items.
Step 3: Capture the first frame and crop to what matters
Click Capture screen. The browser asks which window or screen to share, and a still frame is drawn to canvas. Drag a rectangle around the section you want to comment on. A cropped still beats a full-screen screenshot because the receiver sees exactly what you saw without scanning the whole page for the thing you meant.
Cropping is the only image edit available, and that is intentional. You are not going to spend ten minutes drawing red arrows on a screenshot. You are going to crop tight, then say what is wrong. For a deeper look at why this pattern works for comparing design against build, the use-case page lays out the receiver's side of it.
Outcome: one item in the review, cropped to a single issue.
Step 4: Talk through the comment instead of typing
Click the dictation button on the item and describe what you see. "The card padding is 16 pixels here. The design has it at 24. Also the heading should be semibold, not regular." Dictation uses the browser's built-in speech recognition and works in Chrome and Edge. On Firefox, you type. Either way, write what you would say out loud: the specific thing that is wrong and what it should be instead.
If the section has more than one issue, drop numbered pins on the still and reference them in the comment. "Pin 1: padding. Pin 2: heading weight. Pin 3: the divider is missing." Three pins, one item, one comment. Cleaner than three separate items for the same screenshot.
Outcome: a screenshot, optional pins, and a comment that names the difference between design and build.
Step 5: Work through the page in reading order
Go top to bottom. Header, hero, then each section in turn, then the footer. After the static states, hit the interactive ones: hover, focus, disabled, loading, error, empty. These are where built products drift furthest from the design, because they are easy to skip during handoff. Capture each one as its own item. Aim for one issue per item where possible. It makes comments cleaner and lets the developer mark them resolved individually.
If you spot something that has no useful screenshot ("the page title in the browser tab still says Untitled"), add a free-floating comment without a capture. Not every note needs an image.
Outcome: a review with ten to thirty items covering the page in order.
Step 6: Publish and share the link
Click Publish. The review gets a short public URL of the form /r/<slug>. Anyone with the link can open it; they do not need an account. Paste that link into Slack, the ticket, or wherever the developer lives.
If the build is going to an AI coding agent rather than a person, append /markdown to the URL and feed that to the agent. The same review is also exportable as PDF or Word if the receiver is a client who wants something formal. Pick the format that fits the receiver; the underlying review is the same.
Outcome: a link in the right channel, with the right format for the person reading it.
Step 7: Let the developer reply on each item
The developer opens the link, reads through, and posts a reply on any item that needs discussion ("This is intentional, the design changed last Thursday" or "Fixed in commit abc123"). You mark each item resolved as it lands on the next build. The review becomes the running record of the pass, not a thread that scrolls into oblivion.
When a second design review is needed for the same page, start a fresh review rather than reopening the first one. Compare the two links side by side. The pattern works the same way for an accessibility pass or a staging review before launch; only the things you look for change.
If this is a client-facing review where the work is being signed off, the client feedback workflow uses the same publish-and-share pattern with the PDF export instead of the link. Same review, different receiver, no extra effort.