User Flow
A User Flow maps the screens, choices, and replies on the way to a result.
Another example
A password reset flow includes the request, email, new password, expired link, and success screen.
Main parts
- 01Entry state
- 02Decisions and system responses
- 03Completion and recovery paths
Use it when
Map it before polishing screens so missing steps and states are easier to find.
Do not use it when
For an important task, do not show only the path where everything works. Include errors and ways back.
Name used in code
flow diagram Before you ship
Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision.
Outcome: Use User Flow to make a focused product decision backed by evidence. User context: A password reset flow includes the request, email, new password, expired link, and success screen. Product concept to apply: User Flow. Why it fits: Map it before polishing screens so missing steps and states are easier to find. Do not use it when: For an important task, do not show only the path where everything works. Include errors and ways back. Product framing: Name the target user and wanted result. Record the current baseline and evidence. Set what is in and out of scope, the limits, the owner, and the time frame. Decision quality: Keep facts, guesses, and unknowns separate. Record the options you did not choose and what evidence would change the decision. Acceptance criteria: The document names an owner, target user, measurable result, scope limit, evidence source, open risks, and next test. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Target group, baseline, success level, owner, time frame, dependencies, and review schedule.
Check this request
Review the current use of User Flow. Definition: A User Flow maps the screens, choices, and replies on the way to a result. Release checks: Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.