UX Flows — Overview
A flow is a designed map of movement through an experience: the steps, decisions, states, and handoffs between a starting intent and an outcome. Flows are the working documents UX designers produce BEFORE high-fidelity UI — they are cheap to change, force the hard questions early (what can go wrong? who else is involved? what does the system do?), and give teams a shared picture that words and wireframes each fail to give alone.
Design the flow before the screens: a beautiful screen on a broken path is a beautiful dead end. Flows surface user goals, decision points, edge cases, system behavior, and business operations while changing them still costs minutes, not sprints.
Four altitudes of flow
- User-centered flows (user flow, task flow, screen flow) — the path a person takes. Unit: steps and decisions.
- Experience-over-time maps (journey map, customer journey, experience map) — what a person goes through, including feelings and touchpoints beyond the product. Unit: stages and emotions.
- System-centered flows (state flow, data flow, system flow, decision flow) — what the software is and does at each moment. Unit: states, events, and data.
- Service & business flows (service blueprint, process flow, workflow, swimlane, multi-user) — how people, roles, systems, and policies cooperate to deliver the experience. Unit: actors and lanes.
Real projects use several together: a checkout needs a user flow (path), a state flow (every screen's loading/error/success states), a service blueprint (payment processor, fraud check, fulfillment), and an error flow (declines, timeouts). The overlap is a feature — each answers a different question about the same experience.
Which flow should I use?
| The question you're asking | Use |
|---|---|
| What path does the user take (all routes)? | User flow |
| What's the ideal path for one task? | Task flow |
| What does the user experience and feel over time? | Journey map |
| What's the whole customer relationship, beyond the product? | Customer journey map |
| What's the whole real-world experience, beyond our touchpoints? | Experience map |
| What happens behind the scenes to deliver this? | Service blueprint |
| Which screens, in what sequence? | Screen flow / wireflow |
| How do users move through the structure? | Navigation flow |
| How is everything organized and named? | Information architecture |
| Where does logic branch? | Decision flow |
| What are the operational steps? | Process flow |
| How do roles complete work together? | Workflow diagram |
| What states can this screen/component be in? | State flow |
| What can go wrong, and how do users recover? | Error flow |
| How do multiple actors/lanes interact? | Swimlane / multi-user |
| How does information move through the system? | Data flow / system flow |
| How does a dialogue with an AI/bot/voice UI unfold? | Conversation flow |
| How does someone move and act in 3D space? | XR interaction flow |
| Full experience, first ad to renewal? | End-to-end flow |
Decision help in depth: Flow Selection Guide. Master checklists: Flow Design Checklists. Worked examples: Examples Library.
How this section relates to the rest of the library
Flow files describe HOW TO MAP; the pattern files describe WHAT GOOD LOOKS LIKE on the resulting screens. Authentication flow (15) maps the routes; Privacy & Security UX holds the passkey/2FA best practices. Checkout flow (17) maps the branches; Forms & Input holds the field-level evidence. Same for onboarding (16 ↔ onboarding-empty-states), notifications (21 ↔ notifications-communication), conversation/voice (26–27 ↔ ai-interfaces, voice), XR (28 ↔ vr, ar), IA (10 ↔ information-architecture in 07-process-strategy). Use both together.
How an AI assistant (or Claude Code) should use these files
- At project start, read this overview + Flow Selection Guide; pick the 2–4 flow types the project actually needs.
- Draft flows as text diagrams (the notation used throughout:
Step → Step, indented branches) BEFORE proposing screens or code. - Walk every flow through Flow Design Checklists — especially error/empty/loading paths and permissions, which are the steps AI code generation most often skips.
- Keep the flow in the repo next to the code it describes; update it when behavior changes. A stale flow is worse than none.
Conventions used in this section
- Text-first diagrams (arrows and indents) so flows live in version control, diffs, and AI context windows — tools come later, if at all.
- Every file: definition → when to use → what it answers → what it includes → how to build it → mistakes → example(s) → checklist.
- Happy path is never enough: every flow shows at least the happy, error, and abandonment paths, plus empty/loading states where screens are involved.
- Terms in this field overlap and vendors blur them; each file states its working definition and names the near-synonyms rather than pretending the industry agrees.
Sources
- Nielsen Norman Group — "UX Mapping Methods Compared: A Cheat Sheet" (Gibbons); "User Journeys vs. User Flows"; "Journey Mapping 101"; "Service Blueprints 101"; "Wireflows" (nngroup.com).
- Shostack, G. L. (1984). "Designing Services That Deliver." Harvard Business Review — origin of the service blueprint.
- Kalbach, J. (2016; 2nd ed. 2020). Mapping Experiences. O'Reilly — the alignment-diagram framing spanning journeys/blueprints/models.
- Harel, D. (1987). "Statecharts: a visual formalism for complex systems." Science of Computer Programming, 8(3) — state diagrams.
- Object Management Group — BPMN 2.0 specification (omg.org/bpmn) — process/swimlane notation.
- Cooper, A. et al. (2014). About Face (4th ed.) — scenarios and flow-before-form.