It is 9pm in Berlin, the developer is asleep in Manila, and the designer logs on at 7am in Toronto. You just opened the staging build and spotted six things. Booking a call means losing two days. Writing a wall of text means losing the developer's attention by item three.
What follows is the exact sequence to walk a build, capture what matters, and hand it off so the next person to wake up can start fixing without asking you a single clarifying question.
Step 1: Open the build and a fresh review tab side by side
Pull up the staging URL in one window. In another, go to start a new review. No install, no extension, no signup. The page loads with a Capture screen button and an empty list of items. You are ready to record in about four seconds.
Outcome: two tabs, one showing the build, one ready to receive screenshots and notes.
Step 2: Decide the route before you start clicking
Pick the user path you are reviewing and write it as the first item. Type something like: "Reviewing the signup-to-first-project flow on staging build 482, Chrome 119 on macOS, 1440px viewport." That single comment frames everything that follows. The developer in Manila now knows the browser, the viewport, and which build to check out.
Outcome: the first item in the review is a plain-text context note, not a screenshot. This is the equivalent of the agenda you would have read out loud on a call.
Step 3: Capture each problem as you find it, not in a batch at the end
Walk the flow. The moment something looks wrong, click Capture screen. The browser asks which window or screen to share, you pick the build tab, and a still is drawn to canvas. Drag a rectangle around the relevant region (the broken pricing card, the misaligned form, the unreadable empty state) and confirm the crop.
If you need to point at a specific spot inside the screenshot, drop a numbered pin on it. Pin 1 on the disabled button, pin 2 on the error text. Now your comment can say "pin 1 stays disabled even after I fill all required fields; pin 2 only appears after a second submit."
Outcome: one item per issue, each a cropped still with pins where ambiguity would otherwise creep in.
Step 4: Talk through the comment instead of typing it
For each item, hit dictate and narrate what you saw, what you expected, and how to reproduce it. In Chrome or Edge the browser's speech recognition transcribes as you speak. Two sentences out loud beats four typed ones. Say what the receiver needs:
- What you did right before the screenshot.
- What you expected to happen.
- What actually happened.
If you are on Firefox, type it. Either way, keep each comment scoped to a single problem. If you find two bugs in one screenshot, make two items.
Outcome: every screenshot has a comment that reads like a bug report, not a riddle.
Step 5: Add free-floating comments for anything without a visual
Some feedback has no screenshot. "The whole signup flow feels three steps too long." "Email confirmation took 90 seconds, expected under 10." Add these as items with no image. They sit in the same list and keep the strategic notes next to the pixel-level ones, instead of scattered across Slack.
Outcome: one document holds both "this button is broken" and "this flow is too long."
Step 6: Publish and copy the link
Hit Publish. You get a short URL of the form /r/<slug>. Anyone with the link can open the review. No login wall, no "create account to view comment." Paste the link into the team channel with a one-line summary: "Six items on build 482, three blockers marked at the top." That is the entire handoff.
Reviewing for an external client is the same flow; the no-login link is the whole reason client feedback works asynchronously here. The client opens the link, reads, and replies on individual items. No tool to learn.
Outcome: a single URL that is the whole conversation.
Step 7: Hand the developer the format that fits their tools
The same review is available three ways from the same URL: the public page for humans, a PDF or Word export for anyone who wants a document, and a markdown version at /r/<slug>/markdown. The markdown is the one to paste into Cursor, Claude Code, or any other agent if the team uses one. If they do not, the public link is enough.
The developer in Manila wakes up, opens the link, and works through the list top to bottom. For deeper background on that handoff, the guide on feedback for coding agents and the breakdown of what an agent-readable bug report contains are worth a read.
Outcome: every receiver gets the format that matches their workflow, from the same source.
Step 8: Track responses without a status meeting
As the team works through the list, each person can post a comment on individual items. "Fixed in commit a3f2b, please reverify pin 1." You mark items resolved as they come in. The review's analytics page shows who has opened the link and from where, so you know the Manila developer actually saw it before the Toronto designer starts on the dependent work.
Outcome: progress is visible on the same URL the feedback lives on, with no project board to maintain.
If the review is for a client, not a teammate
The flow is identical, but the framing shifts. Send the link with a short note about which items need a decision versus which are FYI. Clients reply per item. The thread sits on one page they can return to. The pattern for client feedback without making the client learn a tool covers the etiquette in more depth, and the staging site review workflow is the close cousin when you are reviewing pre-launch builds.
Open a new review the next time you spot something on a build. By the time you would have finished writing the meeting invite, the link is already in the channel.