QUICK ANSWER
What is the difference between a user flow and a user journey?
A user flow maps the screens, visible states, actions, decisions, errors, recovery paths, and exits inside one bounded interface task. A user journey maps a person's broader experience across stages, channels, touchpoints, waiting, context, and research evidence before, during, and after that task. A journey can contain several digital flows, while one reusable flow may support several journeys.
A user flow maps how one person moves through observable interface screens and states to complete a bounded task. A user journey maps the wider experience around a goal across stages, channels, touchpoints, context, waiting, support, and evidence about what the person does, thinks, or feels. Both can use boxes and arrows, but they should not own the same question.
The strongest relationship is composition. A journey can expose a difficult digital touchpoint, then link to a user flow that specifies the entry, decisions, errors, recovery, success, and safe exit inside that task. The flow returns tested behavior and operational findings without claiming it represents everything before or after the interface.
Start with the unresolved question and observable evidence
A map is useful only when its boundary tells reviewers what they can decide. Use these five passes before drawing stages, screens, emotions, or branches.
Name the person's whole problem and the bounded task
Describe the broader outcome in language supported by research, then identify the specific interface task within it. The journey owns the experience around the whole problem; the flow owns only the observable path through the selected digital task.
Sources: [govuk-whole-problem], [govuk-user-needs], [figma-user-flow]
Collect evidence before drawing sentiment
Use interviews, observations, analytics, search logs, support evidence, or other authorized records to identify what happened and what people thought or felt. Record unknowns explicitly. Do not add an emotion curve or satisfaction score merely because the template has room for one.
Sources: [govuk-experience-map], [govuk-user-needs], [ico-data-minimisation]
Model the interface in observable states
Give the flow a clear entry, screen or visible state at every node, user or system trigger on each transition, meaningful decision conditions, visible results, errors, retry rules, recovery, success, and a safe exit. Keep offline and organizational activity in the linked journey or service record.
Sources: [figma-user-flow], [govuk-scope-service], [wcag-error-identification], [wcag-status-messages]
Link the touchpoint to the exact flow version
Give journey stages and touchpoints stable IDs. Link the selected digital touchpoint to the current user-flow ID and version, then link flow outcomes back to the affected journey stage. Preserve gaps and alternatives rather than copying screen nodes into the journey.
Sources: [govuk-whole-problem], [figma-user-flow], [govuk-experience-map]
Review on evidence and system changes
Revisit the journey when research, channels, policies, support paths, waiting, or service ownership changes. Revisit the flow when screens, states, validation, errors, provider behavior, recovery, or entry conditions change. Reconcile links after either review.
Sources: [govuk-user-needs], [govuk-whole-problem], [figma-user-flow], [wcag-error-identification]
The owner boundary for this comparison
This page owns the choice and handoff between a user journey and a user flow. The two template owners retain editable artifacts, and adjacent UX and service records retain their own decisions.
Included
- A criterion-by-criterion comparison of scope, time, structure, channels, branches, evidence, ownership, traceability, and maintenance
- One fictional support experience shown at journey scope and as a bounded support-request flow slice
- Rules for choosing a flow, journey, linked pair, or a different planning artifact
- A versioned touchpoint-to-flow link contract that keeps evidence and interface behavior separately reviewable
- A two-way internal-link contract: this comparison links both template owners, while each template keeps a concise difference FAQ that points back to this full decision guide
Not included
- The editable user-flow artifact and download intent owned by /blog/user-flow-template
- The editable journey-map artifact and download intent owned by /blog/customer-journey-map-template
- A separate user-journey-map template alias, customer-journey versus user-journey taxonomy owner, service blueprint, sitemap, wireframe, persona, workflow, research repository, or analytics dashboard
- An invented emotion score, universal stage model, assumed customer motive, or claim that every team distinguishes user and customer journeys identically
- Production behavior, research consent, privacy approval, accessibility conformance, operational performance, or proof that a service outcome works
Ten criteria for choosing a user flow, journey, or linked pair
Apply every row to the same user job. The map type follows the decision and evidence boundary, not the drawing tool or whether the diagram happens to run left to right.
Decision question
Separates a bounded interface task from the wider experience in which that task begins, continues, and affects trust.
Time and scope
Prevents a screen path from pretending to explain the whole experience or a journey map from becoming an unreadable interaction specification.
Structure and sequence
Shows whether the model needs observable state transitions or evidence-backed stages and touchpoints over time.
Channels and touchpoints
Makes clear whether the boundary stays inside one interface or crosses search, people, messages, waiting, and service operations.
Branches, errors, and recovery
Keeps visible errors, retries, alternate entries, safe exits, and recovery from disappearing behind a happy-path arrow.
Evidence and context
Distinguishes observed research and operational evidence from invented emotions, assumed motives, or decorative scores.
Ownership and collaboration
Assigns the interface behavior and the wider service experience to the roles that can review and change each boundary.
Composition and traceability
Connects a high-friction journey touchpoint to the exact flow version that implements it without copying either model.
Maintenance trigger
Keeps paths, channels, evidence, service rules, and linked artifacts current as the real experience changes.
Paired support example
Shows the same fictional help-seeking job first as an end-to-end journey and then as one bounded website flow slice.
User flow and user journey decision matrix
Neither map is more complete in every context. Choose the smallest boundary that answers the current question, then compose them when one digital task must remain traceable to a wider experience.
User flow
Best for: One bounded digital task whose screens, states, actions, decisions, errors, recovery, success, and safe exit need review.
Use a user flow to make observable interface behavior reviewable before layout polish or implementation hides missing states. Keep every transition tied to a visible result and stop at the boundary of the selected task.
| Criterion | Finding |
|---|---|
| Decision question | Own how one person reaches one observable result through a digital interface, including what they see and can do at each state. Sources: [figma-user-flow], [govuk-scope-service] |
| Time and scope | Begin at a named interface entry and end at success, a recoverable stop, or a safe exit. Do not imply the task boundary represents the entire relationship or service experience. Sources: [figma-user-flow], [govuk-scope-service] |
| Structure and sequence | Use observable screens or states connected by user or system triggers, decision conditions, and visible results. Keep the graph reviewable without turning it into a pixel-level wireframe. Sources: [figma-user-flow], [wcag-status-messages] |
| Channels and touchpoints | Model the selected website or app path and link external channels at explicit entry or exit points. The flow should not absorb phone, email, staff, or offline stages it cannot observe. Sources: [figma-user-flow], [govuk-whole-problem] |
| Branches, errors, and recovery | Show meaningful decisions, validation failures, unavailable states, retry behavior, preserved work, recovery, success, and a safe exit instead of drawing only the ideal path. Sources: [figma-user-flow], [wcag-error-identification], [wcag-status-messages] |
| Evidence and context | Ground entries and branches in current requirements, research, analytics, support evidence, or tested behavior. Label assumptions and do not attach invented emotions to screen nodes. Sources: [govuk-user-needs], [figma-user-flow] |
| Ownership and collaboration | Give product, design, engineering, content, accessibility, and operations reviewers explicit ownership for the states and handoffs they can verify. The diagram itself grants no authority. Sources: [govuk-scope-service], [wcag-error-identification], [wcag-status-messages] |
| Composition and traceability | Link the flow ID and version to the journey touchpoints it implements, plus the reviewed requirements, wireframes, workflow states, and tests that own adjacent detail. Sources: [figma-user-flow], [govuk-whole-problem] |
| Maintenance trigger | Review when screens, states, copy, validation, providers, permissions, errors, recovery, entry conditions, or linked requirements change, then recheck the affected journey touchpoints. Sources: [figma-user-flow], [wcag-error-identification], [wcag-status-messages] |
| Paired support example | At support.example.test, the bounded flow starts when a person leaves a help article to request support, then shows category selection, a sanitized summary, review, submit, and a visible pending receipt. It branches for missing input, duplicate request, connection loss, preserved draft, retry, and safe exit without claiming a real support outcome. Sources: [figma-user-flow], [wcag-error-identification], [wcag-status-messages] |
Tradeoffs
- A precise path exposes branches and recovery inside the interface, but it can hide why the person arrived, what other channels they used, and what happens after the terminal state.
- Adding every support interaction, policy, backstage activity, emotion, and operational handoff makes the flow unreadable and collapses it into several adjacent artifacts.
User journey
Best for: A person's wider experience of achieving a goal across stages, channels, touchpoints, context, waiting, support, and evidence over time.
Use a user journey to connect what people do across the whole problem with evidence about their context, questions, friction, and outcomes. Keep stages and touchpoints grounded in research and link detailed interface behavior to separate flows.
| Criterion | Finding |
|---|---|
| Decision question | Own how a person experiences the wider goal across the whole problem, including what happens before and after any one digital task. Sources: [govuk-whole-problem], [govuk-experience-map] |
| Time and scope | Span the evidence-backed period needed to understand the goal, from recognition and preparation through completion, waiting, support, and meaningful follow-up. Sources: [govuk-experience-map], [govuk-whole-problem] |
| Structure and sequence | Organize evidence into stages and touchpoints that preserve sequence, context, questions, and outcomes. Do not use the journey as a substitute for screen-state or workflow specifications. Sources: [govuk-experience-map], [govuk-whole-problem] |
| Channels and touchpoints | Include every relevant researched channel and handoff, such as search, website, app, phone, message, staff interaction, waiting, or offline activity, without assuming every participant uses all of them. Sources: [govuk-whole-problem], [govuk-experience-map] |
| Branches, errors, and recovery | Record alternate entries, abandonment, waiting, escalation, channel switching, and recovery as evidence-backed journey variants. Link interface-level error mechanics to the exact user flow. Sources: [govuk-experience-map], [govuk-user-needs] |
| Evidence and context | Attach authorized evidence references for observed actions, questions, thoughts, feelings, constraints, and outcomes. Mark missing evidence rather than drawing a smooth emotional curve from assumption. Sources: [govuk-experience-map], [govuk-user-needs], [ico-data-minimisation] |
| Ownership and collaboration | Assign an accountable journey owner plus contributors for research, product, content, support, operations, policy, and channels. Keep personal research data in its authorized system. Sources: [govuk-whole-problem], [ico-data-minimisation] |
| Composition and traceability | Give stages and touchpoints stable IDs, then link digital touchpoints to current flow versions and service changes. One journey can contain several flows, and a reusable flow can support several journeys. Sources: [govuk-whole-problem], [figma-user-flow] |
| Maintenance trigger | Review when research, user needs, channels, policy, service ownership, support paths, waiting, communications, or observed outcomes change, then reconcile linked flows and open evidence gaps. Sources: [govuk-user-needs], [govuk-whole-problem], [govuk-experience-map] |
| Paired support example | The fictional support journey begins when a person notices an exported file appears incomplete, then spans asking a teammate, searching help, reading guidance, choosing support, waiting for a response, clarifying the problem, applying a resolution, and deciding whether trust is restored. Every feeling or friction point requires a research reference; the website request is only one linked flow slice. Sources: [govuk-experience-map], [govuk-whole-problem], [govuk-user-needs] |
Tradeoffs
- A wider map exposes cross-channel gaps and organizational seams, but it becomes speculative when stages, emotions, or priorities are filled from workshop opinion instead of evidence.
- The journey supports service-level decisions, while it lacks the state and transition detail required to specify one digital interaction safely.
Choose one boundary, then compose only where the evidence connects
Use the smallest map that owns the current decision. A linked pair is justified when the wider experience contains a digital touchpoint whose states and recovery need independent review.
The question is how one person completes a bounded task through interface screens and visible states.
Choose: Use a user flow with explicit entry, branches, errors, recovery, and exits.
Tradeoff: The interaction becomes reviewable, but the flow cannot explain the person's wider context or cross-channel experience.
The question spans discovery, preparation, several channels, waiting, support, context, and what happens after one interface task.
Choose: Use an evidence-backed user journey and link detailed digital tasks separately.
Tradeoff: The service boundary becomes visible, while researchers and owners must keep assumptions and personal data controlled.
Journey evidence identifies a high-friction digital touchpoint whose branch, error, or recovery behavior remains unclear.
Choose: Keep the touchpoint in the journey and create a linked user flow for that bounded task.
Tradeoff: Two models require versioned links, but the journey stays readable and the interface behavior can be tested independently.
The unresolved question is page hierarchy, layout, backstage service operations, durable workflow state, or persona evidence.
Choose: Use a sitemap, wireframe, service blueprint, workflow model, or research owner instead of overloading a flow or journey.
Tradeoff: Review spans connected artifacts, while each map remains focused on the decision it can actually support.
There is no current evidence for the proposed stages, channels, motives, emotions, or interface path.
Choose: Record the hypothesis and research plan first; do not publish a polished journey or flow as if it were observed.
Tradeoff: The team delays diagram polish but avoids using invented certainty to prioritize or implement the wrong behavior.
MODEL THE CONNECTION
Turn one difficult journey touchpoint into a reviewable flow
Describe the person's wider goal, evidence-backed stage, selected digital task, visible states, branches, recovery, and versioned link. Start with one boundary your team can inspect.
Start BuildingThe map does not approve production behavior or prove that the real experience works.
Open the user flow template for the artifact itselfThe comparison owner remains separate from the editable flow and journey-map jobs.
Limits of the distinction
Teams use journey, experience map, customer journey, task flow, and user flow differently. Define the local vocabulary and evidence boundary instead of treating labels as universal standards.
- A journey can zoom into a digital touchpoint and a flow can show context at its entry, but neither should silently absorb the other artifact's lifecycle and evidence.
- A valid graph does not prove that the chosen task or journey is useful, complete, usable, accessible, secure, private, or correctly implemented.
- Emotion curves, satisfaction scores, and personas require evidence and sampling context. Workshop opinion is not a substitute for research with relevant people.
- Do not place names, contact details, raw notes, recordings, secrets, or unnecessary personal data in a shared journey or flow diagram.
- Fictional support.example.test examples show document composition only and do not claim real export, help-center, support, notification, or recovery behavior.
Current sources and evidence boundaries
These sources were checked on August 1, 2026. They support task scoping, user-flow structure, journey research, whole-problem mapping, error and status visibility, and data minimization. The exact comparison matrix and fictional support example remain Playcode editorial synthesis.
[figma-user-flow] Figma:What is a user flow?
Checked August 1, 2026. Supports: User flows as visual paths through a product toward a goal, including entry points, steps, decisions, task flows, wireflows, and review before detailed design.
[govuk-scope-service] GOV.UK Service Manual:Scoping your service
Checked August 1, 2026. Supports: Defining a service boundary around a problem users recognize, understanding dependencies, and avoiding organizational structures as the user-facing scope.
[govuk-experience-map] GOV.UK Service Manual:Researching user experiences
Checked August 1, 2026. Supports: Researching what people did, thought, and felt over time, capturing evidence in sequence, and combining research into an experience map.
[govuk-whole-problem] GOV.UK Service Manual:Map and understand a user's whole problem
Checked August 1, 2026. Supports: Mapping the whole problem across content, services, organizations, channels, and dependencies rather than optimizing one isolated transaction.
[govuk-user-needs] GOV.UK Service Manual:Learning about users and their needs
Checked August 1, 2026. Supports: Evidence-led user needs, continuous research, inclusion of people who struggle with existing services, and explicit treatment of unsupported opinions as assumptions.
[wcag-error-identification] World Wide Web Consortium:Understanding Success Criterion 3.3.1: Error Identification
Checked August 1, 2026. Supports: Programmatically or textually identifying detected input errors and describing them to the user rather than relying on color or an unexplained failed state.
[wcag-status-messages] World Wide Web Consortium:Understanding Success Criterion 4.1.3: Status Messages
Checked August 1, 2026. Supports: Making important status changes available to assistive technology without unnecessary focus movement, supporting observable results and waiting states in a flow.
[ico-data-minimisation] Information Commissioner's Office:Principle (c): Data minimisation
Checked August 1, 2026. Supports: Keeping personal data adequate, relevant, and limited to what is necessary, used here to bound the evidence references stored in shared maps.
User flow and user journey questions
Is a user flow part of a user journey?
It can be. A journey may contain several digital touchpoints, and each complex touchpoint can link to a bounded user flow. Keep the journey stage and flow as separate versioned records so screen changes do not silently rewrite the wider experience.
Can one user flow support several journeys?
Yes. A shared sign-in, request, preference, or status flow may appear in several wider journeys. Link every affected touchpoint and record differences in entry, permissions, context, or outcome instead of assuming the reusable path behaves identically everywhere.
Is a customer journey different from a user journey?
Teams use the terms differently. Customer journey often emphasizes a commercial relationship, while user journey can include any person using a service. This comparison uses user journey for the wider experience and keeps the editable map job with the existing customer journey template owner.
Should a journey map include emotions?
Only when research supports them. Reference the evidence, participant scope, date, and limitations. Do not invent a smooth emotion curve, average incompatible participants, or store unnecessary personal notes in the shared map.
Should a user flow show errors and recovery?
Yes, when those states can occur in the task. Show how an error is identified, what remains preserved, which recovery or retry is available, what the person sees next, and how they can exit safely. A happy path alone is not a complete review surface.
Is a user flow the same as a wireframe?
No. A flow maps states and transitions toward one outcome. A wireframe defines the regions, hierarchy, content, and controls of one screen or page. Link flow nodes to wireframe versions instead of forcing layout detail into the path map.
Is a user journey the same as a service blueprint?
No. A journey centers the person's evidence-backed experience across stages and touchpoints. A service blueprint adds frontstage and backstage roles, processes, systems, dependencies, and lines of interaction. Link them when operational causes need a separate owner.
How often should flows and journeys be updated?
Use event-driven review plus a named cadence. Recheck flows after interface, validation, provider, error, or recovery changes. Recheck journeys after research, channel, policy, support, waiting, or ownership changes. Reconcile the touchpoint-to-flow links after either review.
START WITH ONE EVIDENCE-BOUND PATH
Build the smallest experience workspace that preserves recovery
Give Playcode the reviewed users, stages, touchpoints, states, branches, and evidence links. Keep real research governance, provider behavior, accessibility review, and production verification with their accountable owners.
Start BuildingNo credit card required. AI credits are included to start; production requirements and plan limits still apply.