A user flow is a diagram of every step someone takes to finish one task in your product, from where they start to where they're done. It maps the screens, the actions, and the decision points between them — including the ones that branch off the happy path. The point is to see the whole route to a goal before you build it, so dead ends and missing screens show up on paper instead of in production.

How do you create a user flow?

Pick one clear goal the user is trying to reach, then list every entry point they could start from. Lay out the steps and decisions between start and finish, attach the actual screen at each step, and map the edge cases — errors, empty states, and dead ends — not just the happy path. Use standard flowchart shapes so anyone can read it, and keep it to one goal per diagram instead of cramming the whole product into one chart.

User flow vs wireframe — what's the difference?

A user flow shows the route between screens — the sequence and the decisions. A wireframe shows the layout of a single screen — where the button, the field, and the heading sit. The flow answers what happens next; the wireframe answers what this one screen looks like. You usually draw the flow first to decide which screens exist, then wireframe each one.

What tools are used to make user flows?

FigJam and Miro are the common choices for collaborative, low-friction flow diagrams you sketch with a team. Figma works well when you want the flow to live next to the actual screen designs. Whimsical is popular for quick, clean flowcharts. Honestly, the tool matters less than the habit — a flow drawn on a whiteboard photo still beats no flow at all.

User Flows: What They Are & How to Map Them

Q: What's the difference between a user flow and a user journey?

A user flow is tactical and screen-level: the exact clicks and decisions to complete one task inside the product. A user journey is broader and emotional: the whole arc of someone's relationship with your product over time, including how they feel and what happens off-screen. The journey tells you why a moment matters; the flow tells you how that moment works, screen by screen.

A user flow is the map of every step someone takes to finish one task in your product — start to finish, including the forks in the road. It's the click-by-click route to a goal, drawn before you build it, so the dead ends and missing screens turn up on paper instead of in a bug report. If you've ever shipped a feature and then discovered there was no way back from the confirmation screen, you've felt the cost of skipping this.

This piece is about the practical version. What a user flow actually is, how it's different from a user journey and a wireframe, and how to map one that earns its keep. We'll keep it to the parts we use when we draw these for real work, not a textbook tour.

What a user flow is

A user flow is a diagram of the path a person takes through your product to complete a single task. Sign up. Reset a password. Check out a cart. Each flow has one goal, and it traces the screens, the actions, and the decisions that sit between the user's first step and their last. When people say "user flow diagram," they mean exactly this: a flowchart of a task.

The reason it's worth drawing isn't that it looks tidy in a deck. It's that the act of mapping forces questions you'd otherwise dodge. What happens if the email's already taken? Where does someone land after they cancel? Is there a way back, or did we just trap them? You answer those on a canvas in twenty minutes, or you answer them in production after a user files a complaint. One of those is a lot cheaper.

A good flow stays narrow. One goal, one diagram. The temptation is to map the entire product in a single sprawling chart, and that chart always ends up unreadable — too many lines, nobody looks at it twice. Better to have eight small flows people actually use than one wall poster they avoid.

User flow vs user journey vs wireframe

These three get mixed up constantly, and the confusion costs real time in meetings. They sit at different zoom levels. A user journey is the wide shot: the whole arc of someone's relationship with your product, often spanning days and including how they feel and what happens off-screen. A user flow is the medium shot: the screens and decisions inside one task. A wireframe is the close-up: the layout of a single screen. The user journey vs user flow distinction is mostly about scope — journeys are emotional and end-to-end, flows are tactical and screen-level.

Here's the quick version of when to reach for each.

Artifact	What it shows	When to use it
User journey	The whole arc over time — stages, emotions, touchpoints on and off-screen	Early, to understand the person and find the moments that matter
User flow	The screens and decisions to finish one task inside the product	Before design, to map the route and catch gaps in a single task
Wireframe	The layout of one screen — where each element sits	After the flow, to design each screen the flow says you need

