011 min
Why teams draw a user flow
Picture a designer at a subscription app. The product manager asks for a free trial, and the team agrees in one short meeting. The designer starts drawing the sign-up screen.
Two days later, an engineer asks what should happen when the email address already has an account. Another engineer asks what should happen when the card is declined. Nobody has decided either one. The meeting settled one question, whether to offer a trial. It left several smaller questions open, and each of them changes what the screens must show.
A user flow answers those smaller questions before anyone builds the screens. Teams usually draw it after they have studied their users and before they sketch page layouts. The rest of this article follows the free trial through each stage of drawing and checking a flow.
022 min
What a user flow contains
Every user flow is built from four parts. The entry point is where the person arrives, such as an advertisement, a search result or a button inside the app. The steps are the things the person sees or does, one after another. The decisions are the places where the path can split, either because the person chooses or because the system checks something. The outcome is where the flow ends, and a good flow shows both the successful outcome and the failed one.
Designers draw these parts with a few shapes taken from flowcharts, the diagrams that engineers use to record a process.
| Shape | What it stands for | In the free trial example |
|---|---|---|
| Oval | Where the flow starts or ends | The person arrives from an advertisement |
| Rectangle | A step the person or the system takes | The person enters an email address |
| Diamond | A decision, with one arrow out for each answer | Does this email address already have an account? |
| Arrow | The direction the person moves next | From the email step to the decision |
In the example, the flow starts at the advertisement and the person enters an email address. The first decision asks whether that email address already has an account. If the answer is yes, the person goes to log in. If the answer is no, the person continues to payment. A second decision checks whether the card is accepted. If it is, the trial starts. If it is not, the person returns to the payment step with a message that says what failed.
The happy path in a user flow
The happy path is the route where nothing goes wrong: the email address is new, the card is accepted and the trial starts. Teams draw it first, and many stop there. That is a mistake, because the engineers' questions were all about the other routes. An error path is a route that starts when something fails, such as a declined card. A recovery path is the route that brings the person back to a step where they can try again. Each diamond needs one labelled arrow for every answer it can have, so no answer is left without a place to go.
031 min
Where the user flow comes from
No single person named the user flow, and the sources on the term give no inventor or date. The diagram underneath it has a clear history.
Frank and Lillian Gilbreth introduced the flow process chart in 1921, in a presentation to the American Society of Mechanical Engineers. Their chart recorded the steps of a work process in order, so that engineers could look for a better way to do the work. Interface designers later used the same idea for a different subject. The Gilbreths charted what a worker does in a factory. A user flow charts what a person does with a product.
Nielsen Norman Group, a UX research firm, defines a user flow as the usual or best-case sequence of steps for a common task with a product. The word "ideal" in that definition matters. A user flow is a plan for the path the team wants people to take, and the real paths can differ from it. A later section shows how to compare the two.
042 min
User flow, task flow and wireflow
Teams use related drawings, and the names overlap. They differ in what they include.
| Drawing | What it shows | Does it branch? |
|---|---|---|
| Task flow | One task as a straight list of steps | No |
| User flow | One goal, with its decisions and alternative routes | Yes |
| Wireflow | Page layouts joined by flow arrows | Yes |
| UI flow | A user flow whose steps are finished screen designs | Yes |
In the free trial example, a task flow would list only the happy path: enter an email address, enter card details, and the trial starts. Adding the two decisions turns it into a user flow. A task flow is often the first draft, and a user flow grows from it.
Why a wireflow shows the screens
Some products have only a few core pages whose content changes after each action. A flowchart box that carries a page name tells the reader little, because the page looks different each time. Nielsen Norman Group says a plain flowchart lacks the page context that matters for interface work. A wireflow adds that context by drawing each screen inside the flow. It takes longer to draw. Use one when the screen itself decides what the person does next, and use a plain user flow when the logic matters more than the layout.
052 min
User flow vs. journey maps, sitemaps and funnels
Three other drawings get mistaken for a user flow. Each one answers a different question.
User flow vs. user journey map
A user journey map covers a whole experience that can last weeks and cross many channels. Nielsen Norman Group says a user journey describes a person's whole experience across channels and over time, while a user flow zooms in on a few specific interactions. A journey map also records what the person thinks and feels. A flow does not. Teams often draw both: the journey map shows how the trial feels, and the user flow shows what happens at each step of it.
User flow vs. sitemap
A sitemap lists the pages a product has and how they are grouped. It does not show the order in which one person visits them. The free trial may use three pages that sit in three different parts of the sitemap, and only the flow shows that the person meets them one after another. Grouping pages is the job of information architecture, the work of organising a product's content.
A funnel report is not a user flow
A funnel is a series of steps in a fixed order, and a funnel report counts how many people reach each step. The conversion funnel measures a flow after release. It does not design one. Google's documentation draws the same line between the two kinds of report. Google says its path exploration report shows many paths, where its older multi-channel funnels report followed one path chosen in advance. A report that follows one chosen path cannot show routes the team never thought of.
062 min
How to draw a user flow
Drawing the free trial flow takes seven short steps. Any whiteboard or diagram tool will do, because the shapes matter more than the software.
Pick one person and one goal.
Start from user research or from a persona, a written profile of a typical user. Here the person is a new visitor and the goal is to start a free trial. A second goal, such as cancelling, gets its own diagram.
Pick the entry point.
Choose the place where most people with this goal begin, such as the advertisement.
List the steps in order.
Name each step with a verb: enter email address, enter card details. Leave out anything the person does not see or do.
Add the decisions.
Mark every place where the person chooses or the system checks something, and draw an arrow out of the diamond for each answer.
Add the error and recovery paths.
For every step, ask what could go wrong and where the person goes next.
Label everything with short words.
Label each arrow that leaves a diamond with its answer, and add a small key if the diagram uses colours or extra shapes.
Test it with people.
Ask a few people from the target group to try the task on a prototype, a rough working model of the product, in a usability test. Watch where their path leaves the drawing. Ask an engineer to find the cases that are missing. Redraw the flow and repeat.
Keep the drawing short enough to read on one screen. If it does not fit, split the goal into smaller flows and link them, for example one flow for sign-up and one for payment.
072 min
A user flow in a real checkout
A real checkout shows what a flow can cost. Baymard Institute, a research firm that tests online checkouts, averaged 50 studies of shopping cart abandonment and got a rate of 70.22 percent. Cart abandonment means a shopper leaves without buying.
Baymard also measured how long a checkout flow is. Its testing shows an ideal checkout can be as short as 12 to 14 form elements, but the average checkout in the United States shows 23.48 by default. A form element is one thing the shopper fills in or picks, such as a text box or a drop-down list.
Count the length of a user flow in form elements
Notice the unit. Baymard measures a checkout flow by the form elements shown by default, not by the number of screens. This matters when you draw a flow, because two diagrams with the same number of boxes can ask for very different effort. One box may hold a single field, and another may hold ten. Write the number of fields inside each step of the flow, so a long step is visible before anyone builds it.
Not every abandonment is a flaw in the flow
A rate of 70.22 percent does not mean the flow lost 70 percent of the buyers. Baymard says many abandoned carts come from shoppers who were browsing, comparing prices or saving items for later. Those people were never going to finish. The part a flow can fix is the rest: people who wanted to buy and met an obstacle. Work out which group a drop-off belongs to before redrawing a step.
081 min
Checking a user flow against what people do
A drawn flow is a plan. After release, the team can compare it with what people did. Analytics tools help here. Google Analytics has a report named path exploration that shows the routes people took, as a tree of steps.
Forward and backward paths
A forward report starts from a screen the analyst picks and lists what people did next, and a backward report starts from a chosen end point and lists what came before it. In the free trial example, a forward report from the email step would show how many people reached log in, how many reached payment and how many went nowhere. A backward report from the outcome "trial started" would show which routes led there, including routes nobody drew.
Loops
Google lists looping, where people return to the same steps, as a sign that users may be stuck. In the example, a loop between the payment step and its error message would suggest that the message does not tell people how to fix the card problem.
Two other checks
An A/B test shows two versions of one step to different groups of visitors and compares how many finish. A usability test shows where a few people hesitate and why. The analytics say where people leave, and the test says the reason.
091 min
User flow and accessibility
A long flow asks people to remember what they entered earlier. For some people, such as those with memory or learning disabilities, that is a barrier. The Web Content Accessibility Guidelines (WCAG) are the W3C's accessibility standard. Version 2.2 deals with this in success criterion 3.3.7, called Redundant Entry. WCAG 2.2 success criterion 3.3.7, Redundant Entry, requires a process to fill in earlier answers or let the person select them.
For the free trial, suppose the first step asks for the email address and the payment step asks for it again. The flow should fill it in on the payment step or show it for selection. The rule has exceptions. Asking again is allowed when it is essential, when it protects security, or when the earlier answer is no longer valid. Typing a new password twice is the usual example of the security exception.
Check the drawn flow for this rule before anyone builds it. Every place where an arrow leads to a step that asks for information is a place where the rule can be broken.
101 min
When a user flow stops helping
A user flow has limits, and each one has a sign you can see.
- Too many goals in one diagram. Sign-up, cancellation and plan changes in one drawing cannot be read. The sign is a diagram that needs scrolling. Split it by goal.
- Only one entry point. Some guides say a flow should have one. Real people reach the payment step from an emailed reminder, a shared link or a saved page. List the entry points that matter and draw a short flow for each.
- Feelings left out. A flow records actions and system responses. It cannot show that the person felt worried about being charged. Pair it with a journey map for that.
- One person at a time. A flow follows one person. It does not suit experiences shared by a group, such as a team using a tool together.
- Out-of-date drawings. After the product changes, an old flow tells the team what the product used to do. Update the drawing in the same piece of work as the change, or delete it.
?3 questions
Questions people ask
Who draws a user flow?
What is the difference between a user flow and a user story?
Can I draw a user flow for a product that already exists?
§7 sources
Sources
Kate Kaplan, "User Journeys vs. User Flows", Nielsen Norman Group, 2023:
Page Laubheimer, "Wireflows: A UX Deliverable for Workflows and Apps", Nielsen Norman Group, 2016:
Baymard Institute, "50 Cart Abandonment Rate Statistics", 2026 edition:
W3C, "Understanding Success Criterion 3.3.7: Redundant Entry", WCAG 2.2:
Show all 7 sourcesShow fewer sources
Google, "[GA4] Path exploration", Analytics Help:
"Flowchart", an encyclopedia entry that reports the Gilbreths' 1921 presentation:
Interaction Design Foundation, "What Are User Flows?":
