User Flow Design: How to Map Better Digital Experiences

User flow design means mapping the steps a person takes to complete one task in your product: where they enter, what they see, what they do, which decisions they face and where they can end up. A good flow covers the happy path, the alternative paths and the error paths, not just the ideal route. Map one user and one goal at a time, count the steps, remove or defer anything that doesn't help the user reach the goal, then validate the flow with a prototype and real users before building it.

A user flow is a diagram of how someone completes a specific task inside a product: signing up, finding a product, inviting a teammate, booking an appointment. Nielsen Norman Group describes flows as the typical or ideal steps for a common task within a product, usually completed in minutes, drawn as flowcharts or wireflows.

Flows sit between research and screens. They turn what you learned about users into a sequence you can design, and they make gaps obvious before anyone draws a detailed interface. In the UX design process, they usually come after information architecture and before wireframes.

These artifacts are often confused. They work at different zoom levels.

Agree a simple notation and use it everywhere. Most teams need only a few shapes.

The happy path is the shortest route when everything goes right. It's where most design attention goes and, ironically, where fewest problems live.

Alternative paths are legitimate routes that differ from the ideal: checking out as a guest instead of signing in, saving an item for later, choosing collection instead of delivery, entering through a deep link instead of the homepage.

Error paths start when something goes wrong: a declined card, an expired link, an out-of-stock item, a failed upload, a lost connection. A flow is only complete when every error path leads somewhere useful, ideally back onto the main path without losing the user's work.

Sign-in looks simple until you map it. A complete flow covers new and returning users, social or passkey sign-in if offered, forgotten passwords, expired reset links, locked accounts, email verification, two-factor authentication and what happens when a user who signed up with one method tries another.

Mapping these branches early prevents a common problem: users stuck in a loop between “account already exists” and “no account found”. For implementation detail, see mobile app authentication.

The diagram at the top of this article shows a simplified checkout flow. From the cart, the flow branches on whether the shopper is signed in; guests go through a guest or sign-in choice and rejoin the main path at delivery. From payment, a declined card leads to an error state that keeps the shopper's details and offers a retry, rather than sending them back to the start. Saving an item for later is an alternative path from the cart.

Mapping checkout this way makes hidden costs of each branch visible, such as the number of fields a guest must complete. The ecommerce checkout UX guide covers the design of each step.

Inviting a colleague is often the moment a SaaS product becomes a team product, and it has more branches than it seems: the inviter's permission level, whether the invitee already has an account, whether the email domain is allowed, seat limits on the current plan, pending invitations, expired links and what the invitee sees when they arrive. Each branch needs a clear message and a route forward. See product design for SaaS for how flows like this affect activation.

Mobile flows need branches that web flows often don't: permission prompts (and what happens if the user declines), entry through a push notification or deep link straight into a screen deep in the app, the app being backgrounded mid-task, offline states and biometric sign-in. A booking flow, for example, should specify what happens if the chosen slot is taken while the user is entering details, and how they return to the booking after a phone call interrupts them.

Once a flow is mapped, review it for signs of unnecessary effort.

A flow on a whiteboard is a hypothesis. Validate it by building a clickable prototype and running usability tests with realistic tasks. For live products, compare the mapped flow with funnel analytics: if many users leave at a step the flow considered trivial, the map is missing something. If users can't find where a flow starts, the problem may be structural, which is where information architecture and user flows meet.

Sticky notes and a whiteboard are enough for early flows. For shared, lasting flows, teams commonly use FigJam, Miro or Figma itself, which keeps flows next to the designs they describe. See Figma for product design for how teams organize this. Keep flows versioned and linked from tickets so developers work from the current one.

User flows turn a goal into a designed sequence. Map one user and one task at a time, include alternative and error paths, simplify ruthlessly and validate with users. Flows then become the backbone of wireframes, prototypes and developer handoff. For where flows fit in the bigger picture, see the product design process.