User Flow Documentation Template

What This Template Is For

A user flow documents the step-by-step path a user takes to complete a specific task in your product. It maps every screen, decision point, and edge case between the entry point and the goal. Without documented flows, designers build screens in isolation, engineers discover missing states mid-sprint, and QA does not know what to test.

The difference between a user flow and a customer journey map is scope. A journey map covers the entire relationship (awareness through retention) across channels. A user flow covers one task, within one product, from start to finish. You need both, but user flows are the ones that directly drive design and engineering work.

This template covers three layers of each flow: the happy path (everything goes right), alternative paths (valid but less common routes), and error paths (what happens when something goes wrong). Most teams document the happy path and skip the rest. That is why users encounter blank screens, cryptic error messages, and dead ends. This template prevents that. It pairs well with the information architecture template for understanding where flows sit within the product structure. For validating flows with real users, use the usability test report template. Teams doing product discovery create flow diagrams as part of the design phase, between research and wireframing.

How to Use This Template

1. Start with the Flow Overview. Define the user, the entry point, the goal, and the preconditions. If you cannot clearly state the goal in one sentence, the flow is too broad. Split it.
2. Map the happy path first. Walk through the ideal scenario where the user completes the task without errors, detours, or unusual conditions. List each screen or state in sequence.
3. Add decision points. Every place where the user (or the system) makes a choice that changes the path. Label each branch clearly.
4. Map alternative paths. These are valid but less common routes (e.g., returning user vs. new user, guest checkout vs. logged-in checkout). They are not errors. They are legitimate variations.
5. Map error paths. For every input, API call, or system operation, document what happens when it fails. The most common missing flows are: network error, invalid input, expired session, permission denied, and empty state.
6. Document edge cases in a separate table. These are unusual conditions that require specific handling (e.g., cart with 100 items, username with special characters, user in an unsupported timezone).

The Template

Flow Overview

Preconditions: [What must be true before the user enters this flow]

• ☐ [e.g., User has an account]
• ☐ [e.g., User has items in cart]
• ☐ [e.g., User has verified email]

Postconditions: [What is true after the flow completes successfully]

• ☐ [e.g., Order is placed and confirmation email sent]
• ☐ [e.g., User account is created and session is active]

Happy Path

The ideal scenario where everything goes right.

Decision Points

Alternative Paths

Legitimate variations from the happy path.

Alt Path 1: [Name, e.g., "Returning User"]

Trigger: [What condition creates this variation]

Rejoins happy path at: [Step #]

Alt Path 2: [Name]

Trigger: [Condition]

Rejoins happy path at: [Step #]

Error Paths

What happens when something goes wrong.

Common error conditions to check:

• ☐ Network failure (offline, timeout, 500 error)
• ☐ Invalid input (wrong format, too long, empty required field)
• ☐ Authentication failure (expired session, wrong credentials)
• ☐ Authorization failure (insufficient permissions)
• ☐ Not found (deleted resource, broken link)
• ☐ Rate limiting (too many requests)
• ☐ Empty state (no data to display)

Edge Cases

Flow Diagram

[Entry Point]
    │
    ▼
[Step 1: Screen Name]
    │
    ▼
[Decision Point D1] ─── Condition B ──→ [Alt Path]
    │                                        │
    Condition A                              │
    │                                        │
    ▼                                        │
[Step 2: Screen Name]                       │
    │                                        │
    ▼                                        │
[Step 3: Screen Name] ← ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
    │
    │── Error ──→ [Error State] ──→ [Recovery]
    │
    ▼
[Success State]

(Replace with a FigJam, Miro, or Whimsical diagram link for the actual visual.)

Filled Example: E-Commerce Checkout Flow

Flow Overview

Happy Path

Decision Points

Error Paths

Edge Cases

Key Takeaways

• Document three layers: happy path, alternative paths, and error paths. Most bugs and UX failures live in the last two
• Define the goal in one sentence. If you cannot, the flow is too broad
• Every decision point should have clear branch conditions and labeled paths
• Error messages should state the problem and suggest recovery. "Error 500" is not a user-facing message
• Review and update flows when usability testing or analytics reveal that users take a different path than documented

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use