What is a user flow and how do you draw one?

What is a user flow?

A user flow is the route description of a task in a product. Where does the user start, which screens do they see, where do they decide, where do they end? The diagram answers these questions with boxes connected by arrows.

In a 2023 NN/g text, Kate Kaplan defines the user flow as a series of interactions. This series shows the typical or ideal steps of a common task in a product. The flow contains two things: the user’s important actions and the system’s responses to them.

According to Kaplan, a flow describes work that takes minutes, at most a few hours. Her example is buying a tennis racket on a sporting goods website. Resetting a password or booking an appointment are such tasks too.

The difference from a customer journey map and a wireframe

These terms are often confused because they all describe the same product. The difference lies in what each one looks at exactly.

The customer journey map is the wide-angle shot. According to Kaplan’s comparison, it covers several channels and touchpoints and can span days or months. Besides actions, it also describes feelings and thoughts.

The user flow, on the other hand, stays within one product and doesn’t describe feelings. Kaplan says it clearly: flows are limited to sequences of steps and carry no information about the user’s emotional state.

Kaplan also writes that using both together often helps. The flow looks closely at a single part of the journey.

	Customer journey	User flow
Scope	Several channels and touchpoints.	Interactions in one product.
What it describes	Action, feeling, thought, channel.	User action and system response.
Duration	Days, weeks, months.	Minutes, at most hours.
Output	Customer journey map.	Wireflow, flowchart, task diagram.
Research	Field research, diary study, interviews.	Usability testing, plus analytics.

The wireframe answers a different question: what goes where on a screen? Page Laubheimer writes in an NN/g text that wireframes show layout well but describe interaction poorly. The flow, on the other hand, shows the transition between screens.

Then there is information architecture. It is the product’s map: which pages exist, and how are they grouped? The user flow is a single route on that map.

Task flow, wireflow and user flow

These three terms are used slightly differently depending on the source. I use the following distinction because it clarifies in the team who means what.

• Task flow: the steps to a single goal. According to a 2022 comparison from Overflow, most task flows are largely linear and look simple. They can also describe only part of a long process.
• User flow: according to the same text, all the possible paths a user can take to a goal. It branches, and decisions and error paths become visible here.
• Wireflow: the format Laubheimer defines in a 2016 text. Instead of a flowchart’s abstract boxes, real screen designs appear. The arrow starts from the button the user presses and leads to the screen with the result.

According to Laubheimer, the wireflow suits products with a few core screens whose content changes depending on the user’s action. Mobile apps, web apps and checkout flows are among them. With static desktop websites, caution is needed, because large screen images can obscure the process.

In practice, I draw a plain flowchart first. Once the paths are clear, I turn the important steps into a wireflow.

If the mobile and desktop versions run differently, I draw them separately. The differences between iOS and Android often change the flow too.

Symbols in a user flow

The shapes in a user flow come from the tradition of general flowcharts. According to the Wikipedia article on flowcharts, ANSI standardised these symbols in the 1960s, and ISO adopted them in 1970. Today’s standard is ISO 5807, published in 1985.

• Start and end: an oval or a box with rounded corners. Every flow has one entry and at least one exit.
• Screen or process: a rectangle. In a general flowchart it describes a process. In UX it usually stands for a screen or page.
• Decision: a diamond. It holds a question answered with yes or no. According to Wikipedia, the decision chooses which of two paths is taken.
• Arrow: the order of the steps. If you write on the arrow what the user does, the diagram is easier to read.

When everyone uses the same symbols, the diagram passes easily from one team to the next. Showing error screens in a colour of their own is my own habit.

User flow example: forgot password

The flow below shows the steps for resetting a password in a made-up app. Use the buttons above the diagram to highlight the happy path or the error paths. Press a step and its description opens below.

Some steps come from security rules. OWASP’s forgot password guide recommends returning a consistent message whether or not the address is registered. The reset link should be single use and expire after an appropriate period.

The same guide asks that the user isn’t signed in automatically after changing the password. The user gets an email reporting that the password was changed. That email doesn’t contain the password itself.

Interactive user flow

All: 13 steps. 2 start and end, 5 screens, 3 decisions, 3 error screens.

• Start and end
• Screen
• Decision
• Error screen

1. 1 · StartPresses “Forgot password” on the sign-in screen

   The person doesn’t remember their password and presses the “Forgot password” link on the sign-in screen. This is where the flow starts.

3. 2 · ScreenReset request: email field

   The heading reads “Reset your password”. The screen has a single field: email. If an address was already entered on the sign-in screen, the field is filled in. The button says “Send link”.

