What is a user flow?
A user flow is the path a user takes through a product to complete a task, mapped screen by screen from the first action to the final outcome.
Think of a task your users care about: booking a hotel room, resetting a password, checking out of an online store. Each of these tasks is really a chain of small steps, and a user flow makes that chain visible. It shows every screen the user sees, every action they take, and every decision they face along the way.
User flows force you to design the journey before you design the screens. When you sketch interfaces first, it's easy to create beautiful pages that don't connect logically. When you map the flow first, you catch dead ends, missing steps, and unnecessary detours while they're still cheap to fix, before a single pixel has been drawn.
Flows are also a communication tool. Developers use them to understand what states they need to build, stakeholders use them to see how a feature actually works, and you use them to defend design decisions with logic instead of taste.
-
keywords
- #UserFlow
- #TaskPath
- #Screens
Flows vs. journey maps
User flows are often confused with journey maps because both describe a user moving through an experience. They serve different purposes, and mixing them up leads to the wrong tool at the wrong time.
A journey map is emotional and cross-channel. It follows a person across their whole relationship with a product or service: seeing an ad, visiting the website, calling support, receiving a package. It captures what the person feels at each stage, including frustration, doubt, and relief, and it often spans days or weeks.
A user flow is narrower and more precise. A journey map tells you where the experience hurts; a user flow tells you exactly which screens and actions will fix it. It zooms into a single task inside your product and describes it at screen level, usually covering minutes rather than weeks.
In practice, the two work together. You might discover from a journey map that users abandon your service during sign-up, then create a user flow of the sign-up task to find out exactly where and why they drop off.
-
keywords
- #JourneyMap
- #Emotions
- #ScreenLevel
The standard shapes
User flows borrow their visual language from flowcharts, a notation that predates UX design by decades. The vocabulary is small, and because it's a shared standard, anyone who reads flowcharts can read your flow without a legend.
Circle or oval: start and end
A circle or rounded oval marks where the flow begins and where it ends. Every flow needs exactly one clear starting point, such as "User taps Sign up," and at least one end point, such as "Account created." If you can't name a single trigger that starts the flow and a concrete outcome that ends it, your task isn't defined tightly enough yet.
Rectangle: action or screen
A rectangle represents a step the user moves through: a screen they see or an action they perform. "Enter email address," "View cart," and "Confirmation page" all live in rectangles. Keep the label short and specific, one step per box.
Diamond: decision
A diamond marks a decision point where the flow splits, and it always contains a question with two or more possible answers. "Is the password valid?" branches into yes and no. "Does the user have an account?" branches into log in and register. Diamonds are where flows earn their keep, because every branch is a scenario you must design for.
Arrows: direction
Arrows connect the shapes and show the direction of movement. A flow should read in one dominant direction, usually top to bottom or left to right. If your arrows start crossing each other and looping back constantly, that visual mess is often a sign the underlying experience is confusing too.
-
keywords
- #Flowchart
- #Shapes
- #Decisions
- #Notation
How to map a user flow
Start with a user story, a short sentence that captures who wants what and why: "As a returning customer, I want to reorder my last purchase so that I don't have to search for it again." The story gives your flow a beginning, an end, and a reason to exist.
Define the entry point. Where does the user start? A home screen, an email link, a push notification? The same task can have several entry points, and each one may need its own path.
Define the success state. Write down the exact moment the task is done, such as an order confirmation screen. This is your end oval.
List the steps in between. Walk through the task as the user would, writing one rectangle per screen or action. Be honest here; skipping "boring" steps like loading states or permission prompts is how gaps sneak into products.
Mark the decisions. Wherever the user or the system has to choose, add a diamond and draw a branch for every answer.
Walk it backwards. Start at the success state and trace back to the entry point, asking at each step what the user needed to get here. Reversing direction exposes missing steps that forward walking glosses over.
-
keywords
- #UserStory
- #EntryPoint
- #SuccessState
- #StepByStep
Happy path and edge cases
The happy path is the ideal route through a flow, where every input is valid and every step succeeds on the first try.
Most designers map the happy path and stop, but real users rarely stay on it. They mistype their email, lose their connection, abandon a form halfway, or arrive without the permissions they need. A flow that only covers the happy path is a design that only works for users who make no mistakes, and those users don't exist.
For every diamond in your flow, follow the unhappy branches too. What happens when the payment is declined? When the search returns no results? When the session times out? Each of these needs an error path that tells the user what went wrong and, more importantly, gives them a way back onto the main route.
Edge cases are rarer but just as real: the user who already has an account, the coupon that expired an hour ago, the address the courier can't deliver to. You don't need to design every one immediately, but your flow should at least name them so they become deliberate decisions instead of accidental crashes.
-
keywords
- #HappyPath
- #EdgeCases
- #ErrorPaths
A worked example: sign-up flow
Let's map a simple sign-up flow for a mobile app in prose. The start oval is "User taps Sign up" on the welcome screen. The first rectangle is the sign-up form, where the user enters an email address and a password.
Submitting the form leads to our first diamond: "Is the input valid?" If no, the flow loops back to the form with an inline error message explaining exactly what to fix. If yes, we move to the next rectangle, a screen telling the user a verification email has been sent.
Here comes a second diamond: "Did the user click the verification link?" If yes, the flow proceeds to a welcome screen and ends at the oval "Account created." If no, we need an error path, perhaps a "Resend email" action after a short wait, so the user isn't stranded outside their own account.
Notice what the mapping revealed. Before drawing a single screen, we already know we need an inline error state, a resend mechanism, and a waiting state, requirements that a happy-path-only sketch would have missed entirely. That's the whole point of the exercise.
-
keywords
- #SignUpFlow
- #Validation
- #WorkedExample
Takeaways
Map the path first, design the screens second.
A user flow turns a vague task into a precise sequence of screens, actions, and decisions, covering the happy path as well as the errors and edge cases around it. Once your flow is solid, it becomes the skeleton for what comes next: each rectangle is a scene waiting to be storyboarded and a screen waiting to be wireframed.