A new user signs up, waits for the verification email, and it never arrives. Or it lands 40 seconds later with a sender name of "noreply@", a subject line that reads like a database field, and a confirm button that points at a staging URL. You will never find any of that in a set of screenshots of your signup screens, because the screens are not where the problem lives. The emails are.
Signup is not a page. It is a sequence, and part of that sequence happens outside the browser entirely. A screenshot pass captures the form, the success state, maybe the empty dashboard behind it. The confirmation email, the welcome email, and the password-reset email that a first-time user often triggers by accident are all invisible to a reviewer who is only grabbing frames of the UI.
Why the emails are where signup breaks
The form is the part your team looks at most, so it tends to be the part that works. The emails get built once, early, and then nobody opens their own signup inbox again. That is where the rot sets in.
Common failures that only show up when you actually receive the message: the verification link expires faster than the copy claims, the email renders fine on desktop but the button overflows on a phone, the "reset your password" and "confirm your email" templates got swapped, or the whole thing goes to a promotions tab because the sending domain was never configured. Each of these stops a real user cold, and each is invisible to someone photographing screens.
There is also timing. A screenshot has no clock. If the confirmation email takes a minute to arrive, a static review shows a user who confirmed instantly. The person walking the flow in real time notices the wait, because they are the one sitting there refreshing the inbox.
What walking the flow step by step records
A flow walkthrough treats signup as one named sequence and goes through it in order: land on the form, submit it, wait for the email, open it, click the link, see where it drops you. Every step is a captured still with a note, and the emails the flow sends are part of the record, not an afterthought.
That matters because the receiver can see the chain. Instead of a lone screenshot of a broken button, they get the step before it (the user submitted a valid address) and the step after (the confirm link 404s). A developer reading that does not have to guess what the user did to get there. The order is already laid out, which is the same reason numbered pins make a reader follow steps in order.
Cobalt's agent-run walkthrough signs up with a temporary test inbox, so it can receive the real emails your system sends and screenshot each one the way a first-time user would see it. It needs an AI that can drive a browser, and it stops once for your go before it starts. You ask in plain words, for example "Walk the signup flow on yoursite.com," and it returns a review: the form, the emails, the links clicked, and where each one landed.
Walkthrough versus a plain onboarding pass
These two studies look similar and catch different things. An onboarding feedback pass judges whether a new user understands what to do next once they are inside the product. A flow walkthrough verifies that a single named path actually completes, emails included. If your complaint is "people sign up and never confirm," that is a walkthrough question, not an onboarding one. The difference is covered in more detail in what each pass actually catches.
You can run either one by hand too. If you want to walk your own signup and capture the emails yourself, you capture each screen, add your own screenshots of the inbox on a phone (phone browsers cannot grab the screen, so you take a normal screenshot and add it), pin the broken spot, and type or dictate what went wrong. The output is the same review format: a link anyone can open with no login, plus a PDF or clean markdown if a coding agent is going to read it.
Turning what you find into a fix
A walkthrough is only useful if the broken step reaches whoever fixes it. The review link opens on a phone with no app, so a founder can read it between meetings. A signed-in owner can send it to a GitHub repository as an issue, screenshots and all. And because the review is also available as markdown, an agent reading it sees the screenshot of the misrouted confirm link, not just a sentence describing it.
The honest version of the pricing: capturing reviews is free to try with no password and no card. After 7 days a review goes read-only for you, though the link you shared keeps working for the people you sent it to. Keeping every review editable and reopening read-only ones is the $5 a month Pro plan, cancellable any time. Full detail is on the pricing page.
Next time someone says "signups are down," do not screenshot the form. Walk the whole flow, open the email, and click the link. The problem is almost always one step past where a screenshot stops.