Mapping the path between intent and outcome before you design a single screen

A user flow is a diagram showing every step a user takes to complete a specific task in your product — from entry point to end state. It captures screens, decision points, error paths, and alternative routes at the task level: what happens when a user tries to invite a team member, set up an integration, or export a report.

The word "specific" matters. "User navigates the app" isn't a flow — it's a vague gesture at one. "New user completes identity verification after signup" is a flow. The tighter the scope, the more useful the artifact.

User flows are the closest thing UX has to a functional spec. They make architectural decisions explicit before visual design starts, when those decisions are cheap to change.

The two get conflated because they're both diagrams about users doing things. The difference is resolution and scope.

A User Journey Map covers the full arc of a user's relationship with a product — often across weeks, including touchpoints outside the product itself. It's strategic. It answers: what is the overall experience like from first awareness to long-term retention?

A user flow is scoped to a single task inside a specific session. It's operational. It shows exactly what a user clicks through, what decisions the system forces them to make, and where the paths branch. It answers: what happens when someone tries to do X?

If your team is trying to understand why users drop off during trial signup, a user flow will show you the exact decision points and dead ends. A journey map won't have that resolution. Both matter — but they're not interchangeable.

Start with a specific task and a specific user type. Then:

1. Define the start and end state. Where does the flow begin — a landing page, a notification, a menu item? Where is "done"? Both need to be explicit.
2. List every step the system requires. Don't design yet — just map what currently exists or what you're planning to build.
3. Mark every decision point. These are the branches: "if the email is already registered, show error / redirect to login." Decision points are where users get lost.
4. Add failure and error states. A flow that only shows the happy path isn't useful. Map every branch that leads to friction.
5. Annotate with context. Where do analytics show drop-off? Where do support tickets cluster? Where did users hesitate in research sessions?

Tools don't matter much — Figma, Miro, or a whiteboard all work. The thinking is the hard part.

A few patterns to watch for when reviewing flows:

• Too many decision points in sequence usually means the product is asking users to make choices that could be system defaults, or that could be handled through Progressive Disclosure later in the experience
• Long paths to complete simple tasks suggests the Information Architecture is organised around internal team structure rather than how users think about their work
• Missing [Error States](/glossary/error-states) in the flow almost always means missing error states in the product — error paths designed under deadline pressure rather than with UX intent
• Flows that loop back frequently often mean required information wasn't surfaced early enough, or the system forces repeated confirmation steps that erode user trust

Each of these is diagnosable at the flow level — before a single screen is designed.

User flows belong in design review before detailed UI work starts. Reviewing a flow takes 20 minutes. Reviewing 30 screens takes three hours — and structural problems found at the screen stage require rethinking all the screens.

If your team skips straight to Wireframing without mapping flows first, you're making architectural decisions inside Figma, where they're hard to see and harder to debate. The flow makes those decisions explicit and discussable.

A practical habit: for any significant feature, require a user flow to be approved before Prototyping begins. It's a forcing function that keeps design and product aligned on what the experience is supposed to do before everyone has an opinion on what it should look like.