Decision Flow

A decision flow maps the conditional logic of an experience: every point where the product asks a question about the user, the data, or the situation, and routes differently depending on the answer. Where a user flow (User Flow) follows a person's path, a decision flow follows the logic — the if/then/else skeleton the paths hang on. Near-synonyms you'll meet: decision tree, logic flow, branching logic, conditional flow. This file's working definition: a flow whose primary unit is the decision point, not the step or the screen.

When to use one

Authentication: logged in? session expired? 2FA enrolled? device trusted? account locked? (pairs with Authentication Flows and Privacy & Security UX).
Permissions and roles: can this user see/edit/delete this? What does each denial actually show?
Onboarding branching: new vs. returning, invited vs. organic, imported data vs. empty start (Onboarding Flows).
Checkout: guest vs. account, payment method, address validation, stock check, discount eligibility (Checkout Flows).
Eligibility and qualification: does the applicant/plan/region qualify, and what happens to everyone who doesn't?
Form logic: which fields appear, which validations fire, in what order (Forms & Input).
AI agent routing: which intent, which tool, which fallback when confidence is low — modern agent routers are decision flows, and drawing them exposes the "low confidence" branch teams forget (Conversation Flow, Designing AI-Powered Interfaces).

What it answers

What questions does the system ask? What are ALL the possible answers (not just yes/no)? Where does each answer lead? What happens by default when no condition matches? Which branches are policy decisions nobody has actually made yet?

Notation

Flowcharting convention draws decisions as diamonds with one entering arrow and labeled exits — a convention standardized from ANSI X3.5 (1963) into ISO 5807:1985, not a law of nature. In this library's text-first style, a decision is a question with indented outcomes:

Is user logged in?
├── yes → Dashboard
└── no  → Login screen

Rules that make the notation honest:

Phrase decisions as answerable questions ("Is payment method saved?"), not vague topics ("Payment check").
Label every exit arrow with the answer it represents.
Decisions can have more than two exits — forcing everything into yes/no hides the real cases (see example below).
Every branch terminates somewhere real: a screen, a message, an end state, or a named jump to another flow. A dangling arrow in the diagram becomes a dead end in the product.
Every decision has a default/else branch. "What if none of the above?" is the branch that catches corrupted data, new enum values, and race conditions. If you can't name the else case, the flow is incomplete.

Is user logged in?
├── yes → Dashboard
├── no → Login screen
│    ├── credentials valid → Dashboard
│    ├── credentials invalid (attempt < 5) → Error message, retry
│    ├── credentials invalid (attempt = 5) → Account locked
│    │    └── Locked notice → Contact Support / wait 30 min
│    └── "Forgot password" → Reset flow (see Error Flow for
│         the expired-token and email-never-arrives branches)
└── session expired (was logged in) → Re-auth prompt, return to
     the page they were on — not the dashboard

Note the failure branches are most of the diagram. That's typical and correct: the happy path is one line; the logic lives in the rest.

Decision flows expose policy questions

The highest-value output of drawing a decision flow is usually a list of questions for product, legal, or security — because every diamond needs an answer someone with authority must give. From the example above: How many failed attempts before lockout? Lockout for how long — and does "Contact Support" mean a human or a form? Does "forgot password" work on a locked account? Do we tell the user the account is locked, or is that an account-enumeration leak (security says the error must be vague; UX says vague errors are cruel — someone must decide)? Designers who present a flow with named, unanswered diamonds get decisions made in a meeting; designers who skip the flow discover the answers in a bug report.

Common mistakes

Yes/no framing on multi-way decisions (login isn't binary: valid, invalid, locked, expired, unverified email, SSO-only account…).
No else branch — the flow silently assumes clean data forever.
Branches that end in "…" or an arrow to nowhere.
Encoding policy you invented: a flow diagram makes made-up rules look official. Mark assumptions ([ASSUMED — confirm with X]).
Drawing logic the backend owns without checking it — the flow must match the actual rules engine, or it's fiction.
Depth without grouping: past ~3 levels of nesting, split into named sub-flows and link them.

Checklist

Every decision is phrased as an answerable question.
Every exit arrow is labeled with its answer.
Multi-way decisions have all their real exits, not a forced yes/no.
Every decision has a default/else branch.
Every branch terminates at a screen, message, end state, or named flow — no dangling arrows.
Failure and lockout branches are drawn, not implied (Error Flow).
Assumed policies are marked and on a list for the owner to confirm.
Logic matches what the backend actually enforces.
Nesting deeper than ~3 levels is split into linked sub-flows.

Sources

ISO 5807:1985 — Information processing — Documentation symbols and conventions for data, program and system flowcharts — the decision diamond and flowchart symbol conventions (successor to ANSI X3.5, first published 1963).
Goldstine, H. & von Neumann, J. (1947). Planning and Coding of Problems for an Electronic Computing Instrument — the original program flowcharts, including decision branches.
Object Management Group — BPMN 2.0 specification (omg.org/spec/BPMN; v2.0.2, 2014) — gateways as the formalized decision notation.