User flows

Why it matters

Before you design screens, you need to know which screens exist and how a person moves between them. A user flow is a diagram of the path someone takes through your product to complete a task: where they start, the steps and decisions along the way, and where they end. Flows catch problems early, such as dead ends, missing error states and unnecessary steps, when changing them costs a pencil line rather than a sprint of development.

The core idea: one task, one entry, one goal

A flow is always about a single task with a clear entry point and a clear success state. "Use the app" is not a flow. "Sam requests a housemate's share of the internet bill, starting from a notification that the bill has arrived" is.

Terms you will hear:

• Task flow: a single, linear path for one task with no branches. Good for a first pass.
• User flow: the same task with decisions and branches, for example what happens if the person is not logged in or a payment fails.
• Wireflow: a flow drawn with small wireframes instead of boxes (useful once you start sketching screens).

Standard shapes

You do not need special software. Most teams use a few simple shapes:

Keep arrows going one direction (left to right or top to bottom) where possible, and label each arrow with what the user does.

Worked example: request a share of a bill

Entry: Sam taps a notification "Internet bill added". Goal: all housemates have been asked to pay.

(Start: taps notification)
  -> [Bill detail screen]
  -> taps "Split"
  -> [Split screen: equal split pre-filled]
  -> <Split equally?> -- no --> [Edit amounts] -> <Totals match bill?> -- no --> [Inline error: "Shares add up to 55, bill is 60"] -> back to [Edit amounts]
                                                                       -- yes --> [Review]
                     -- yes --> [Review]
  -> taps "Send requests"
  -> (system: posts request to house feed, notifies housemates)
  -> [Confirmation: "Requests sent. We'll remind them in 3 days."]
  -> (End: success)

Drawing this exposed three questions the team had not answered:

1. What if a housemate has left the house since the bill period? (New decision: who is included.)
2. What does Sam see if the network drops on "Send"? (New error state.)
3. Does Sam need the Review screen, or can the split screen show a summary? (Possible step to remove.)

Every one of those questions is cheaper to answer now than after screens are designed.

How to draw a flow

1. Write the task, the persona, the entry point and the success state at the top.
2. Draw the happy path first: the shortest route when everything goes right.
3. Count the steps. For each, ask "is this step necessary?" Remove or merge where you can.
4. Add decisions: where the user chooses, and where the system checks something (logged in? valid input? enough balance?).
5. Add the unhappy paths: errors, empty states, cancel and back. Each one needs a screen state or message.
6. Check every branch reaches an end. A branch with no end is a dead end for a real user.
7. Walk through it with your persona: does each step make sense from where they are?

Paper is fine. Free diagramming tools such as FigJam on the free plan, or the free diagrams.net, make it easier to edit.

Common mistakes

• Mapping the whole app at once. Flows get unreadable. One task per flow.
• Only the happy path. Real users mistype, lose connection, cancel and come back later. Those paths need design too.
• Unlabelled arrows. An arrow should say what triggers it: a tap, a choice or a system event.
• Starting at the home screen every time. Many real tasks start from a notification, an email link or a search result. Use the realistic entry point.
• Mixing a flow with a sitemap. A sitemap shows structure (what exists). A flow shows a path through it (what someone does).

Quick recap

• A user flow shows how one person completes one task, from a real entry point to a success state.
• Use simple shapes: ovals for start/end, rectangles for screens, diamonds for decisions, labelled arrows.
• Draw the happy path, trim steps, then add decisions and error paths.
• Every branch must reach an end.

Try it

On the Do tab you will diagram the flow for the key task in your project, including at least two error paths.