The button is four pixels too high, the label wraps on mobile, and the empty state you spent an afternoon on never shipped. None of that shows up in a Figma file. It shows up in the build. So the review that matters is the one you run on the built screen, and the feedback that matters is the kind a developer can open, read, and fix without pinging you back three times.
Here is a workflow that keeps the judgment on the real UI and delivers something the developer can queue directly.
Step 1: Open the built screen, not the design file
Pull up the staging or preview URL in your browser. This is the version the developer actually built, rendered by the actual browser at the actual viewport. Compare against your Figma frame in a second window if you want, but the thing you capture is the build. Judging the design on a static mockup is how a wrong margin ships: it looked fine in the file.
If you review on desktop but your users are on phones, resize the window or check both. A layout that holds at 1440px can break at 375px, and that break is exactly the thing worth flagging.
Step 2: Capture the frame in a browser tab
Go to start a new review and click Capture screen. The browser prompts you to share the window, and the current frame draws to a canvas. No install, no extension, no signup. That matters because most design tools want you to sit inside them; here you stay on the real page and grab exactly what the developer will see.
Drag a rectangle to crop down to the region you care about, or keep the full frame. Cropping is the only edit, and that is on purpose. You are not doodling red arrows on a mockup. You are pointing at the built pixels. If you want the reasoning behind that, a cropped still beats an annotated live page for feedback that stays true after the page changes.
Step 3: Pin the exact spot and say what is wrong
Drop a numbered pin on the element you mean. Pin 1 on the primary button, pin 2 on the wrapping label, pin 3 on the missing empty state. Numbered pins make a developer read your points in the order you intend instead of guessing. See numbered pins that make a developer read steps in order if you want to be deliberate about sequence.
Then add the comment. Type it, or dictate it with the browser's built-in speech recognition in Chrome or Edge. Say the specific change, not the vibe. "The CTA sits 8px too high; baseline should align with the input field to its left" beats "button feels off." Use the shared vocabulary a developer already has: padding, margin, baseline, gap, hex value, breakpoint. A designer who writes in those terms gets fixes back that match the intent. That habit is a big part of how designers get built screens to match the design without a second round.
Step 4: Add each issue as its own item
Every problem becomes a separate captured item with its own comment. One item per fix. Do not stack five unrelated problems under one screenshot; the developer will fix the first and lose the rest. If an issue has no visual anchor ("the whole page needs more vertical rhythm"), add it as a free-floating comment with no screenshot.
This is the difference between feedback a developer triages in two minutes and a wall of text they set aside for later. A clean list of discrete, pinned, specifically worded items reads like a task queue, because that is what it is.
Step 5: Publish and send the link
Click Publish. The review saves and gets a short public URL like /r/your-slug. Anyone with the link can open it, read every pinned item, and post a comment on any individual item. You do not need an account to publish; an anonymous review is kept for 30 days, and you can sign in later to claim it permanently.
Send that one link to the developer. They open it in a tab, see the built screen, the pins, and the exact change requested for each. No screenshots pasted into Slack, no back-and-forth about which button you meant. If your developer hands the work to an AI coding agent, the same review is available as clean markdown the agent can read at /r/your-slug/markdown, plus PDF and Word exports for anyone who wants a document.
Step 6: Track resolution without a bug tracker
As the developer fixes items, they (or you) mark each comment resolved on the review. You get a clear picture of what is done and what is left without spinning up a board or assigning tickets. Cobalt Capture is not a project tool and does not try to be; it just makes each item easy to close out. If that fits how you work, resolving comments without a bug tracker covers the mechanics.
The owner-facing analytics page shows visit counts too, so you can tell whether the developer actually opened the link before the standup where they say they did not have it.
Where this fits your larger review habit
This is the same core loop whether you are checking a full build or a single component. For a broader pass across a release, the approach in running a design review on the built product scales it up. To turn a batch of pinned items straight into developer tasks, going from design review to ready-to-code tasks shows the next stretch.
Open the build, pin the exact pixels, name the change in words a developer shares, and send one link. That is feedback that survives the handoff.