How to Create a User Flow in UX Design: A Step-by-Step Guide

A user flow is a visual diagram showing the steps a user takes through a product to complete a specific goal — from entry point to successful completion. Most UX designers learn to draw them quickly. A few rectangles, some diamond decision points, arrows connecting them — it looks straightforward on a tutorial diagram. The trouble is that real user flows, the kind that are actually useful to a design team, are substantially harder to produce than a tidy flowchart of the happy path.

This guide is about what makes a user flow genuinely useful: the thinking required before you touch a diagramming tool, the distinctions that matter, and the mistakes that make most flows misleading rather than illuminating.

Want to create user flows on a real project? UX Academy (myuxacademy.com)'s Beginner UX Design course teaches user flows and the full UX process live with working professionals. Cohort 1 starts 5 Sep 2026 -- reserve your place with a £99 deposit.

What a user flow actually is

A user flow is a visual representation of the path a user takes through a product to complete a specific goal. It shows every step, screen, and decision point between where the user starts and where they finish. The goal might be completing a purchase, signing up for an account, booking a call, or resetting a password. The flow maps what happens — and what can go wrong — at every stage.

User flows sit within the broader UX design process as a bridge between research and design. They come after you understand your users and their goals, and before you start sketching wireframes. Their purpose is to make alignment explicit: everyone on the team can see the intended experience before a single screen is designed.

What user flows are not is a record of how the system works internally. The logic that runs on a server, the database queries, the API calls — none of that belongs in a user flow. A user flow captures only what the user sees, decides, and does.

User flows, task flows, and flowcharts — what is the difference?

These three terms are used inconsistently in the industry, which causes confusion. Here is a practical distinction:

| Term | What it shows | Typical use | |---|---|---| | Task flow | A single linear path through one task | Analysing a specific interaction | | User flow | Multiple paths, entry points, decisions, and error states | Mapping the full experience before wireframing | | Flowchart | Logic or process steps, often system-focused | Engineering, business process documentation |

A task flow assumes one type of user, one entry point, and one outcome. It answers: what are the steps in this task? A user flow is richer: it shows what happens when the user makes different decisions, what error states look like, and how different entry points lead to different paths. A user flow is the more complete and more useful artefact for design purposes.

What symbols are used in a user flow diagram?

User flows use a small vocabulary of shapes. Different tools use slightly different conventions, but these are the most widely recognised:

• Rounded rectangle / oval — start and end points (sometimes shown in a different colour)
• Rectangle — a step, screen, or action the user takes
• Diamond — a decision point; the user makes a choice, leading to two or more paths
• Arrow / connector — shows direction of travel between steps
• Parallelogram — occasionally used for data inputs and outputs

The exact shapes matter less than consistency. Define your symbols at the start of a project, add a legend to the diagram, and use the same conventions throughout. A flow where diamonds sometimes mean decisions and sometimes mean screens is not a useful artefact — it is a source of confusion.

How to create a user flow: step by step

1. Define the goal and the user

Before opening a diagramming tool, you need two things clearly in your head: whose flow are you mapping, and what are they trying to achieve?

If you have user personas, choose the one most relevant to this flow. A first-time visitor trying to understand your pricing behaves very differently from a returning customer trying to change their billing details. Mixing the two into a single flow produces something that describes nobody accurately.

The goal should be a specific outcome: "user successfully completes the checkout and receives a confirmation email," not "user buys something." The specificity forces you to think about what "complete" actually means.

2. List the entry points

Real users do not always arrive at the beginning. They land on product pages from organic search. They follow a link in an email that drops them three steps into a journey. They return to an app mid-task. Your flow needs to reflect this.

List every realistic entry point for this particular goal. Then decide whether to map them all in one diagram or produce separate flows per entry point. For complex products, separate flows per entry point are often cleaner.

3. Map the steps and decisions

Work through the journey step by step, adding a rectangle for each screen or action, and a diamond wherever the user faces a meaningful choice. "Meaningful" is doing a lot of work in that sentence — not every micro-interaction needs its own decision diamond. A user flow is a strategic document, not a pixel-by-pixel walkthrough.

The decisions to include are those that create genuinely different paths: logged in or not, payment method selected, error encountered or not, email verified or not. If a choice does not change what happens next, it probably does not need a diamond.

4. Add error states and edge cases

