In short
- A user flow maps one task for one kind of user, step by step, from entry to finish.
- It shows the decisions and the failure paths as well as the happy path.
- Flows come before screens: they decide what screens you need and in what order.
- Short, well-mapped flows are one of the cheapest ways to make a product easier to use.
Also called: User flow diagram, Task flow, Flow chart, Screen flow.
What a user flow shows
A user flow answers a simple question: what does someone have to do, step by step, to get this one thing done? Booking a table, inviting a teammate, paying an invoice. Each of those is a flow, and each one starts somewhere specific, such as an email link, a home screen, or an ad, and ends when the person has what they came for.
A good flow diagram has three kinds of parts. Steps are the screens or states the person sees. Decisions are the points where the path splits, like whether they already have an account. Outcomes are the ends of the path, including the unhappy ones: the card was declined, the email is already taken, the link has expired.
A sign-up flow for a booking app
- 01Landing pageArrives from a search or an ad
- 02Pick a timeSees real availability first
- 03Create accountOnly once there is a reason to
- 04ConfirmBooking and email receipt
User flow, journey map, and wireframe
These three get mixed up because they often sit in the same design file. They answer different questions and come at different moments.
| Artifact | What it answers | Level of detail |
|---|---|---|
| Journey map | What is this person's whole experience, including outside the product? | Broad: feelings, channels, weeks or months |
| User flow | What steps does someone take to finish one task in the product? | Medium: steps, decisions, outcomes |
| Wireframe | What goes on each screen, and where? | Detailed: layout of one screen at a time |
A combined form, sometimes called a wireflow, puts small wireframes in place of the boxes in a flow. It is useful for mobile apps, where the path and the screens are hard to judge separately.
How to map a user flow
You do not need special software. A whiteboard, sticky notes, or a simple diagram in Figma or FigJam is enough. What matters is choosing the task carefully and being honest about the paths that go wrong.
- Name the user and the task. One sentence, such as: a first-time customer books a table for tonight.
- Write down the entry points. Where do people actually start? Search, an invite email, a push notification, a shared link.
- List the steps in order. Each screen or state the person must pass through. Count them, because every step loses some people.
- Mark the decisions. Logged in or not, paid plan or free, first visit or returning.
- Add the failure paths. Errors, empty states, timeouts, and the way back from each one.
- Cut steps. Ask of every box whether the task still works without it, or whether it can move later.
Choie's prototype week makes the cut on day one: the critical workflow is picked, its screens and states are named, and everything else is ruled out for that week.
The step most worth cutting
Asking for an account before people have seen any value is the most common avoidable step. Often it can move to the moment there is something to save.
Where user flows fit in a project
Flows come early. Once the team knows who the product is for and what job it does, mapping the main flows tells you which screens to design, what the information architecture needs to hold, and how big the build is. A flow with twelve steps and four decision points is a very different estimate from one with four steps.
They are also the backbone of testing. A usability test usually gives participants a task and watches them work through its flow. Where people stall or turn back, the flow needs work. After launch, the same flow becomes a funnel in your product analytics, so you can see which step loses the most people.
At Choie, mapping flows is part of the product design work in the first two weeks of a build, and the first live link goes out on the first Friday, so people can try the real path rather than a picture of it.
Common mistakes
- Mapping only the happy path. The flow looks clean in the diagram, then real users hit an error with no way back.
- Mapping the whole product at once. A single giant diagram is hard to read and hard to change. One flow per task works better.
- Designing screens first. Screens drawn before the flow is agreed tend to include steps nobody needs.
- Ignoring the entry point. Someone arriving from an invite email needs a different first step than someone who found you through search.
- Never revisiting the map. Once the product is live, compare the drawn flow with what analytics show people actually do.
Common questions
What is the difference between a user flow and a user journey?
A user journey covers someone's whole experience with a company, often across channels and over weeks. A user flow is narrower: the steps inside the product needed to finish one task.
What tools are used to make user flows?
Figma and FigJam are common, as are Miro and Whimsical. A whiteboard or sticky notes work just as well early on, since the thinking matters more than the drawing.
How many user flows does an MVP need?
Usually one critical flow done well, plus the supporting ones it depends on, such as sign-up, sign-in, and password reset. More flows mean more screens and a bigger build.
Who creates user flows?
Usually a product or UX designer, working with whoever owns the product decisions. Engineers should review them too, because flows reveal edge cases that affect the build. At Choie, the people who map the flows also write the code, so nobody has to pass those edge cases along to someone else.