You are about to walk through a signup path, screen by screen, capturing what breaks. Before you start, decide which of two jobs you are doing, because they look identical and produce different notes. One is a general flow walkthrough: any multi-step path, checked step by step. The other is an onboarding feedback pass: the specific first run a new user takes, judged on whether they get to value. Same clicks, different questions, different things you write down.
The question each pass answers
A flow walkthrough asks: does this path work? You move through every step of a defined sequence (checkout, a settings wizard, a multi-page form) and mark anything that is broken, confusing, or off. It is agnostic about who the user is. A returning power user and a first-timer both hit the same steps, and you are checking the steps.
An onboarding pass asks a narrower thing: does a brand-new person, who has never seen this product, reach the first useful moment without giving up? You are not just checking that the buttons work. You are checking whether someone with zero context knows what to do next, whether the empty states explain themselves, and where a real newcomer would stall.
The overlap is why people conflate them. Onboarding is a flow, so an onboarding pass is a flow walkthrough with a specific lens bolted on. But if you run the general version and call it onboarding, you will miss the things that only a fresh user hits.
What you capture in a flow walkthrough
In the general flow walkthrough format, each step becomes one item. You capture the screen, drop a numbered pin on the exact control, and write what is wrong with it. The numbering carries the sequence, so whoever reads the export sees the steps in order without you narrating "then I clicked next."
The notes are functional and checkable. "Step 3: the Continue button is disabled but there is no message saying why." "Step 5: back button loses the data I entered on step 4." You are documenting behavior against the intended path. A developer or an agent reading it can reproduce each item because you pinned the spot and stated the action. If you want the numbering to do more work, there is a pattern for pins that make a developer read steps in order.
What you do not usually capture here: whether the copy makes sense to someone new, or whether the whole sequence is worth the number of steps. That is out of scope for "does it work."
What an onboarding pass adds on top
An onboarding feedback pass keeps all of that and adds the first-time-user judgments. You capture the same screens, but your comments read differently:
- Point of confusion: "The dashboard is empty and there is no prompt telling me what to create first."
- Unexplained jargon: "It asks me to pick a workspace before I know what a workspace is."
- Where I would quit: "Step 4 asks for a credit card before I have seen anything work. A new user bails here."
- Time to first value: "It took six screens to reach the thing I signed up for."
These are opinions grounded in the new-user perspective, and they are the whole point of the pass. The trick is to actually simulate a first run: fresh account, no saved state, and note your reaction before you use what you already know about the product. If you are documenting this as you go, an onboarding template you fill as you walk keeps the two kinds of note (broken vs confusing) separate so the receiver can triage them.
Where they line up in a table
| Dimension | Flow walkthrough | Onboarding pass |
|---|---|---|
| Question | Does the path work? | Does a newcomer reach value? |
| User assumed | Any user | First-time user, no context |
| Main note type | Broken or wrong behavior | Confusion, friction, drop-off risk |
| Needs a fresh account | No | Yes |
| Copy and empty states | Often skipped | Central |
Capturing either one without switching tools
Both passes run the same way mechanically. Open a browser tab, click Capture screen, grab each step as a still, pin the spot, and type or dictate the note. No install, no extension, no password to start. When you Publish, you get a review link the receiver opens with no account, plus a clean PDF or Word export for a person and plain markdown an AI coding agent can read directly. That last format matters when the fixes go to a developer or an agent, because the markdown carries your pinned screenshots and comments in order.
Dictation helps on the onboarding pass in particular, since first-reaction notes come out faster spoken than typed. It works in Chrome and Edge; on Firefox you type instead. On a phone you cannot capture the screen, so you take a normal screenshot and add it, which is fine for reviewing a mobile onboarding flow from the device itself.
Cobalt Capture is not a bug tracker with assignees and workflow states, and it does not record video. It captures still frames and turns them into a shareable review. If your onboarding audit turns into ongoing tickets, you will move the items into whatever tracker you already run. For the walkthrough itself, one review link holds the whole ordered path.
Pick the pass before the first click
Decide up front. If someone asked "is the flow broken," run the general walkthrough and stay on behavior. If someone asked "why are new signups dropping off," create a fresh account, run the onboarding pass, and write down every place you hesitated. You can start either one now at a new review, and it stays editable for 7 days on the free tier, or indefinitely on Pro at $5 a month.