User Flow Template With Diagram and Worked Example
By SayCraft Team · 2026-08-27 · 9 min read
A useful user flow shows how a person reaches an outcome and what happens when the happy path breaks. Begin with an entry point and user intent, then record each screen or state, system response, decision, failure or recovery path, analytics question, and exit condition. Include permissions plus loading, empty, validation, and error states that change what the person can do next. The copyable table below works when the team needs to agree behavior before drawing screens or building a prototype. It does not replace a journey map for the wider experience or a wireframe for layout.
Copyable user flow template
| Step | User intent | Screen/state | System response | Decision | Failure / recovery | Analytics question |
|---|---|---|---|---|---|---|
| 1 | Enter the workflow | Entry point | Loads eligible record | Signed in and permitted? | Sign in or permission message | Which entry source and permission outcome occurred? |
| 2 | Understand current state | Loading → content/empty/error | Returns data or explicit status | Record available? | Retry, create first record, or exit | Which state caused an exit or retry? |
| 3 | Complete the action | Form or review state | Validates and submits | Input valid? | Keep input, explain error, focus correction | Which validation or failure blocked completion? |
| 4 | Confirm outcome | Success state | Persists result once | Another action needed? | Return to list or safe next step | Did success lead to the intended next task? |
Plain-text diagram: client draft approval
Invite link (entry)
├─ not signed in → sign in → validate invitation
├─ expired invitation → explain → request new invite (exit)
└─ valid invitation → load draft
├─ loading fails → retry or contact owner
├─ no current draft → empty state (exit)
└─ draft ready → review
├─ approve → confirm once → approval receipt (success exit)
└─ request changes → require comment → saved request (success exit)Worked flow table
| Step | State | Evidence question | Analytics question |
|---|---|---|---|
| Open invite | Validating invitation | Can the client tell that access is being checked? | Which entry source reaches valid, expired, and denied outcomes? |
| Review draft | Ready with version label | Does the client know which version the decision affects? | Where do loading, empty, permission, and error exits occur? |
| Submit approval | Submitting; controls disabled | Can repeated clicks create duplicate decisions? | How often does validation block submission or retry follow failure? |
| Finish | Approval receipt | Can the client and designer retrieve the same decision later? | Does success lead to retrieval or the intended next task? |
Payment success, failure, cancellation, and retry states
A payment flow needs more than success and failure. Model the processor result, the product state, and the user's safe next action separately. Do not mark an order paid from a client-side success screen alone; the authoritative payment event and idempotency rules belong to the payment integration.
| State | What the interface should explain | Safe next action |
|---|---|---|
| Processing | The payment result is not yet final and duplicate submission is blocked. | Wait for the authoritative result or return safely. |
| Succeeded | The accepted amount, item, receipt, and resulting access are clear. | Continue once; repeated callbacks must not duplicate fulfillment. |
| Failed | The payment did not complete without exposing sensitive processor detail. | Retry with the same order or choose another supported method. |
| Canceled | No completed payment was recorded and the reserved action was released or retained by policy. | Return to checkout without creating a duplicate order. |
| Retrying | The product distinguishes a retry from a new purchase. | Preserve the order identity and show the new attempt result. |
A user flow maps interaction states. A journey map includes the broader experience across channels and time. A wireframe shows layout. Use this flow to populate an app prototype template and translate system responses into functional requirements.
Turn the document into something testable
Bring one completed flow—including its failures—to the live builder. A preview that covers only the success route has not yet implemented the approved flow.
Frequently asked questions
What is a user flow?
A user flow maps the sequence of user intent, interface state, system response, decisions, and exits required to reach an outcome.
What should a user flow include?
Include an entry point, success exit, decisions, permissions, and loading, empty, error, and recovery paths relevant to the workflow.