You have a Figma file, a staging build, or a half-finished landing page, and you owe the designer feedback by end of day. You do not need a meeting and you do not need a new app to install. You need a sequence of cropped screenshots, each tied to a specific comment, sitting at a URL anyone on the team can open.
Here is a workflow that gets you from blank tab to shared link in about twenty minutes, using nothing the reviewer has to download.
Step 1: Open the design and the capture tool side by side
Put the artifact you are reviewing in one window: Figma prototype, staging URL, Storybook, whatever. In a second tab, open a fresh review. No signup, no extension. The browser is the only thing you need running.
Outcome: you have a live review session ready to receive items, and the thing you are critiquing is one click away.
Step 2: Decide what you are reviewing for, in one sentence
Type that sentence as the first free-floating comment. Something like "Reviewing the checkout flow on staging against the v3 Figma, focused on the address step." This is not ceremony. It anchors every comment that follows, and it tells the designer reading the link later what frame you were in.
Outcome: the review has a stated scope at the top, so a comment about button padding does not get read as a comment about information architecture.
Step 3: Walk the screens and capture stills as you go
Click Capture screen. The browser asks which window or tab to share. Pick the design, and the current frame is drawn to a canvas. Drag a rectangle around the part you want to talk about, or take the full frame. Each capture becomes its own item.
Resist the urge to capture only the broken bits. Capture the screens that are working too, with a one-line comment saying so. A designer who only sees the negatives cannot tell whether you noticed the parts you liked.
Outcome: an ordered list of cropped stills that mirrors the path a user would walk through the product.
Step 4: Talk through each screenshot instead of typing
For each item, hit dictate and narrate what you see. In Chrome and Edge the browser's speech recognition turns it into text in place. Firefox users will need to type. Talking is faster than typing, and it tends to produce comments that sound like a person reviewing a design rather than a checklist of nits.
Say what you noticed, why it caught your eye, and what you would try. "The primary button sits eight pixels below the form, which makes it read as unrelated. I would close that gap or move it inside the card." That is feedback a designer can act on. "Button feels off" is not.
Outcome: every screenshot carries a comment that explains the issue and proposes a direction.
Step 5: Drop numbered pins where the comment points at a specific spot
When a single screenshot has three different issues, add numbered pins to the still and refer to them in the comment: "1 is the label alignment, 2 is the helper text color, 3 is the focus ring on the dropdown." Pins keep three problems in one screenshot from collapsing into one mushy paragraph.
Outcome: multi-issue screens are still legible, and the designer can resolve them one at a time.
Step 6: Add free-floating comments for the things that have no screen
Some feedback is not about a specific frame. "There is no empty state for a brand-new account anywhere in this flow." "The tone shifts from second person on the marketing site to first person in the app." Add these as items without a screenshot.
Outcome: structural notes live alongside the visual ones, in the same artifact, instead of getting buried in Slack.
Step 7: Reorder items so the most important issues are first
Drag the blocking issues to the top. Polish items go to the bottom. Designers and PMs read top to bottom and triage as they go. If your tenth item is the one that breaks the launch, it will get treated like a tenth-priority item.
Outcome: the review communicates priority through order, without you having to write "P1" on anything.
Step 8: Publish and share the link
Hit Publish. You get a short URL of the form /r/<slug>. Paste it into the design ticket, the Slack thread, or an email. Anyone with the link can read the review and leave a comment on any individual item. You can mark each comment resolved as the work lands.
The same review is available as a PDF, a Word doc, and as markdown at /r/<slug>/markdown. If your designer hands the work to an agent like Cursor or Claude Code, that markdown URL is what the agent reads. You do not have to do anything different to produce it.
Outcome: one link, multiple formats, one source of truth for what needs to change.
What this workflow is good for, and what it is not
This shape works well for design review on a built or near-built product, for staging site reviews before launch, and for client feedback rounds where the client should not have to learn a tool.
It is not a substitute for a live critique on a still-forming concept, where two designers need to sketch together. It is also not a bug tracker; once items are resolved, archive the review and start a fresh one for the next round rather than letting one URL accumulate six weeks of mixed history. If you are doing this for a distributed team and want more on the async side, the design review on the built product walkthrough goes deeper on handoff.
Next time someone asks for design feedback, open a tab, talk through what you see, and send the link.