User Flow Template: Map States, Decisions, and Recovery Paths
By SayCraft Team · 2026-08-27 · 4 min read
A user flow template should map what starts the journey, who performs it, the required state, each user action and system response, decision branches, failure and recovery paths, permission checks, important data changes, and the observable completion state. Stable step IDs make the flow reviewable even when screens change.
Community signal: Screen sequences often omit permissions, data changes, interruptions, and recovery. A state-first flow exposes those branches before visual polish makes the journey look complete.
What a user flow needs to show
A user flow template should map what starts the journey, who performs it, the required state, each user action and system response, decision branches, failure and recovery paths, permission checks, important data changes, and the observable completion state. Stable step IDs make the flow reviewable even when screens change.
Copyable flow-step table
Copy the node and edge notation below, replace bracketed fields, and arrange the finished lines as a visual flow. The text remains an editable source even when the team redraws it in a diagram tool.
Walk the flow with at least two account or permission states when the journey involves shared resources. Read every step aloud as a starting state, action, system response, and next state. If a reviewer cannot explain where data changed, why a branch was allowed, or how failure recovers, keep that point as an explicit design question before adding screens.
- FLOW-[ID] | Goal: [outcome] | Role: [role] | Trigger: [event] | Entry: [state] | Done: [observable evidence]
- START → S01 [starting state] → A01 [user action] → R01 [system response]
- R01 → D01 [decision question?] | YES → S02 [allowed state] | NO → E01 [safe denied state and message]
- E01 → A02 [retry, cancel, or recovery action] → R02 [system response] → S03 [known recovered state]
- At every response | Permission check: [rule owner] | Data read or change: [record] | Audit evidence: [event]
- END-[success] [completion evidence] | END-[cancelled] [preserved state] | END-[failed] [next safe action]
- Trace | Requirements: [IDs] | Acceptance criteria: [IDs] | Test cases: [IDs] | Open questions: [owners]
Workspace-invitation example
A workspace invitation flow begins with an authorized owner, a valid recipient, and a pending invitation. It branches for expired, revoked, already accepted, wrong-account, and temporary-delivery states, and ends only when access and audit evidence match the intended outcome.
- Name the role, trigger, and starting state
- Alternate user action and system response
- Add decisions, failures, and recovery
- Trace the final flow into requirements and tests
Define trigger, role, and starting state
Start with one user goal and the conditions that make the journey possible. Record the role, trigger, entry point, authentication state, relevant object or data state, permission, and desired completion evidence. Then alternate user action and system response with stable step IDs. This prevents a flow from becoming a sequence of screen names that hides what the product must actually do.
Separate navigation from behavior. Moving from screen A to screen B is only useful when the flow also records the user intent, system decision, permission check, data effect, and recovery state. A diagram can look complete while omitting expiration, duplication, cancellation, wrong-account access, or interruption. Review the underlying state table first, then use a visual map to communicate it without hiding unresolved branches.
- Nielsen Norman Group: UX deliverables glossary
- Atlassian: product requirements template
Map decisions, failures, and recovery
Add decision branches where information or authority changes the outcome. Include invalid input, empty state, network failure, expired or revoked objects, duplicate action, wrong account, denied permission, cancellation, interruption, and retry only when relevant. State what is preserved, what changes, what message appears, and where recovery returns the user. A branch with no observable endpoint is an unresolved product question.
Trace the flow into requirements and tests
Review the flow against other product artifacts. Each important branch should trace to a requirement and at least one test case; data creation or mutation should trace to an ownership and retention question; permission checks should not be represented merely by hiding a control. Screens and layout may change while step identities remain stable, allowing the conversation, preview, criteria, and tests to stay aligned.
Limits of a flow diagram
A preview is not evidence of production security, compliance, or launch readiness.
- Every branch has an observable outcome
- Permission and data changes are explicit
- Recovery returns the user to a known state
- The map does not imply production assurance
Sources and discussion
- Nielsen Norman Group: UX deliverables glossary (publisher)
- Atlassian: product requirements template (publisher)
Community posts describe individual experiences and questions; they are not treated as universal proof.
Related resources
Build the next step with SayCraft
Map one critical journey before adding screens, then use the flow to challenge missing states and assumptions. SayCraft can turn the conversation into a preview; qualified owners still review architecture, security, accessibility, and production behavior.