In short
A user flow is a diagram of the steps a user takes through a product to complete a specific task, showing screens or states as boxes, actions as arrows, and decision points as branches, from the entry point to the goal or to an exit. It is drawn before screens are designed to check that every path is complete, that decisions are handled, and that the number of steps is justified. It is narrower than a journey map, which covers the whole experience across channels, and more behavioural than a sitemap, which shows structure rather than movement.
What it is
A user flow answers one question: how does a person get from here to done? It takes a single task, such as resetting a password, buying a product, or inviting a colleague, and lays out every step between the point where the user starts and the point where the task is complete, including the branches where something goes wrong or the user has to choose.
The result looks like a flowchart. Boxes are screens, pages or states; arrows are the actions that move between them; diamonds are decisions, made by the user or by the system. A well-drawn flow has one entry, one or more successful exits, and explicit handling of every failure: the wrong password, the expired link, the out-of-stock item, the declined card.
Why draw it before the screens
Mockups show what a screen looks like. They do not show what happens when the user taps the button, what the screen looks like when the list is empty, or where the user goes if they change their mind. Those questions are answered, or not, in the flow, and it is far cheaper to discover a missing step in a diagram than in a built product.
Flows also make the length of a task visible. A checkout that reads naturally in a design review may turn out to be eleven screens when drawn end to end, and the diagram is the argument for collapsing it. They surface the decision points that designers tend to skip: what if the user is not logged in, what if they have no saved address, what if the code is invalid twice. And they give developers a specification of behaviour that a stack of screens does not.
The notation
Keep it simple and consistent:
- Rectangle: a screen, page or distinct state.
- Diamond: a decision, labelled with the question, with a labelled arrow for each answer.
- Arrow: an action, labelled with what the user does ("taps Continue") or what the system does ("sends email").
- Rounded rectangle or circle: start and end points.
- A distinct shape or colour for system actions, errors and off-product steps such as an email or a text message.
Tools: FigJam, Whimsical, Miro, Lucidchart, or a whiteboard. The tool matters less than completeness.
How to create one
- Name the task and the user. "A returning customer reorders a previous purchase." One task, one user type; multiple tasks are multiple flows.
- Define the entry points. Where does this start? A link in an email, a button on the dashboard, a search result. There may be several.
- Define success. What state means the task is done, and what does the user see there.
- Walk the happy path step by step, one box per screen or state, one arrow per action.
- Add the decisions. At every step, ask what could be different: logged out, no data, invalid input, a choice to make. Draw each branch.
- Add the failures and recoveries. Errors, timeouts, cancellations. Every branch must lead somewhere, ideally back to the path.
- Count the steps on the happy path and challenge each one.
- Review it with a developer and, if possible, a user. Developers find the states the design missed; users find the steps that do not make sense.
A flow for a moderately complex task takes an hour or two and fits on one page. If it does not fit, the task may be two tasks.
What flows reveal
The screen that exists in the design and has no way to reach it. The error with no way back. The step that asks for information the system already has. The decision the design assumed the user would never face. The email that is sent and never mentioned in the interface. And, most often, the six-step task that should be three, which is the finding that most improves conversion and reduces support tickets.
Flow, journey map, sitemap
A user flow shows the path through an interface for one task. A journey map shows the whole experience of reaching a goal across time and channels, including steps outside the product, annotated with thoughts and feelings; it is broader and less precise. A sitemap shows the structure of a site, which pages exist and how they are organised, without showing how anyone moves through them. A wireflow combines wireframes with flow arrows, showing rough screens in sequence; it is a user flow with more detail per box.
When to draw them
For any task with more than two or three screens, any task with decisions or failure states, any task that involves a system action such as an email or a payment, and any task that is being redesigned because people abandon it. Draw the current flow first when fixing an existing product; the problems are usually visible in the diagram before anyone looks at a screen. For a trivial task, a flow is overhead, and a quick sketch is enough.
Flows are the unglamorous part of product design, and the part most likely to prevent a rebuild. If you would like a task in your product mapped and shortened, book a call; it is usually an afternoon.
Common questions
What is the difference between a user flow and a user journey?
A user flow diagrams the specific path through an interface to complete one task, screen by screen with decisions and errors. A user journey, or journey map, covers the whole experience of reaching a goal over time and across channels, including steps outside the product, annotated with thoughts and feelings. The journey finds where the experience breaks; the flow designs the task within the product.
What should a user flow include?
The task and the user type, the entry points, every screen or state on the path as a box, every action as a labelled arrow, every decision as a branch with each outcome drawn, every error and recovery path, and the success state. Every branch must lead somewhere. If it does not fit on a page, the task is probably two tasks.
What tools are used to create user flows?
FigJam, Whimsical, Miro and Lucidchart are the common choices, and a whiteboard works for a first draft. Figma can also show flows as connected frames. The notation matters more than the tool: consistent shapes for screens, decisions, actions, and start and end points.
When should you create a user flow?
Before designing screens for any task with more than a few steps, with decisions or failure states, or with system actions such as emails or payments; and when redesigning a task people abandon, where drawing the current flow usually reveals the problem. Trivial one- or two-screen tasks do not need a formal flow.
What is a wireflow?
A user flow whose boxes are wireframes rather than labelled rectangles, so each step shows the rough layout of the screen as well as its place in the sequence. It is useful for reviewing a task with stakeholders who find abstract flowcharts hard to read, at the cost of being slower to produce and change.
