User flow diagrams: map the path before you design the screens

Every product has paths people follow to get something done: sign up, pay, invite a teammate, recover a password. A user flow diagram is how you see those paths before you commit design and build time to them.

Short answer: A user flow diagram is a map of the steps a user takes to complete one task in a product, drawn as screens, actions and decision points from entry to end state. It shows every path the user can take, including the ones that fail. You make one by writing down the trigger, the steps in order, each decision as a yes/no question and the possible end states, then drawing them as one connected flow.

What is a user flow diagram?

A user flow diagram is a diagram of one task, seen from the user's side. It starts where the user enters (an ad, a link, an empty state), moves through the screens they see and the actions they take, branches at every decision, and ends at a clear outcome: task done, task abandoned, or an error. One flow covers one task. "The whole app" is not a user flow; "a new user creates their first project" is.

Teams draw them for two reasons. Before building, the flow exposes missing screens and dead ends while they are still cheap to fix. After launch, the flow is the map you hold against analytics: if 40% drop at the plan-selection step, you know exactly which box that is.

What are the building blocks of a user flow diagram?

Five elements are enough for almost any flow. Keeping the vocabulary small is what keeps the diagram readable.

• Entry point. Where the user comes from: a campaign link, the home screen, an invite email. One flow can have several entries.
• Screens. What the user sees at each step, usually drawn as rectangles. Name them the way the product names them.
• Actions. What the user does: taps, fills in, uploads. Short verb phrases on the arrows or in their own boxes.
• Decisions. Every point where the path can split, written as a yes/no question: "Has a payment method?" Diamonds by convention.
• End states. Every way the flow can finish, and that includes failure: completed, abandoned, blocked by an error.

How do you draw a user flow diagram?

The fastest route is to write the flow as text first and only then worry about boxes. The logic decides whether the diagram is any good; the layout just makes it readable.

1. Pick one task with a clear finish line, like "a visitor becomes a registered user".
2. Write the trigger: where does the user start, and what do they want?
3. List the steps in the order they actually happen, one screen or action per line.
4. Phrase every decision as a yes/no question, and write what happens on both answers.
5. Name every end state, including the unhappy ones: cancelled, failed payment, verification never finished.
6. Draw it, or hand the written flow to a tool that draws it, and then walk the diagram pretending to be the user. Every dead end you find on paper is one you will not find in support tickets.

Step 4 is where most flows win or lose. A flow with no branches is a brochure: it shows the demo path and hides the product. The failure paths are the reason to make the diagram at all.

User flow diagram, user journey map or flowchart: which one do you need?

The three get mixed up because they all have arrows. They answer different questions.

Three formats, one line each

|Format|What it shows|Best for|

|---|---|---|

|User flow diagram|Screens, actions and decisions in one task|Designing or auditing a feature|

|User journey map|Phases, feelings and touchpoints over time|Understanding the customer, not the screens|

|Flowchart|Any process, not tied to a user or screens|Internal processes and system logic|

A user flow diagram is a flowchart with opinions: the boxes are screens, the actor is the user, and the end states are product outcomes. If what you are mapping has no user making choices, a plain flowchart or a process map is the better format.

How do you generate a user flow diagram from a description?

If you can write the flow as text, you do not have to draw it at all. In SketchMind, an AI whiteboard, you pick Flow in Create with AI, describe the task in plain language and get one editable flow frame on your board in about 20 seconds. The same writing that makes a good flow makes a good prompt: the trigger, the steps in order, the decisions as yes/no questions, the end states including the failures. The prompt field takes up to 3,000 characters, you can attach one PDF of up to 5 MB (a spec, a research summary) and paste up to three public links, and the result is written from them. On a board that already holds notes or frames, "Use this board's content" lets the flow build on what is there. The frame stays editable, so renaming a screen or adding a branch is a direct edit, and you can present the flow straight from the board when you walk the team through it.

Last updated: October 8, 2026. Checked against the current SketchMind app.

What is the difference between a user flow and a user journey?

A user flow maps the screens and decisions in one task; a user journey map covers the whole relationship over time, including feelings and touchpoints outside the product. Flows are for building, journeys are for understanding.

What shapes are used in a user flow diagram?

Rectangles for screens and actions, diamonds for decisions, rounded shapes for entry and end states. The convention matters less than using the same shape for the same thing throughout.

How many steps should a user flow diagram have?

One task usually fits in 5 to 15 steps. If you pass 20, you are probably mapping several tasks at once; split them into separate flows.

Can AI generate a user flow diagram?

Yes. In SketchMind you pick Flow in Create with AI and describe the task: trigger, steps, decisions as yes/no questions, end states. One editable flow frame lands on your board in about 20 seconds.

Do I need a user flow diagram for every feature?

No. Draw them for flows with real branching or real risk: onboarding, payment, anything users fail at. A linear two-screen feature does not need a diagram.