User flow design

Choose the tasks

Start with the tasks that matter most to users and the business: the ones people do often, the ones that earn money and the ones that generate support requests. Each gets its own flow. Trying to map everything at once produces a diagram no one can read.

Parts of a flow

Entry points

People rarely start where designers expect. They arrive from search results deep in a site, from an email link, from a notification or after a password reset. Map each common entry point, because a flow that only works from the home page will fail many users.

Decisions and branches

Flows branch when the user or system makes a choice: logged in or not, delivery or collection, payment accepted or declined. Each branch needs its own path to an end point. Writing branches out reveals rules no one has written down, such as what happens if a discount code expires mid-checkout.

Edge cases to include

Designing a flow

1. 01

   Task

   Pick one task and its goal.

   Output: Task statement

2. 02

   Entry points

   Where users start.

   Output: Entry list

3. 03

   Happy path

   Steps when all goes well.

   Output: Main flow

4. 04

   Branches and errors

   Decisions and failures.

   Output: Full flow

5. 05

   Validate

   Walk through with users and developers.

   Output: Agreed flow

Example: a returns flow

Removing steps

Once a flow is drawn, question each step: is it needed, can it be combined, can the system fill it in? Asking for the same information twice adds friction; WCAG 2.2 criterion 3.3.7 Redundant Entry asks that previously entered information is filled in or available to select, with some exceptions.

Validating flows

Walk through each flow with developers, who will spot technical constraints, and with support staff, who know where customers struggle. Then test the flow with users through wireframes or a prototype.

Keep notation simple

A consistent set of shapes for steps, decisions and end points is enough. The aim is shared understanding, not a perfect diagram.

Showing progress

In multi-step tasks, people want to know where they are and how much is left. Nielsen's first usability heuristic, visibility of system status, applies here: show progress through steps, confirm when something is saved and make clear what happens next. Flows are a good place to decide where these messages appear, because each step boundary is visible on the map.

Leaving and returning

Real tasks get interrupted. Decide in the flow what happens when someone leaves halfway: is their progress saved, do they get a reminder, and where do they land when they come back? These decisions are easy to make on a diagram and hard to add later.