Task Flow

A task flow maps ONE task as a single, linear, ideal path — no branching, no decision diamonds. Every user is assumed to take the same steps in the same order. This is the standard industry distinction (IxDF, "What Are User Flows?": task flows are linear and "tend not to branch out with options or decision points"; user flows show the many paths and choices): task flow = the one shared backbone; user flow = all the routes. If you find yourself drawing a diamond, you've outgrown the task flow.

When to use

Before wireframes — this is the point. A task flow is the cheapest possible agreement on what the steps are, before anyone argues about what the screens look like. Ten minutes of task flow prevents a sprint of wireframing the wrong sequence.
At kickoff, to get PM/eng/design saying the same step names.
As the skeleton you later grow into a user flow (add branches), a screen flow (add real screens and transient states), and an error flow (add failures).
When comparing your product's step count to a competitor's.

What it answers

What are the steps, in order? How many are there? Which steps belong to the user and which to the system? Where does the task start and end?

What it includes

A named task with a clear trigger and a clear end state.
Numbered or arrowed steps — verbs, user's vocabulary, one action per step ("Enter email," not "Handle credentials").
Who acts at each step if it matters (user vs. system) — but if you need lanes, you want a swimlane flow.
A failure ledger under the diagram (convention used in this library): the diagram stays linear, but you still list what can go wrong and where users bail, as bullets below it. A task flow that has never considered errors isn't simple, it's blind — the branches just move to the user flow instead of disappearing.

Relation to task analysis

Task analysis is the research; task flow is a design artifact informed by it. NN/g ("Task Analysis: Support Users in Achieving Their Goals," Rosala, nngroup.com): task analysis is the systematic study of how users actually accomplish their goals — the steps, sequence, tools, and context — so products support real behavior rather than assumed behavior. Do the analysis first (observe, interview, walk the current workaround), then draw the flow. A task flow drawn without task analysis documents the team's guess.

How to build one

Pick one task, one persona, one trigger. Write the end state.
From task analysis, list the real steps users take today.
Cut steps the product can absorb (auto-detect, defaults, prefill).
Order what remains; one verb per step; number them.
List known failure points and abandonment moments below the diagram.
Only then wireframe — one step ≈ one screen is the starting bid, not a rule.

Common mistakes

Branching creep. "But what if they…" — that's the user flow's job. Park branches in the failure ledger and keep the line straight.
Steps at click-level granularity ("tap field, type, tap next field") — that altitude belongs in a screen flow.
Modeling the org's internal process, not the user's task ("Submit to review queue" is your workflow — see workflow).
Skipping task analysis and drawing the flow from the roadmap.
Treating the linear diagram as the whole design — shipping it without ever growing the error and abandonment branches elsewhere.

Example — password reset

Task: regain account access after a forgotten password.

[Login] → tap "Forgot password" → [Enter email] → submit
  → check email → open reset link → [Reset password]
  → enter new password → [Login] → sign in with new password ✓

Failure ledger (handled in the user/error flow, not drawn here):

Email not registered — same "sent" message either way (don't leak which emails exist); user abandons if they typo'd the address.
Reset email never arrives / lands in spam → resend path needed.
Link expired or already used → error page with restart path.
New password rejected by rules → inline requirements, input kept.
User abandons at "check email" — the most common exit; the reset email's subject line is part of this flow.

Example — drone-mapping upload

Task: turn a folder of drone photos into a viewable map.

[Dashboard] → New Project → [Upload Images] → select files
  → [Confirm Coordinate System] (prefilled from EXIF) → confirm
  → Start Processing → (processing) → [View Map] ✓

Failure ledger:

Images missing GPS EXIF → coordinate system can't be prefilled; manual selection is the alternate path (user flow territory).
Upload interrupted (connection drop) → resumable upload + retry.
Processing fails (insufficient overlap) → actionable error naming the fix, not "Error 500."
User closes the tab during processing → job continues; notify by email with a deep link back (recovery).

Checklist

One task, one persona, one trigger, one end state — all named.
Zero branches; every diamond evicted to the user flow.
Steps are verbs in user vocabulary, one action each.
Grounded in task analysis (observed behavior), not the roadmap.
Failure ledger listed beneath the diagram, with owners (user flow / error flow) for each item.
Step count challenged — can the system absorb any step?
Drawn before wireframes, and referenced when wireframing starts.

Sources

Interaction Design Foundation — "What Are User Flows?" (interaction-design.org/literature/topics/user-flows) — task flows as the linear, non-branching case.
Nielsen Norman Group — "Task Analysis: Support Users in Achieving Their Goals" (Rosala), nngroup.com/articles/task-analysis/; "User Journeys vs. User Flows" (Laubheimer), nngroup.com.
Cooper, A. et al. (2014). About Face (4th ed.) — scenarios drive sequence before screens.
The "failure ledger" beneath a linear diagram is a convention of this library, not an industry standard term.