01Eight fields on the first screen
A signup form that asks for company size before the product has shown anything is asking the user to invest before receiving. Every field on the first screen should be one the product cannot function without.
Onboarding Flow
Onboarding is the only interface where the user has already decided to give you something and every additional field is a chance to change their mind. The design goal is not completeness, it is a first successful outcome — everything else can be collected later, when the value is already visible.
What this page has to do
Generated onboarding flows usually look like a settings form split across screens: eight fields per step, a required company size, a phone number, and a progress bar that turns out to be decorative because validation only fires on submit.
Three rules do most of the work. Ask one thing per screen so the cognitive load stays low. Validate as the field loses focus, not when the button is pressed. And make skip real — a Skip link that advances without saving is worse than no link, because it teaches the user the interface lies.
Section order
The order is the argument. Reordering these is not a layout decision, it is a change to the reasoning.
-
01
Progress indicator
Named steps, not just a bar. A bar tells you how long it is; names tell you what is coming, which is what decides whether someone continues.
-
02
One question per step
One primary input, one sentence of why it is being asked. Two fields on a screen doubles the chance of one being abandoned.
-
03
Inline validation
Validate on blur, clear the error on input. Never validate on every keystroke, which flags a partially typed email as invalid.
-
04
Skip
Real skip for anything not required to reach first value, and it must persist — a skipped step must not reappear on the summary screen.
-
05
Summary step
Show what was entered, with edit links. This is where the user catches their own typo before it becomes a support ticket.
-
06
Success state
One screen that says what now exists and what to do next, with a single primary action. Not a confetti animation and not a dashboard dump.
-
07
Resume
If the user leaves mid-flow, the next visit returns to the same step with prior answers intact. Losing progress is the most common silent abandonment cause.
-
08
Empty first screen
Whatever the flow creates, the first view of it must not be blank. One seeded example beats a tutorial overlay.
Build the prompt
7 variables. Change one and the text below rewrites itself — nothing else on this page moves.
The shortest flow that still produces a usable account.
Ask only what the first session needs.
Build a a three-step flow: account, workspace, invite onboarding flow for a team workspace tool, where the first value is seeing a project with the team already in it. AUDIENCE Someone who signed up in the last five minutes. They have one goal: see the product do the thing they signed up for. They are willing to answer two or three questions and unwilling to answer eight. STRUCTURE 1. Layout: no global navigation during onboarding. A single centred column, maximum 480px, with the product wordmark small in the top left and an exit link in the top right. Nothing else competes with the step. 2. Progress: a row of named steps (Account, Workspace, Team) with the current one marked by weight and a filled dot, completed steps clickable, future steps not Step names are visible, the current step is marked, completed steps are links back, future steps are not clickable. 3. Steps: Email and password, then workspace name with a live URL preview, then optional teammate invites with a skip link. Three fields total, two of them skippable. One primary input per step. A single sentence explains why it is being asked, phrased as a benefit rather than a policy. 4. Validation: Validate on blur, clear on input, and never block the primary button. The click surfaces the first invalid field and moves focus to it. On blur, show a specific message under the field (that address is missing an @ sign), not a generic one. Clear the message as soon as the user edits. Never disable the primary button to signal invalid input — let the click explain. 5. Skip: for every step that is not required to reach first value, a text link beside the primary button. Skipping must advance and must not silently save a default. 6. Summary: before the final action, show every answer in a definition list with Edit links. One confirm button, labelled with what it does (Create workspace), not Next. 7. Success: a dedicated screen stating what now exists, one primary action to start, and one secondary link to a sample so the first view is never empty. STYLE Product neutral: white card on a very light grey page, 1px borders, 10px radii, one accent on the primary button only, 16px inputs at 44px height, labels above fields and always visible. MOTION A single 180ms horizontal slide between steps, direction matching forward or back, disabled entirely under prefers-reduced-motion. Nothing else animates. COPY RULES - Button labels are verbs that name the outcome: Continue, Create workspace, Invite team. Never Submit. - Ask for the minimum. Every optional field is a step that can be skipped, and defaults are visible rather than hidden. - No marketing copy inside the flow. No upsells before the first success. - Error messages name the fix, not the rule: Add a company domain, not Invalid input. CONSTRAINTS - Keyboard: Enter advances, Escape exits with a confirmation, focus moves to the first field on every step. - The primary button is at least 48px tall and sits in the same position on every step. - Mobile: the primary action remains visible with the keyboard open at 390x844. - State persists to local storage after each step, so a refresh resumes rather than restarts. - No step may require a field that the product does not use within the first session. OUTPUT A working flow with real validation and real state, not five screens of static markup.
What to change, and what to leave alone
| Variable | How to edit it |
|---|---|
{{FLOW}} |
Every added step is a measurable drop in completion. If a step does not change what the user sees in their first session, it belongs in settings, not in onboarding. |
{{PROGRESS}} |
Named steps convert better than bars because they let the user decide whether to continue. A bar with no names tells them the effort but not the destination. |
{{STEPS}} |
The use-case step is worth its cost only if it changes the seeded content. A personalisation question that changes nothing is pure friction, and users notice. |
{{VALIDATION}} |
Never validate on keystroke from the first character: a half-typed email is invalid by definition and the interface shouts at someone who is still working. |
{{STYLE}} |
Swap the block whole. A dark input on a light page or vice versa reads as a broken form rather than a design choice. |
Feeding it to each builder
| Builder | What to do differently |
|---|---|
| v0 | Generate one step, then ask for the flow shell around it. Building five screens at once produces five different button positions, which is the most common fix-up in onboarding work. |
| Lovable | It will add a password strength meter and a terms checkbox. Keep the terms checkbox only if it is legally required in your jurisdiction; the strength meter is usually noise that stops people mid-field. |
| Bolt | Ask for state to persist per step before styling. Retro-fitting persistence produces flows that restart whenever a component remounts. |
| Cursor / Claude Code | Define the step list as an array of objects with a validate function each, then render generically. Five bespoke screens drift apart within a week. |
Where it usually breaks
02A progress bar that is decorative
If the bar does not reflect real step completion, users learn to distrust every other indicator on the page. It is a small lie with a long half-life.
03Skip that saves nothing
A Skip link that advances without recording the decision means the summary screen shows blank fields the user thought they had skipped. Either save the skip explicitly or remove the link.
04The disabled button
Greying out Continue until the form is valid gives no reason and no feedback. Leave the button enabled and let the click say what is missing — that is the only moment the user is guaranteed to be paying attention.