You are three screens into the new checkout flow and you already have five complaints: the shipping field jumps, the promo code error is unreadable, the confirmation button sits below the fold on a laptop. If you drop those into Slack as they occur to you, they arrive out of order, half of them without a screenshot, and the developer has to reconstruct what you meant. A week later nobody can tell which comment maps to which screen.
Here is a way to record friction in the exact order you hit it, and hand over one review instead of a scattered thread. It runs in a browser tab. Nothing to install, nothing to sign up for.
Open one tab and start capturing before you click anything
Go to start a new review in a fresh tab, then open the build you are testing in another window. Walk the flow the way a real user would, not the way you know it works. The point is to catch the spots where you hesitate.
When something is wrong or awkward, click Capture screen. The browser asks which window to share and draws the current frame to a canvas. You get a still of exactly what you were looking at when the friction hit. This is a screenshot tool, not a screen recorder, so you are working with frozen frames, not a video someone has to scrub through.
Crop to the problem, then say what is wrong out loud
Drag a rectangle around the part that matters. If the promo code error is the issue, crop to that field and its message. Cropping is the only edit, and that is on purpose: a tight crop tells the developer where to look faster than an arrow drawn on a full-page screenshot. See why a cropped still beats an annotated live page if you want the reasoning.
Now add your comment. In Chrome or Edge you can dictate it with the browser's built-in speech recognition, which is faster than typing while you are mid-flow. Say what you saw, what you expected, and why it matters: "The promo error is gray on white and I almost missed it. It should be red, and it should say which code failed." That reads as an actionable note, not a shrug. If you are on Firefox, you type instead.
Each capture becomes its own item. Keep going. Every screen where you stumbled gets its own still and its own comment, stacked in the order you hit them. That order is the value: it is your walk through the build, preserved.
Pin the exact spot and add notes without a screenshot
When one screen has two separate problems, drop numbered pins on the still so the developer reads them in the right sequence. Pin 1 on the field that jumps, pin 2 on the button below the fold. Numbered pins stop the guessing about which comment points at which element.
Some feedback has no screen attached. A missing empty state, a step you expected and never saw, a question about copy. Add those as free-floating comments. The review holds the visual items and the plain notes together, so nothing lives in a separate doc.
Publish once and send the link the team can act on
When you have walked the whole flow, click Publish. The review saves and gets a short public URL like /r/checkout-review. Anyone with the link opens it in a browser, no login required. Your developer sees each cropped still, each pin, each comment, in the order you recorded them.
The same review is available three ways from that one publish. People read the link or you export a PDF or Word document for a stakeholder who wants something to file. If the work is going to an AI coding agent, the review is also clean markdown at /r/<slug>/markdown that the agent reads directly. One capture pass, three output formats, no reformatting.
Whoever opens the link can comment on any individual item, and you can mark each one resolved as it gets fixed. That gives you a running status on the review itself without touching a bug tracker. If you want to see whether the developer actually opened it, each review has an owner-facing page with visit counts.
Why this beats a Slack thread of loose screenshots
A thread scatters. Screenshots arrive without context, comments arrive without screenshots, and the sequence gets shuffled the moment two people reply at once. A published review keeps the walk intact: this is what I saw, on this screen, in this order, and here is what should change. That is the kind of feedback a developer can work straight down without a meeting to decode it.
This is the everyday job for product managers who need feedback that gets fixed: not a video call to talk through problems, not a doc that goes stale, but one link the team acts on. If you run these walks on staging before launch, the same steps apply in a staging review before it ships.
Next time you are about to fire off a Slack screenshot, open Cobalt Capture in a tab first. Walk the build once, capture as you go, publish one link. The team reads it in the order you found it.