Designing onboarding from the moments people stall on camera
Your first-run experience is being tested in public right now, by people using the tools you are about to compete with.
The short answer: design your first-run experience around the moments where people visibly stall in public walkthroughs of the same job, not around the order your data model happens to be in. Eight to twelve recorded sessions of somebody doing the work is enough to find the three or four stalls that will otherwise show up in your own activation funnel.
Onboarding is normally drafted from the inside out. The team knows what objects the system has, so the flow walks a new user through creating one of each — an account, a workspace, a project, a connection — and arrives at an empty state that is technically complete and emotionally flat. Nothing about that sequence came from watching a person try to get something done.
Stalls are free usability data
A tutorial is an unusually honest artefact. The author is trying to look competent, which means every moment they fail to look competent is real friction leaking through. They pause. They scroll a settings page twice. They say “where is that, it used to be under…” and go hunting. They type a value, get an error, and retype it.
None of this is the point of the video, and that is exactly what makes it trustworthy. Nobody is performing friction for your benefit. The same logic drives finding micro-SaaS ideas in tutorial videos: instructional content is obliged to show the tedious steps, including the ones its author stopped noticing years ago.
| What you see | What it means | Onboarding response |
|---|---|---|
| Hunting through settings | Discoverability failure | Surface the control in the flow, not in a menu |
| Jump cut mid-setup | A slow step got edited out | Automate it, defer it, or show progress |
| Re-reading a field label aloud | The label uses your word, not theirs | Rename to the market’s term |
| Typing a value twice | Validation arrives too late | Validate inline, with an example |
| “You’ll want to do this first” | An undocumented prerequisite | Make it step one, or remove the dependency |
The middle row is the one teams under-weight. A jump cut is not a stylistic choice; it is a creator deciding that the next ninety seconds were not worth their audience’s attention. Whatever happened in that gap is a candidate for deletion from your own flow — or, if it genuinely cannot be deleted, for being done on the user’s behalf while they watch something more interesting.
Sequence toward one visible win
Once the stalls are mapped, the design question becomes what the first session should end with. The answer is almost never “a fully configured account”. It is the smallest artefact that proves the product does the thing, produced from data the user already has in front of them.
Working backwards from that artefact tends to delete steps rather than reorder them. Team invitations, naming conventions, integrations and preferences are all real, and none of them belong before the first output. They belong in the second session, once the user has an actual reason to care what the settings do.
- ✗Create one of every object in the data model
- ✗Invite teammates before showing any value
- ✗An empty state as the finish line
- ✗Configuration screens with no worked example
- ✓One real input the user already has
- ✓First artefact produced inside the first session
- ✓Prerequisites removed, defaulted or deferred
- ✓The market's vocabulary on every label
Watch a walkthrough with a stopwatch and note where the first useful result appears. If a competitor gets there in four steps and your draft takes nine, that gap is your activation problem stated numerically, before a single user has seen the flow.
Labels are part of the flow
The cheapest stall to remove is a naming one. Practitioners describe work by outcome; software describes it by structure. When a video says “I need last quarter’s numbers” and the interface says “Create a dataset”, the user has to translate before they can act, and translation is where they leave.
Collecting the market’s vocabulary is a small, mechanical pass: write down the nouns and verbs people actually use for each step, then diff them against your own field labels. Anything that appears in a transcript and nowhere in your interface is a rename waiting to happen, and anything in your interface that never appears in a transcript is probably internal jargon that escaped.
Where onboarding meets the sales objection
A surprising share of activation drop-off is not confusion at all — it is an unresolved worry. People stall at the connect-your-account step because they are unsure what access they are granting, or at the import step because they are unsure whether the data can be removed later.
Those hesitations get voiced out loud in videos and, more bluntly, in the comments underneath them, which is why an onboarding pass and an objection pass are worth running together. The technique is the same one in finding buyer objections in creator content, and the raw material overlaps heavily with mining YouTube comments for product ideas. Answering the worry inline — one plain sentence next to the button — is usually worth more than another tooltip.
How much watching is enough
The recurrence test settles it. Watch until you can predict the stall before it happens; in most categories that lands somewhere between the eighth and twelfth source. Stopping earlier gives you one person’s idiosyncrasies, and continuing well past it produces confirmation rather than information — the same saturation curve described in how many videos a research corpus actually needs.
Keep the timestamp attached to every stall you record. A note that says “users struggle with the connection step” is an opinion; a note that points at a specific moment where a named person spent forty seconds looking for a toggle is evidence, and evidence survives the design review. That is the same discipline behind keeping timestamps and citations attached to video summaries.
What this method will not tell you
Two honest limits are worth stating. Creators are more expert than your median user, so the friction you observe is a floor rather than an average — if a practised person stalls, a first-timer stalls harder. And a recording shows you where someone struggled without ever telling you what they expected to happen instead.
That second gap is the one worth carrying into live conversations. It turns a user session from an open-ended discovery exercise into a short list of specific moments to ask about, which is how the questions in a research-derived interview script stop being generic.
The empty state is the hardest screen you will design
Almost every stall that survives a good first-run flow happens on a screen with nothing on it yet. The user has arrived, the interface is correct, and there is no way to tell what a finished version of this would look like.
The recordings solve this too, because a walkthrough always shows a populated screen — that is the whole point of the demonstration. What a competent, finished workspace looks like in your category is therefore free reference material, and putting a realistic example in front of a new user, clearly marked as sample data they can delete, does more than any amount of instructional text.
What the pass costs
Eight to twelve walkthroughs, watched for friction rather than for instruction, is a single afternoon of structured work. As of August 2026 that fits the $19 a month plan with 25 videos and 2 projects; $59 covers 80 videos and 8 projects if you are mapping several jobs at once, and $199 covers 250 videos, 20 projects and 3 seats. The tiers are laid out on the pricing page.
Pull the friction moments out of a dozen public walkthroughs, with the source moment attached to every observation, and design a first session around the win instead of the data model. 7-day free trial.
Closing thought
Every product you are about to compete with is being usability-tested in public, continuously, by people who have no reason to flatter it. The recordings are free, the friction is unedited, and almost nobody watches them for that.
Frequently asked
How do I design onboarding before I have any users?
Watch people use the tools that already sit in your workflow and mark every moment they stall, backtrack or apologise. Those stalls are the same friction your first ten users will hit, and they are visible in public tutorials months before you have a signup form.
What counts as a stall in a video?
Any point where the narration stops describing the goal and starts describing the interface: hunting for a setting, re-reading a field label, editing a value they got wrong the first time, or cutting away and returning with the step already done.
Why are jump cuts such a useful signal?
Because a creator cuts away from the part that was boring or hard. The edit is an unfiltered admission that something took longer than it should have, and whatever is missing between the two shots is almost always a setup step worth removing or automating.
How many sources do I need to map an onboarding path?
Eight to twelve walkthroughs of the same job is usually enough for the same three or four stalls to repeat. Once you are watching the fifth video and predicting where the pause lands, the map is finished.
Should onboarding copy use the words from the videos?
Yes, when the market's word and your internal word differ. Practitioners name things by outcome and engineers name things by architecture, and shipping the engineering word into onboarding is one of the cheapest self-inflicted stalls there is.
Does this replace watching real users?
No. It gets you a far better first draft, so the sessions you eventually run with real users are spent on problems you could not have predicted rather than on friction that was already documented in public.
What does this kind of research pass cost?
As of August 2026 plans run $19 a month for 25 videos and 2 projects, $59 for 80 videos and 8 projects, and $199 for 250 videos, 20 projects and 3 seats. Mapping one onboarding path takes eight to twelve sources and fits comfortably inside the entry tier.