User flow · UX · Diagrams
How to create a user flow, with a worked example
By T. Krause
A user flow that shows only the happy path hides the places people get stuck. Here is how to create one, followed through a made-up sign-up flow from seven shapes to a version with no dead ends.
To create a user flow, pick one task and the screen where it starts. Draw each screen in order until the task is done, add a diamond at every point where the path can split, and draw where each answer goes. Then check that every box has a way out, and compare the drawing with someone doing the task.
Nielsen Norman Group, or NN/g, defines a user flow as "a set of interactions that describe the typical or ideal set of steps needed to accomplish a common task performed with a product". Two parts of that definition limit the job: one task and one product. Anything bigger is a journey, which has its own section further down.
We make Prompt Board, and our user flow template opens on the sign-up flow below. In the template, ovals mark the start and the end, rounded boxes are steps, and diamonds are decisions. Pen and paper works too.
Write the task as one line
Before you draw a box, write down who starts where and what counts as finished. The end has to be something you could see on the screen.
| Vague | One line |
|---|---|
| Onboarding | From the landing page to a first board that's open |
| Checkout | From a full basket to the order confirmation |
| Account settings | From the profile page to a saved new email address |
A flow with two endings is usually two flows. "Sign up and invite your team" stops at the first board in one flow, and inviting starts from there in the next.
One sign-up, from seven shapes to no dead ends
Everything in this section is invented: the product, the screens and the usability sessions. The product is a made-up whiteboard app, and nobody tested it.
The team writes its one line: from the landing page to a first board that's open.
The main path
They draw the route for someone who makes no mistakes. These five shapes are on the template's sample board.
- Landing page
- Sign up form
- Verify email
- Pick a template
- First board
That's a straight line, and a straight line can't show where someone gets stuck.
The decisions
The sign-up form checks the address, so the team adds a diamond, "Email valid?", and a box for the No answer, "Show inline error". Yes goes on to Verify email. That makes seven shapes, and our template's sample stops there.
Every arrow out of a diamond needs a label. If two unlabelled arrows leave a diamond, nobody can tell which is which without asking the person who drew it.
The dead end
Now they check the rule that matters most: every box except the end needs an arrow leaving it. "Show inline error" has none on the sample board. As drawn, a person who mistypes their address stays on that box for good.
The fix is one arrow, from "Show inline error" back to "Sign up form". It takes a second to draw, and it raises a question for the design. Does the form keep what the person already typed?
The step outside the product
"Verify email" is the odd box. The person leaves the app for their inbox and comes back through a link, and NN/g describes flows as interactions within one product. The team keeps the box, because the task can't finish without it. They also ask what can go wrong while the person is away:
| Question | New on the board |
|---|---|
| What if the link has expired? | Diamond "Link still valid?", with No going to "Send new link" and back to Verify email |
| What if the email never arrives? | Step "Resend email" on the waiting screen, with an arrow back to Verify email |
| What if the address already has an account? | Diamond "Already registered?" after the form, with Yes handing over to "Log in", which is a separate flow |
The test
The team then watches three people sign up on a prototype and keeps the flow beside them. NN/g calls usability testing the best research method for getting the data behind a flow, because it "allows us to watch users interacting directly with the product", and it treats analytics as a useful secondary source.
In these invented sessions, one person looks for a way to skip Pick a template and start on an empty board. The drawing has no such path, so the team adds one and sends a question to the designer. Three sessions don't prove anyone else would do the same, so it goes in as a question and not as a finding.
Four checks before you share it
| Check | What a failure looks like |
|---|---|
| Every box except the end has an arrow out | Someone gets stuck, as on "Show inline error" |
| Every diamond's arrows are labelled | Nobody can tell which branch is Yes |
| Each diamond asks one question | "Valid and not registered?" hides two outcomes |
| Each box is a screen or a step the system takes | "Feels confident" is a feeling and belongs on a journey map |
Then count the boxes on the main path and ask which could merge or go. Could Pick a template wait until later, with a blank board as the default? The flow won't answer that by itself, though it does show you every step you'd be removing.
User flow, journey map or flowchart
NN/g's distinction is that journeys "describe a user's holistic, high-level experience across channels and over time", while flows "zoom in". It also says flows work for short tasks of minutes or hours, and they carry no information about how the person feels.
| What you're drawing | Board |
|---|---|
| The screens for one task in one product | User flow |
| Weeks of contact across email, phone and an office | Customer journey map |
| A process with no user at the centre, such as how a support ticket gets handled | Flowchart |
| Everything to build for a product, split into releases | User story map |
Frequently asked questions
What is the difference between a user flow and a user journey?
A flow covers one task in one product, in discrete steps. A journey covers a larger goal across channels and over time, and it usually includes what the person thinks and feels. NN/g's article compares the two in full.
What should a user flow include?
A start, an end, the screens or steps in between, a diamond at each decision and a labelled arrow for each answer. Include the error paths, because those are the places a happy-path drawing leaves out.
Do you need wireframes first?
No. Boxes with screen names are enough to agree on the steps, and our template uses them. NN/g mentions low-fidelity wireflows, simple flow charts and task diagrams as ways to draw a flow, so you can add screen sketches later if the team needs them.
How many steps should a user flow have?
There's no right number. It should have as many as the task really takes, and every box should be something a person sees or the system does. Then look for boxes you could merge.
Should one flow cover every user type?
Start with one. If an admin and a guest take different routes through the same task, a diamond can split them, and if the routes barely overlap, draw two flows.
Draw your own
Write your task as one line, then draw the main path before any branches. Open the user flow template, replace the sign-up boxes with your screens, and fix the arrow out of the error box as your first edit. If the task starts to spread across days and channels, move to a customer journey map.