5. 3 · DecisionIs the email address spelled correctly?

   The system only checks the format: is there an @ and a domain? Whether the address is registered isn’t checked at this step.

   No
   E1 · Error screenField error, same screen↩ Back to step 2

   The screen stays, and the entered address isn’t deleted. Under the field it says “Enter a valid email address, such as [email protected]”. The person corrects it and sends again.

6. Yes
7. 4 · Screen“Sent” message

   The message reads: “If this address is registered, we’ve sent the reset link.” Whether or not the address is registered, the same message appears. Below it are a note about the spam folder and a “Send again” button.

9. 5 · ScreenReset email

   The subject names the product. Inside is a single button: “Set a new password”. It says clearly until when the link is valid.

11. 6 · DecisionIs the link still valid?

    The system checks two things: has the link expired, and has it already been used?

    No
    E2 · Error screen“Link invalid” screen↩ Back to step 2

    The message reads: “This link has expired or has already been used.” There is one button: “Request a new link”. It takes the person to step 2 with the email field filled in.

12. Yes
13. 7 · ScreenNew password screen

    A password field with a “Show” button next to it. The password rules are under the field and are ticked off one by one while typing. The button says “Save password”.

15. 8 · DecisionDoes the password meet the rules?

    The system checks the new password against the product’s rules, such as the minimum number of characters.

    No
    E3 · Error screenPassword error, same screen↩ Back to step 7

    The screen stays, and the entered password isn’t deleted. The message says which rule is still missing. The person corrects the password and saves again.

16. Yes
17. 9 · ScreenConfirmation screen

    The message reads: “Your password has been changed.” The button says “Sign in”. The system doesn’t sign the person in by itself. An email reporting the password change goes to the account’s address.

19. 10 · EndSigns in with the new password

    The person returns to the sign-in screen and signs in with the new password. The goal is reached, and the flow ends.

Because JavaScript is off, the filter doesn’t work. All steps and descriptions are listed in order above.

I made up this “Forgot password” flow; it doesn’t belong to any real product. The “Sent” message, the single-use link and not signing in automatically after the reset are based on OWASP’s recommendations.

The sign-in screen itself, the password field and where the reset link goes are covered in the login and sign-up pattern.

Happy path and error paths

The happy path is the route on which everything goes well. The user types the address correctly, the email arrives straight away, and the password meets the rules on the first try. In the example above, this path takes 10 steps.

Error paths are the branches that open when a decision is answered “No”. Each error path has to answer two questions: what does the user see, and where do they return to? The example has three error paths, and all three take the user back without losing what they entered.

In most teams the happy path is designed and the error paths are left to development. The result is an “An error occurred” message that throws the user back to the first screen. If you connect every No arrow to a screen, this problem is solved from the start.

How I write the message itself is described on the error messages page.

When the flow is finished, check: do at least two arrows leave every diamond? Is no box left in a dead end? These two questions find most missing screens before design begins.

How to draw a user flow

You can draw a flow on paper or in a design tool. More important than the tool is the order of the steps. This is how I go about it:

1. Choose the task and user. Write one goal in one sentence, such as “The user resets their password”. Settle with a persona who you are drawing for.
2. Write down the entry point. Where does the user come into this flow from: the sign-in screen, an email, an ad? Different entry points may need different first screens.
3. Draw the happy path first. Draw a single straight line from start to end. Give every screen a name.
4. Add the No branch to every decision. Go through cases such as wrong data, an expired link or a lost connection one by one. Write down where each branch leads back to.
5. Write down the system’s response. According to Kaplan’s definition, the flow also describes what the system shows at each step.
6. Test the flow with real users. Kaplan names usability testing as the most suitable method for flows. To see where the user taps first, a first-click test is a good start too.
7. Then move to the wireframe. Each rectangle in the flow becomes a screen design.

When you draw the flow matters too. A flow drawn before the problem and the user are clear nicely describes the wrong task. That is why I draw the first flows at the end of the discovery phase, before moving into design.

My note

For me, the user flow is the cheapest document a product team can draw. It is quick to draw and settles many discussions between design and code from the start. Development sees in the diagram which error screen it should build.

The most common gap in my audits: error paths aren’t designed at all. The happy path is carefully drawn, but someone who presses an expired link lands on an empty page.

If you want to draw your flow with me and have its screens delivered along with the code: the Design & Ship Sprint is made for exactly that. In the two-week sprint I deliver design and code into your repository.