User Flow

Draw screens one at a time and the space between them stays empty. Twelve designs can each be excellent, and stitching them together turns up one screen nothing leads to, plus another that two paths enter and only one path leaves. None of that is visible while looking at a single screen.

So the questions arrive after the build starts. Where does someone with no payment method on file get sent? Which screen does an invited person without an account see first? Nothing in the designs answers that, so answers get invented on the spot, and situations of the same kind get handled differently on different screens — a message here, a bounce back to the home screen there. Neither choice is wrong on its own; having both in the same product is.

A user flow is the work of drawing the space between screens rather than the screens. Lay out which screen leads to which and what condition sits on each connection, and the questions that would have come up mid-build come up while drawing instead.

Pick one starting point and one goal, then connect what's between them. One page holds one goal.

Four things go into the drawing.

1. The entry point. Write down where people come in from. Someone who clicked a link in an invitation email and someone who arrived from a search start on different screens, and collapsing that into one entry point erases the first half of the flow.
2. Screens. Each screen the user sees becomes a box, holding the screen's name and the actions available on it.
3. Branches. Points where a condition splits the path get a different shape. Is the person signed in? Is there a payment method? Do they have permission to open this document? Each one is a question with a yes side and a no side, and both sides need a destination.
4. End points. The state where the goal is met — and there's usually more than one. Separating "finished sharing" from "gave up partway" from "hit a wall" is what shows you later where to work.

There's an order to drawing it. Lay down the happy path, the route where nothing goes wrong, as a single line first, then attach the branches. Start from the branches and one page turns into twenty-four routes that nobody reads.

Four branches are the ones most often missed: not signed in, no permission, nothing to show yet, and the request failed. None of the four tends to get designed, and all four happen constantly in real use. Leave out the screen for an empty list and the first thing a new user sees is a screen that doesn't exist.

Split the page when it grows. Drawing signup through first shared document on one page runs past twenty boxes, and at that size the eye can't follow where the conditions sit. Splitting the goal in two works better.

There are four places the drawing gets used.

The first is before any designs get made. Draw the flow and the list of screens to build falls out of it: eight of the fourteen boxes already exist and six have to be designed, known before anyone starts.

The second is handing work to engineering. When the answers to mid-build questions are already in the drawing, the questions don't come. One diamond saying where a person without permission goes is enough.

The third is lining it up with numbers. Funnel analysis, which shows how many people drop out at each step, gets far more useful when its steps match the boxes in the flow, because then the drop-off numbers sit directly on the drawing. When the steps don't match, "half of them leave at step three" starts with an argument about which screen step three is.

The fourth is scoping automated tests. An end-to-end (E2E) test, which runs a whole user flow the way a real person would, needs a decision about what to run, and the happy path line is the first candidate on that list.

Some flows have their own names for a specific goal. A signup flow, the sequence of screens up to a created account, is one, and it's the flow growth teams redraw most often.

"The designs look good, but without a flow I can't tell how anyone gets to this screen."

One screen isn't enough to judge; what comes before and after has to be there.

"Where does someone without permission go from here?"

The branch wasn't drawn, so the person building it has to decide.

"I put the numbers on each box and half of them leave at the third one."

The drawing and the metrics line up, so the place to fix narrowed to one screen.

At Pagedeck, Noa drew the document sharing flow on one page. The happy path was four boxes — open document, press share, choose permission, copy link — with three branches attached: whether the recipient has an account, whether the sharer has permission to share, and whether org settings block external sharing.

Theo's first question came from the third branch, because nothing said whether a blocked attempt should show a message or send a request to an admin. Ravi took the box names from the same drawing and used them as the funnel step names, which is what let the drop-off numbers land on the drawing later.

The most common mistake is treating a flow as something drawn once. It's used before work starts, so that reading is easy to fall into. But screens keep changing afterwards and the drawing stays put. Whoever opens that file six months later sees a route the product no longer has, and a wrong drawing is worse than no drawing. So either refresh it when the work is finalized, or keep it inside the design file itself so it gets edited when the screens do. The second option costs nothing to maintain, which is usually why it wins.

The second is thinking every branch has to be drawn. Covering every condition looks thorough and gap-free. But five conditions produce more than thirty routes, and even the person who drew that page won't read it again. Two tests decide what makes the cut: does it happen often, and does it hurt when it goes wrong. Draw the case that happens dozens of times a day and the case where one mistake exposes someone else's document, and write the rest down in a sentence beside the page.