UX Encyclopedia

Onboarding Flows

An onboarding flow maps everything between a new user's arrival and their first meaningful success — the "aha moment" the product was bought for. This file maps the ROUTES; the pattern-level evidence (empty states, tooltips, activation metrics, quiz trade-offs) lives in Onboarding, First-Run & Empty States. Registration — the account creation step alone — has its own file: Registration Flows. Onboarding is the superset: welcome → account → setup → first success.

Design backward from the activation target

Define the activation event FIRST — the measurable action that equals first real value (first project created, first message sent, first report run) — then design the flow backward from it, deleting every step that doesn't directly serve reaching it. A flow designed forward ("what should we show them first?") accretes tours, quizzes, and permission walls; a flow designed backward asks of each step: does this move the user toward activation, or does it serve us? Track time-to-value along the flow, not just completion (see the activation section of Onboarding, First-Run & Empty States).

The canonical route

Welcome → account creation → role/personalization (only if the answer visibly changes the next screen) → permissions IN CONTEXT (not here — see below) → guided first task → first meaningful success.

Landing / app install
  → Welcome (one screen: value promise + primary action)
      ├─ "Get started" → Create account (Registration Flows)
      │     ├─ completes → Choose role
      │     └─ abandons → exit
      │           └─ return later → resume AT THE SAME STEP
      │                 (state saved; re-engagement email deep-links here)
      ├─ "Explore first" → limited/demo mode          (if offered)
      │     └─ hits value → signup prompt at moment of motivation
      └─ existing user → Sign in                       (offramp)
  → Choose role / goal  [Skip]
      ├─ answered → next screen visibly adapts (the payoff must show)
      └─ skipped  → sensible defaults, editable later in settings
  → Set preferences  [Skip]  (only asks what can't be inferred from use)
  → Tour offered  [Skip / Skip all]
      ├─ declined → straight to workspace              (no penalty)
      └─ accepted → ≤3 contextual pointers, Esc anywhere
  → Empty workspace = designed empty state (Empty State Flow)
      → "Create your first project" (template/sample offered)
          ├─ completes → SUCCESS moment (activation event fires)
          │     └─ celebrate briefly → normal use
          │           └─ later, at a moment of success: passkey /
          │             notification enrollment prompts (in context)
          └─ stalls → contextual help; next-session nudge deep-links
                back into the incomplete step (not to the home screen)

Permissions: a moment-of-need branch, not a step

Permissions (notifications, camera, location, contacts) do not belong in the onboarding sequence. Map each as a branch that fires when the user takes the action that needs it:

User taps "Scan receipt"
  → soft ask ("To scan, we need camera access")
      ├─ yes → OS dialog
      │     ├─ granted → scan proceeds
      │     └─ denied  → degrade gracefully + path to Settings
      └─ not now → manual-entry alternative; ask again only on
            next relevant action, never on a timer

Apple's HIG says to request permissions in context with evident need; Android 13+ makes even notifications an opt-in runtime permission — the front-loaded permission wall is dead on both platforms (details: Notifications & Communication and Privacy & Security UX).

Progressive onboarding vs. front-loaded tours (the evidence)

NN/g's quantitative test of deck-of-cards tutorials (70 users, 4 mobile apps) found tutorials made users no faster and no more successful — and made tasks feel MORE difficult. Their onboarding analysis recommends avoiding formal onboarding where possible and teaching contextually at the moment of need instead. So the flow implication: the tour is an optional branch, never a gate; the main line runs Welcome → account → first task. Progressive onboarding (contextual tips triggered by behavior, spread over the first sessions) replaces the front-loaded carousel.

Skippability is a requirement, not a courtesy: every step after account creation carries a [Skip], skips are remembered (never re-ask what was skipped twice), and skipping never strands the user — each skip arrow lands somewhere with sensible defaults.

The abandon/return branch is half the flow

Most users do not finish onboarding in one sitting. Map it: state persisted per step; return resumes at the incomplete step, not the start; re-engagement email/notification deep-links into that exact step; a user who returns already-activated never sees onboarding again (demonstrated competence ends the flow). An onboarding flow without a resume route silently restarts users to a welcome carousel — the fastest way to convert a hesitant signup into a churned one.

Common mistakes

  • Designing forward from the welcome screen instead of backward from the activation event.
  • Permission walls and 12-screen questionnaires before any value.
  • Tours as gates (undismissable overlays, focus-trapped walkthroughs).
  • Personalization questions whose answers change nothing visible.
  • No abandon/resume branch; re-engagement links to the homepage instead of the incomplete step.
  • Measuring onboarding completion instead of activation + retention (a completed tour is not a successful user).

Checklist

  • Activation event defined and instrumented before flow design
  • Every step justified against the activation target (or deleted)
  • Account creation branch delegates to Registration Flows
  • Role/personalization step visibly changes the next screen, or is cut
  • Every post-account step skippable; skip lands on sensible defaults
  • Tour optional, ≤3 contextual tips, escapable, never repeated
  • Permissions mapped as moment-of-need branches with denied states
  • First empty state designed as the activation launchpad
  • Abandon branch: state saved, resume-at-step, deep-linked re-engagement
  • Success moment explicit in the flow (what exactly fires it?)
  • Time-to-value measured along the route, not just completion
  • Walked against Flow Design Checklists

Sources

↑↓ to navigate · Enter to open · Esc to close