User Flow

A user flow is a diagram of the path a user takes through a product to complete one goal — including ALL realistic routes, not just the ideal one. NN/g's distinction: a user journey is the holistic, cross-channel experience of a high-level goal over days or months; a user flow is the granular set of in-product interactions for one specific objective, completed in minutes ("User Journeys vs. User Flows," nngroup.com). Emotions and phone calls belong in a journey map; screens and decisions live here.

The five path types (define all of them, every time)

Happy path — everything goes right; the shortest realistic route from entry to goal.
Alternate paths — legitimate different routes to the same goal (search vs. browse; guest vs. logged-in checkout). Not failures.
Error paths — something goes wrong (validation failure, payment decline, timeout) and what the user sees and can do next.
Abandonment paths — the user exits without completing. Where, and to what? Exits are outcomes, not gaps.
Recovery paths — the route back to completion after an error or abandonment (retry, saved cart + reminder email, resume draft).

When to use

Before wireframes, after you know the goal and the users — when the question is "what are all the ways this can go?"
When conversion drops somewhere and nobody can say where; the flow makes drop-off points discussable.
When a task flow (single ideal path) is agreed and you now need the branches.

What it answers

Where do users enter? What decisions do they face, in what order? Where can they fail, quit, or loop? Steps to the goal, per route?

What to include

Entry points — all of them. Users arrive from search results, ads, emails, deep links, and shared URLs, not just your homepage. Each real entry point is a starting node.
Steps as rectangles/plain lines; decisions as diamonds written as questions ("Card authorized?") with every outgoing branch labeled (yes/no/timeout). An unlabeled branch is an undesigned behavior.
Exits — success exits and abandonment exits, both explicit.
Page vs. action notation (convention, not standard): distinguish "user is on a screen" from "user/system does a thing." In text diagrams: [Screen] for pages, plain text for actions, (state) for transient system states. State your key; vendors' shapes differ.
One goal per diagram. Scope creep here is how flows become unreadable.

How to build one

Write the goal as a sentence: "A first-time visitor buys shoes."
List real entry points (analytics tells you; assumption doesn't).
Draft the happy path as a task flow first.
At each step ask: what else could the user want, do, or hit? Add alternate, error, and abandonment branches with labeled decisions.
Add recovery: for each error/abandon exit, is there a way back?
Walk it with someone who didn't draw it; fix where they stumble.

Common mistakes

Happy-path-only. The most common and most expensive mistake; the errors and exits are where the design work actually is.
Mixing altitudes — journey-level stages ("Awareness") or pixel-level details ("tap the blue 44pt button") in one diagram. A user flow lives between the two: steps and decisions.
Starting at the homepage when analytics shows most users enter a product page from search or an ad and never see the homepage.
Decisions with unlabeled or missing branches ("no" goes nowhere).
No abandonment paths — as if users are locked in until they convert.
Drawing the sitemap and calling it a flow — structure isn't movement; see navigation flow and IA for flows.

Example — e-commerce purchase

Entry: Google search → [Product page]   (most common entry)
Entry: Instagram ad  → [Landing page]
Entry: direct        → [Homepage] → Search "trail shoes" → [Results]

[Results] → Found a candidate?
  ├─ yes → [Product page]
  └─ no  → Refine filters → [Results]  (loop, max patience ~2–3 tries)
           └─ still no → EXIT: abandon to competitor   [abandonment]

[Product page] → Size in stock?
  ├─ yes → Add to Cart → [Cart] → Checkout
  └─ no  → "Notify me" email capture → EXIT            [abandonment]
           └─ back-in-stock email → [Product page]     [recovery]

Checkout → Has account?
  ├─ yes → Login → [Payment]        (login failure → see error below)
  └─ no  → Guest checkout → [Payment]                  [alternate]

[Payment] → Card authorized?
  ├─ yes → [Confirmation]  ✓ GOAL
  ├─ declined → inline error, cart intact → retry / other method  [error]
  └─ user closes tab → cart saved → reminder email →
       deep link back to [Cart]                        [recovery]

Example — SaaS (drone-mapping app)

[Login] → Credentials valid?
  ├─ no  → inline error, input preserved → retry / reset password  [error]
  └─ yes → [Dashboard] → Create Project → [Upload]

[Upload] → Files valid (format, count, GPS data)?
  ├─ no  → per-file error list → replace files → revalidate        [error]
  └─ yes → [Configure] → Start → (Processing…)

(Processing…) → Succeeded?
  ├─ yes → [Results]  ✓ GOAL
  ├─ no  → error screen: cause + retry + contact support           [error]
  └─ user closes app mid-process → job continues server-side →
       email "your map is ready" → deep link to [Results]          [recovery]

Combine with: a state flow for per-screen states, and an error flow when a failure branch deserves its own map (payments almost always do). Grow the drawn steps into a screen flow once wireframes exist.

Checklist

One goal, stated in one sentence at the top of the diagram.
Every real entry point shown (checked against analytics).
Happy + alternate + error + abandonment + recovery paths present.
Every decision is a question; every branch is labeled.
Every exit (success and abandon) is explicit.
Notation key stated (page vs. action vs. transient state).
Step count per route counted — is the happy path defensible?
Walked through by someone who didn't draw it.

Sources

Nielsen Norman Group — "User Journeys vs. User Flows" (Laubheimer), nngroup.com/articles/user-journeys-vs-user-flows/ — the scope distinction used here; "UX Mapping Methods Compared: A Cheat Sheet" (Gibbons), nngroup.com.
Interaction Design Foundation — "What Are User Flows?" (interaction-design.org/literature/topics/user-flows) — user flows branch; task flows don't.
Cooper, A. et al. (2014). About Face (4th ed.) — flow before form.
Shape conventions (rectangles = steps, diamonds = decisions) come from classic flowcharting — convention, not standard; state your key.