User Flow Template: Six Observable Paths You Can Adapt

Build the flow around one observable task

Start with a user-recognizable goal, not the product navigation or internal organization chart. Then make the interface states and branch results explicit enough for design, engineering, QA, accessibility, and operations reviewers to challenge the same model.

1. Bound one actor, task, entry, and outcome

   Name the specific actor and the one task they recognize. Record where the path begins, what observable result counts as success, and which adjacent task is outside scope. Figma describes user flows as steps toward a specific task, while GOV.UK recommends scoping transactions around a problem users recognize instead of organizational structure.

   Sources: [figma-user-flow], [govuk-service-scope]

2. Turn screens and dynamic results into explicit nodes

   Give every screen, waiting state, error, review, confirmation, and safe exit a stable ID. Describe what the person can perceive and do, not only the database state. W3C guidance makes error identification and status changes concrete accessibility concerns, so an unlabeled spinner or silent failure is not a complete flow node.

   Sources: [user-flow-pack], [wcag-error-identification], [wcag-status-messages]

3. Write branches as conditions with visible results

   For every transition, name the trigger, condition, destination, observable result, and retry rule. Decisions need at least two result branches. Errors need a recovery or safe exit. Preserve a meaningful focus sequence when a branch changes the interface, and never show success before the relevant result is confirmed.

   Sources: [user-flow-pack], [wcag-focus-order], [wcag-status-messages]

4. Validate the graph before drawing detailed screens

   Run the included checks for unknown references, duplicate IDs, unreachable nodes, dead ends, terminal exits, one-way error traps, missing branch coverage, and generated-file drift. Then review the model with real user evidence and only afterward hand approved nodes to wireframes, implementation stories, tests, and operational workflows.

   Sources: [user-flow-pack], [figma-user-flow], [govuk-service-scope]

What this user flow resource owns

The pack owns observable task navigation: which surface or state a person sees, what causes each transition, how results branch, and how the person reaches recovery, success, or a safe exit. Adjacent planning artifacts keep their own jobs.

Six user flow examples and the risk each exposes

Each example focuses on a person moving through interface states. The examples deliberately stop before the deeper record lifecycle or provider workflow so teams can connect, rather than confuse, those separate artifacts.

Choose the right planning artifact before you draw

A user flow is useful when the unresolved question is how one person reaches an outcome through interface states. Use these stop rules to keep neighboring artifacts from collapsing into one overloaded diagram.

1. The question is which pages exist and how they are organized

   Choose: Use a website sitemap or information-architecture inventory, then start a user flow only for a bounded task that crosses those pages.

   Tradeoff: You maintain two connected artifacts, but page ownership and task behavior remain independently reviewable.

2. The question is what one page looks like or contains

   Choose: Use a wireframe for regions, content priority, responsive order, and controls. Link each flow node to the relevant wireframe version.

   Tradeoff: The flow stays visually sparse, while page-level layout gets enough detail for design review.

3. The question is what a backlog item must deliver

   Choose: Write a user story with acceptance evidence and reference the approved flow nodes and transitions instead of copying the whole diagram into the story.

   Tradeoff: Traceability takes deliberate IDs, but implementation slices do not silently redefine the task path.

4. The question is how a durable record moves across actors or systems

   Choose: Use a workflow state table for authoritative states, guards, side effects, retries, and audit. Keep the user flow focused on what one person sees and does.

   Tradeoff: The UI path and business process require reconciliation, but provider or record failures no longer disappear behind a screen arrow.

5. A branch has no visible result, recovery, or safe exit

   Choose: Keep the flow in review. Add the observable state and terminal path before detailed wireframes or implementation stories begin.

   Tradeoff: Design starts later, but the team avoids polishing a path that can trap or mislead the person.

What the template cannot prove

A structurally valid graph makes missing states easier to find. It does not prove that the chosen task, policy, copy, interaction, or implementation is correct for real people.

• The six examples are fictional provider-neutral planning records, not customer flows, product screenshots, or recommended business policy.
• Reachability and branch checks cannot prove user research, comprehension, task success, accessibility conformance, or usability.
• A visible UI state does not prove durable storage, authorization, idempotency, provider delivery, audit, retention, or recovery.
• The Mermaid overview is a review view, not a replacement for the JSON source, interface specifications, tests, or operational diagrams.
• The ZIP is verified locally but not publicly available until an authorized environment serves the exact bytes with the correct content type.
• This ordinary informational article does not claim a native user-flow generator or grant AI signup credits.

Sources and verification record

Current primary and first-party guidance supports the one-task scope, interface-state, error, status, and focus boundaries. The six models, fields, checks, examples, and adaptation rules are original Playcode editorial work.

1. [user-flow-pack] Playcode:User flow examples JSON model

   Checked August 1, 2026. Supports: The six fictional flows, 61 observable nodes, 75 transitions, scope boundaries, acceptance checks, generated views, and structural validation described in this guide. Public availability remains unverified until deployment.

2. [figma-user-flow] Figma:What Is a User Flow?

   Checked August 1, 2026. Supports: Defining a user flow around one actor and goal, entry, meaningful steps, decisions, endpoint, and the distinction from wireframes, journey maps, task flows, and sitemaps.

3. [govuk-service-scope] GOV.UK Service Manual:Getting the Scope of Your Transaction Right

   Checked August 1, 2026. Supports: Scoping a transaction around one user-recognizable task and connecting it coherently to a wider journey without copying organizational structure into the experience.

4. [wcag-error-identification] W3C Web Accessibility Initiative:Understanding Error Identification

   Checked August 1, 2026. Supports: Making detected input errors identifiable and describing them in text so a person knows what failed.

5. [wcag-status-messages] W3C Web Accessibility Initiative:Understanding Status Messages

   Checked August 1, 2026. Supports: Exposing success, results, waiting, progress, and error status so assistive technologies can present important changes without unnecessary focus movement.

6. [wcag-focus-order] W3C Web Accessibility Initiative:Understanding Focus Order

   Checked August 1, 2026. Supports: Preserving meaning and operability when people navigate sequentially through interactive content and changed interface states.

User flow template questions