You have five screens to review for a client and forty minutes before the next call. Typing a paragraph under each one is slow, and the client ends up reading a flat list of changes with none of the reasoning behind them. Talking through what you see is faster and lands better, because the client hears why the header feels crowded, not just "fix the header."
Here is the full workflow, start to finish, using dictation over captured stills. Chrome or Edge, no install, no signup. If your reviewer is on Firefox, dictation is off there and they type instead, which is covered in what to do when your reviewer is on Firefox.
Step 1: Open a review and capture the first screen
Go to start a new review in a browser tab. Put the page you are reviewing in another window or tab. Click Capture screen. The browser asks which window or screen to share, and the current frame gets drawn to a canvas. That still is now the first item in your review.
Drag a rectangle to crop down to the part you care about, or keep the full frame. Cropping is the only edit you make to the image. You are not drawing arrows or boxes; the point of this workflow is that your voice carries the explanation. If you want the reasoning behind that, a cropped still beats an annotated live page for most feedback.
Step 2: Dictate your observation over the still
With the screenshot in front of you, start dictation and talk. Say what you notice and why it matters. Something like: "The signup button sits below the fold on a laptop, so a first-time visitor scrolls past the pricing before they ever see the call to action. I would move it up next to the plan cards."
That is three things in one breath: what you see, the consequence, and the suggested fix. Typing that same thought takes four times as long and usually comes out shorter and blunter. Dictation lets you keep the causal chain intact, which is exactly what a client needs to agree or push back. For longer notes, dictation beats typing once the comment runs past a sentence or two.
The browser's built-in speech recognition writes your words straight into the comment. Read it back, fix any word it misheard, and move on.
Step 3: Drop a numbered pin if the spot is ambiguous
If your comment points at one exact element on a busy screen, add a numbered pin to the screenshot at that spot. Now the client's eye goes to the same place your voice is describing. When you have several points on one screen, pins in order keep the client and any developer reading in the sequence you meant, which is the case for numbered pins that set the reading order.
Step 4: Repeat for each screen, and add floating notes
Capture the next screen, crop, dictate, pin. Each screenshot becomes its own item, so the client scrolls through them in order like a walkthrough.
Some of your feedback is not about a single screen. "The tone across the marketing pages reads more formal than the app itself." That kind of remark does not need a screenshot. Add it as a free-floating comment, dictate it the same way, and it sits in the review as its own item.
Step 5: Publish and send one link
Click Publish. The review saves and gets a short public URL of the form /r/<slug>. Anyone with the link can open it and read your captured screens with your dictated notes underneath. No account, no tool for the client to learn. That is the whole promise of the client feedback workflow: they click a link and see your thinking.
If the client wants a document instead of a link, the same review exports as a PDF or a Word file. And if their developer or an AI coding agent is going to act on it, the plain-text version lives at /r/<slug>/markdown. One review, several outputs, chosen by whoever receives it. Sending both at once is the point of one review, two links for client and developer.
Step 6: Let the client reply on each item
Anyone with the link can post a comment on any individual item. So the client can reply directly under your "move the button up" note with "agreed" or "we tried that, here's why it stayed." You mark each comment resolved as it gets handled. This is a conversation on the screens, not a bug tracker with assignees and statuses. If you want to know exactly who can do what, who can see, comment on, and resolve items lays it out.
Why the spoken version gets fixed faster
A written status update strips out the reasoning to save your time, and the client fills the gap with guesses. Dictating over each still puts the reasoning back in at no extra cost to you, because talking is faster than typing. The client hears a person thinking, not a checklist, so they either agree quickly or raise the real objection early instead of during a redo.
Try it on the next set of screens sitting in your inbox. Open a tab, capture the first one, and talk. If you review across timezones and never catch the client live, the same link works asynchronously, which is the setup in client feedback when you are never online together.