UX Encyclopedia

Flow Design Checklists

Master checklists for reviewing any flow before it becomes wireframes or code. Not every group applies to every flow — but decide that a group doesn't apply; don't just skip it. These are the steps that reviews (and AI code generation) most often miss.

User goals & entry/exit points

  • The user's goal is written at the top of the flow, in their words
  • Every real entry point mapped: deep link, search, notification, email, ad, organic navigation, resumed session — not just "Home"
  • Each entry point lands with enough context to proceed (a deep link into step 3 must not assume step 1's state)
  • Every exit is intentional: success exit, save-and-leave, abandonment — and what state each leaves behind
  • Success is defined from the user's side ("booked", not "form submitted")

Paths

  • Happy path complete, start to confirmed outcome
  • Alternate paths: different user choices, skipped optional steps, returning users, existing-data shortcuts
  • Error paths for every step that can fail (see Error Flow), each with a recovery route — never a dead end
  • Recovery preserves user input; retry never means re-enter
  • Abandonment path: what happens to partial work; can the user resume; do we follow up (and is that welcome)?
  • Back/undo behavior defined at every step — including browser back

States

  • Empty: first-use and zero-data states designed (Empty State Flow), with a path to first content
  • Loading: what shows during each wait; skeleton vs. spinner vs. progress; what's interactive meanwhile
  • Success: explicit confirmation state with a next action
  • Partial/degraded: some data loaded, some failed
  • Offline/reconnect: what works, what queues, what warns (mobile especially)
  • Every screen in the flow has its state set enumerated (State Flow)

Permissions & roles

  • Every step marked with who can perform it (Permission Flow)
  • The blocked experience designed: what a user without permission sees — hidden, disabled-with-reason, or request-access path
  • Role transitions handled: what happens to in-flight work when access is revoked or a role changes
  • OS/browser permission prompts (camera, location, notifications) requested in context, with the denial branch designed

Notifications & communication

  • Each notification in the flow justified: would the user thank us? (Notification Flows)
  • Channel chosen per message (in-app, push, email) with fallbacks
  • Notification taps deep-link to the right state, not the home screen
  • Quiet failure has a voice: async errors reach the user somewhere

Data needs

  • Every screen lists the data it needs and where it comes from (Data Flow)
  • Data the user must supply is minimized and justified
  • Stale/missing/malformed data branches exist
  • Retention and deletion answered for anything the flow collects

Accessibility of the flow itself

Screen-level a11y lives in WCAG Essentials and Accessibility Across Platforms and Devices; this checks the route:

  • The whole flow is completable by keyboard alone, in a sensible focus order across steps
  • No time-trap steps: timeouts are generous, extendable, or absent; nothing auto-advances faster than a screen reader can announce it
  • No step depends on a single sense or ability: color-only cues, audio-only confirmations, drag-only interactions all have alternatives
  • Interruptions (2FA, CAPTCHAs) have accessible alternatives
  • Errors move focus to the problem and are announced
  • The flow's reading level and step count suit the audience (Inclusive Design)

Mobile

  • Flow survives interruption: calls, app switching, lock screen — state restored on return
  • Input minimized: autofill, camera capture, pickers over typing
  • Touch targets and reach considered at every decision point
  • Poor connectivity is a designed branch, not a spinner forever

XR comfort (if any step is in VR/MR/AR)

  • Comfort checkpoints scheduled: breaks, rest poses, no sustained arm work; recenter and pause reachable everywhere (XR (VR/AR) Interaction Flow; Virtual Reality Design)
  • Locomotion comfort-first; user never relocated in MR/AR
  • Headset-off/boundary/tracking-lost states auto-save and resume
  • Seated and one-handed modes; non-XR fallback where feasible

AI uncertainty (if any step is AI-driven)

  • Wrongness is a designed path: correction, dismissal, regenerate, report (Designing AI-Powered Interfaces)
  • Consequential actions gated behind preview + explicit approval; undo exists after
  • Uncertainty surfaces honestly; sources shown where claims are made
  • Escalation to human is discoverable, with context transferred
  • AI involvement is disclosed where users interact with or read it

Developer handoff

  • Every state in the flow is spec'd — not just the happy screens
  • Every transition names its trigger (user event, system event, timeout) — "arrow" is not a spec
  • Copy for errors, empty states, and confirmations written, not TODO
  • Edge-case decisions recorded next to the flow, so they don't get re-decided in code review
  • The flow file lives in the repo and has an owner for updates

Analytics & success metrics

  • Each flow has a success metric (completion rate, time-to-done) and a counter-metric (error rate, support tickets, regret signals)
  • An event is named for every step entry, success, error, and abandonment — before launch, not after
  • Funnels distinguish abandonment (left) from failure (blocked)
  • Someone is named to look at the numbers after launch (Usability Testing & UX Metrics)

Before moving to wireframes, confirm:

  • The user goal is clear
  • Every major decision point is mapped
  • Error and recovery paths are included
  • Empty, loading, and success states are included
  • The required data is known
  • Roles and permissions are clear
  • The behind-the-scenes work is understood
  • Accessibility is supported
  • The flow is measurable with analytics
  • The flow is simple enough for the target user
↑↓ to navigate · Enter to open · Esc to close