The order in that table is roughly the order you'd work in. Journey first to see the forest, flow next to plan the trails, wireframe last to build each step. You can skip the journey for a small internal tool. You can't really skip the flow if the task has more than one branch — that's where the bugs hide.

How to map a user flow, step by step

Mapping a flow is less about drawing skill and more about asking the right questions in order. Here's how we'd run it.

Pick the goal. Name the one thing the user is trying to accomplish, in their words, not yours. "Recover a forgotten password," not "auth subsystem." A flow with two goals is two flows wearing a trench coat, and it'll read like one.
Find the entry points. Where can someone start this from? A login screen, an email link, a deep link from a notification — list them all. Flows break most often at the edges, because someone arrives from a path nobody mapped.
Lay out the steps and decisions. Walk from start to finish, marking each action and each fork. Every decision point is a yes/no question that splits the path. This is the spine of the flow, and it's where you'll find the questions you hadn't answered yet.
Attach the screens. For each step, name the actual screen or state the user is on. This is the bridge from flow to design — once you know which screens exist, you know what to wireframe.
Map the edge cases. The happy path is the easy 80%. The value is in the other 20%: errors, empty states, timeouts, the back button, the dead end. A flow that only shows the sunny route is a flow that lies to you.

A user flow diagram for a login task. It starts at a rounded Start node, moves to a Login screen, reaches a diamond decision asking whether the credentials are valid. A No branch leads to an Error state that loops back to the Login screen; a Yes branch leads to the Dashboard screen and then to a rounded End node. — A simple login flow — the diamond is where the path branches, and the loop back from the error state is the edge case people forget to draw

A real flow is messier than that, but the shapes are the same. Notice the loop: a failed login sends the user back to try again, not into a void. That loop is the kind of thing you only remember to build because the diagram made its absence obvious.

The symbols and how to read a flow

Flow diagrams borrow a small set of flowchart shapes, and once you know four of them you can read almost any flow. You don't need the full standard — most teams use a handful and keep it consistent.

Rounded rectangle (oval) — start and end. Where the flow begins and where the task is done.
Rectangle — a step, screen, or action. The bulk of any flow is rectangles.
Diamond — a decision. A yes/no fork that splits the path. If your flow has no diamonds, it's probably a list, not a flow.
Arrow — direction. It shows where the user goes next, and labeled arrows ("Yes," "No") make branches readable.

The one habit that separates a clear flow from a confusing one is labeling your arrows out of decision points. A diamond with two unlabeled lines leaving it makes the reader guess which is which, and people guess wrong. Spend the extra two seconds.

A user flow isn't a drawing of what your product does. It's a list of the decisions you haven't made yet, disguised as a diagram.

Common user flow mistakes

The ways flows go wrong are predictable, which is good news — you can watch for them. The most common is mapping only the happy path, drawing the route where everything works and quietly ignoring every error and dead end. That's the flow equivalent of testing your code by running it once and trusting it.

Close behind is cramming too much into one diagram — the everything-flow that tries to show signup, checkout, and settings in one chart and ends up readable by nobody. Split it. Then there's skipping the entry points, assuming everyone starts from the home screen when half your users arrive from an email link or a shared URL. And the quiet one: drawing the flow once and never updating it, so it slowly drifts from the real product until it's actively misleading. A stale flow is worse than no flow, because people trust it.

Most of these trace back to treating the flow as a deliverable to file away rather than a thinking tool to argue over. The flow earns its keep in the questions it forces, not in how it looks on the wall. Mapping flows sits inside the wider UX design process, and the screens they point to get pressure-tested in usability testing — the flow tells you what to test, the testing tells you whether the flow was right. If you're still sorting out where flows fit relative to visual design, our take on UI vs UX draws that line, and the broader case for user-centered design explains why evidence should settle these calls. You can see how it all fits together on our UI/UX design hub.

Got a product to map? Start with the flows before the screens

Talk to our design team