UX Encyclopedia

Registration Flows

A registration flow maps account creation specifically: from "I need an account" to "the account exists and is usable." State the boundary clearly in your flow docs, because teams blur it: registration ends when the account exists; onboarding (Onboarding Flows) is everything from arrival to first meaningful success. Registration is one step inside onboarding — usually the step with the worst drop-off, because it's where the product first asks for effort before delivering value. Field-level guidance (labels, validation, autofill, password rules) lives in Forms & Input and Privacy & Security UX; this file maps the routes.

The minimum-information principle

Every field in registration is paid for in drop-off, and every stored field is breach surface (data minimization — Privacy & Security UX). The flow rule: registration collects only what is needed to CREATE the account — typically one identifier plus one credential. Everything else (name, role, preferences, phone, company size) moves to the moment of need: ask for a shipping address when they ship, a phone number when they enable SMS 2FA, a display name when they first post. This is progressive profiling (Forms & Input), and in flow terms it means those questions are branches in LATER flows, not steps in this one. Required vs. optional: in a minimal registration there are no optional fields — an optional field is a field that belongs in a later moment or nowhere.

The main flow

"Create account" (from welcome, or prefilled from a failed login)
  → Enter email → [Continue]
      ├─ new email → credential step
      │     ├─ CREATE A PASSKEY (offer first where supported —
      │     │   FIDO pattern: account exists after one OS gesture,
      │     │   nothing to remember, nothing phishable)
      │     │     ├─ success → account created
      │     │     └─ declined/unsupported → password path
      │     └─ Create password (rules visible upfront, meter honest,
      │           paste allowed, show-password toggle)
      │           └─ valid → account created
      ├─ EMAIL ALREADY EXISTS → sign-in offramp:
      │     "You already have an account" → Sign in (email
      │     prefilled) → forgot-password one tap away
      │     (never a bare "email taken" error that strands them;
      │     security note: this reveals account existence — for
      │     sensitive products use the email-first neutral pattern:
      │     "check your email" either way, message differs privately)
      ├─ typo'd domain (gamil.com) → "did you mean gmail.com?"
      └─ social/SSO button → provider consent → return
            └─ email collision → link accounts after re-auth
                  (see Authentication Flows)
  → Terms acceptance
      • unambiguous action; unbundled checkboxes (terms ≠ marketing
        consent — pre-ticked marketing boxes are illegal under GDPR)
  → Email verification (placement per policy below)
  → (Optional, clearly skippable) Name → Preferences
  → CREATED → hand off to onboarding at the next step
Abandon (any step)
  → keep entered state where retention policy allows; a returning
    half-registrant resumes, not restarts

Email verification placement — three options, real trade-offs

  1. Verify before use (account locked until link clicked): highest integrity, worst drop-off — the flow now depends on another app (their inbox) at the moment of maximum fragility. Branches you must map: email never arrives (resend + edit-address route), link opens in another browser (session handoff), link expires. Reserve for products where a wrong email is catastrophic (finance, legal).
  2. Soft-verify while using: account works immediately; a persistent-but-polite banner asks for verification; only email-dependent features (notifications, recovery) are held back. Best default for most products — value flows first.
  3. Verify at sensitive action: no verification until the user tries something that requires a proven address (payout, invite, publish). Lowest friction, but the verification interrupt lands mid-task — design that interrupt as a save-and-resume branch, not a dead stop.

Whichever you choose, map the abandoned-verification branch: the user who registered but never clicked. Timed reminder (capped, then stop), re-send on next login attempt, and an expiry policy for never-verified accounts — plus the "wrong email entered" recovery route (let them correct the address and re-send without support).

Verification email sent
  ├─ clicked → verified → continue where they left off
  ├─ not clicked, returns to product →
  │     soft-verified? → keep using + banner    (option 2/3)
  │     hard-locked?   → "check your inbox" + resend + EDIT EMAIL
  ├─ never returns → capped reminder → account expiry policy
  └─ email bounces → flag on next visit, force address correction

Common mistakes

  • Registration walls that ask for onboarding-tier data (role, company, phone, birthday) before the account exists.
  • "Email already registered" as a dead-end error instead of a prefilled sign-in offramp.
  • Verify-before-use chosen by default, with no resend, no edit-address, and no expiry branch.
  • Bundled consent: one checkbox covering terms + privacy + marketing.
  • Password-only credential step in 2026 — passkey not offered at creation (FIDO documents new-account-creation-with-passkey as a standard pattern) or at first success afterward.
  • Confirm-email / confirm-password double fields (typo theater; use show-password and verification instead).
  • No abandoned-registration or abandoned-verification branches mapped.

Checklist

  • Boundary stated: this flow ends at "account exists"; onboarding owns the rest
  • Fields = identifier + credential; every extra field moved to moment of need
  • Passkey offered at creation with password fallback (or enrollment at first success)
  • Existing-email branch → sign-in offramp, email prefilled, reset one tap away
  • Enumeration stance chosen deliberately and consistent with login/reset
  • SSO branch with email-collision linking route
  • Verification placement chosen (before use / soft / at-action) with rationale
  • Not-received, expired-link, wrong-address, and cross-device branches mapped
  • Abandoned-verification loop: capped reminders, resend-on-login, expiry policy
  • Terms unbundled from marketing consent; no pre-ticked boxes
  • Abandon/resume branch for half-completed registration
  • Handoff arrow into Onboarding Flows at the exact next step
  • Walked against Flow Design Checklists

Sources

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