You have an hour blocked to review the new signup flow before it ships. The PM wants specifics, not vibes, and the engineer wants something they can fix on Monday without watching a 14-minute video. Here is how to walk the flow once, capture friction in the order you hit it, and send something useful by the time your coffee is cold.
Before you start: set the scene in one tab
Open a fresh browser profile or an incognito window so cookies, autofill, and your logged-in state do not contaminate the run. Use Chrome or Edge if you want to dictate your notes; Firefox works fine but you will type. Then open a new review in another tab. No signup, no install, no extension. That is the only setup.
Decide your persona before the first click. "New user on desktop, has heard of the product from a coworker, has never signed up" is enough. Write that one line as your first item in the review (a free-floating comment with no screenshot). It anchors everything that follows and tells the receiver which lens you were wearing.
Walk the flow once at real speed
Go to the marketing page or signup URL and act like a real user. Read what you would actually read. Skip what you would actually skip. The point of the first pass is to feel the friction, not to grade copy. When something snags you (a confusing button label, a field that wants data you do not have, a screen that loads slowly, a password rule that appears only after you fail), stop and capture.
Click Capture screen, share the browser tab, and the current frame is drawn to a canvas. Crop to the part that matters: the form, the modal, the error, the empty state. Drop a numbered pin on the exact element that tripped you. Then add a comment. Dictate it if you can; you will speak more naturally than you type, and natural notes read better later.
Say what you expected, what happened, and why it matters. "I expected the company field to be optional because I am signing up as an individual. It is required and there is no asterisk legend, so I typed 'n/a' to get past it." That sentence is worth more than ten arrows on a screenshot.
Capture in the order you hit the friction
Resist the urge to reorder, dedupe, or polish as you go. The sequence is part of the data. If the third screen breaks because of a choice you made on the first screen, the team needs to see that chain. Each captured screenshot becomes an item in the review, in order, with its pins and its comment. That ordered list IS the user journey.
Some items will have no screenshot. "Between step 2 and step 3 there was a four-second blank screen and I almost closed the tab." Add that as a free-floating comment. Timing, hesitation, and emotional reactions matter in onboarding and they do not live in a screenshot.
If you hit a hard blocker (the verification email never arrives, the OAuth popup is blank), capture it, write down what you tried, and route around it so you can finish the walk. A complete pass with one blocker is more useful than a half pass.
Do a second pass for the things you missed
Now go back to the start in another incognito window and walk it again, faster. You will notice things the first pass hid: the tab title is still "Untitled", the favicon is the framework default, the welcome email arrived from a no-reply address with no sender name, the success screen has no clear next action. Capture each one. Two passes catches roughly twice as much as one and still fits inside your hour.
If mobile matters, do a third pass on a phone-width window. Onboarding bugs hide in viewport widths between 360 and 414 pixels: cut-off buttons, sticky footers that cover the submit, keyboards that hide the field you are typing in.
Publish, then send the right format to the right person
Hit Publish. The review gets a short public URL at /r/<slug>. Anyone with the link can read it, and they can comment on individual items without an account. That is what you send to the PM and the designer. For a formal stakeholder review, export the PDF or Word doc instead; same content, neater wrapper.
If a developer or AI coding agent is going to action the report, grab the markdown version at /r/<slug>/markdown. It is the same review as plain text an agent can read cleanly, which is the practical difference between feedback that gets fixed and feedback that gets watched. The patterns for that handoff are covered in the guide on markdown bug reports and in how to give feedback to an AI coding agent.
One link, three formats, no one has to learn a tool. That is the whole point of the onboarding feedback workflow: you walked the flow, captured the friction in order, and handed over something a human or an agent can act on the same day.
What to do when comments come back
Watch the review's analytics page to see who actually opened it (visit counts, rough geography). When the team posts comments on individual items asking for clarification, answer them inline and mark each one resolved as it is addressed. The review becomes the running record of what changed before launch, which is more useful than a Slack thread that scrolled away on Tuesday.
If this is a client-facing signup, the same approach works for client feedback rounds; if you are reviewing a build that is not live yet, see running a staging review before launch. Same tool, same workflow, different stakeholders.
Block the hour. Walk the flow. Hit Publish. Send the link.