This is where most first-attempt flows fall short. The happy path — user does everything correctly, no errors, perfect outcome — is the easy part to draw. The flows that are actually useful show what happens when:

• The user enters invalid information into a form
• The session times out mid-checkout
• A required field is left empty
• The user wants to go back and change a previous step
• A payment fails

Edge cases are not edge cases in practice. Password resets, failed payments, and validation errors happen constantly. If your flow does not show them, the designers building from it will have to make decisions on the spot — and those decisions will be inconsistent.

5. Review and simplify

A finished user flow should be readable by a stakeholder who has not been in any of the design conversations. If it requires a five-minute verbal explanation before it makes sense, it is too complex or too poorly structured.

Common simplifications: collapse sub-flows into a labelled box and document them separately, remove steps that are identical across paths, and check whether any diamonds are actually redundant (both paths lead to the same next step anyway).

6. Test and iterate

A user flow is a hypothesis. It is your team's best current understanding of how users will move through the product. That understanding should be updated as you learn more.

Once you have wireframes built from the flow, run usability testing to see whether real users actually follow the paths you mapped. They often do not — and the divergences are the most useful information you will gather. Update the flow to reflect what you learn.

Common user flow mistakes

Mapping only the happy path. The most common error. A flow that shows nothing going wrong is not a complete flow — it is an optimistic sketch. Error states and alternative paths are where design decisions have the most impact on user experience.

Too many paths in one diagram. The opposite problem: a flow so dense with branches that it cannot be read without a magnifying glass. If your flow has more than two or three levels of branching, consider splitting it into multiple focused diagrams.

Confusing user actions with system actions. A flow should show what the user does and sees, not what the backend does in response. "Database updates user record" is a system action; it does not belong in a user flow unless it produces something visible to the user.

Starting too detailed too early. It is tempting to jump into a diagramming tool and start adding every micro-interaction from the beginning. The more useful approach is to sketch the broad structure first — on paper if necessary — and add detail only once the overall shape is agreed.

Skipping the flow entirely. Perhaps most common of all: jumping straight from research to wireframes without ever mapping the journey. The result is screens that look reasonable in isolation but do not connect logically. Wireframes built without a user flow often expose structural problems too late, when fixes are expensive.

Tools for creating user flows

You do not need specialist software to create a useful user flow. The right tool is whichever one your team will actually use and share.

Paper and pen is genuinely underrated for early-stage flows. Speed matters when you are still figuring out the structure, and paper forces you to simplify.

Figma — specifically FigJam, Figma's whiteboarding tool — has built-in flow shapes and connectors that snap together automatically. If your team already uses Figma for design, keeping flows there means everything lives in one place.

Miro and Whimsical both have dedicated flowchart templates and are well-suited to collaborative sessions where multiple team members are building the flow at the same time.

Lucidchart and draw.io are more traditional diagramming tools that work well for complex flows with many branches.

The choice of tool has no bearing on the quality of the thinking. A mediocre flow in Figma is no better than a mediocre flow on a sticky note. The discipline of working through entry points, decision points, error states, and edge cases is what produces a useful artefact — not the tool.

Where user flows sit in the design process

User flows connect naturally to several adjacent UX skills. They sit after information architecture work — once you have decided how to organise the content, you can map how users will move through it. They inform wireframes, which translate the flow into actual screen layouts. And they are testable: you can walk participants through a flow in a research session before any screens exist, to check whether the overall journey makes sense.

They are also an underused alignment tool. A well-constructed user flow, shared with engineering and product stakeholders early, surfaces disagreements about scope and logic before they become expensive design changes. The conversation "wait, what happens if the user is not logged in at this point?" is much cheaper to have over a diagram than over a half-built prototype.

User flows are not glamorous work. They are rarely shown in portfolios, and they do not photograph well for social media. But the ability to think clearly about how users move through a product — including when things go wrong — is one of the most practically useful skills a UX designer can develop.

If you are switching into UX design from another field, building this skill early will save you significant rework later. Understanding how to map a journey before designing screens is the kind of thinking that separates designers who build things that work from designers who build things that look good.

If you want to see what live UX training feels like before committing, the free UX masterclass at UX Academy (myuxacademy.com) is the place to start. For a structured introduction to user flows and the full UX process — with live feedback on real work — the Beginner UX Design course at UX Academy (myuxacademy.com) covers exactly this, taught live by Natalia Veretenyk and her team. Cohort 1 starts 5 September 2026.