How to Turn User Research Into a User Flow

Key Takeaways

• Extract decisions and questions, not steps. Steps describe what exists; questions describe what users need.
• Every step in a flow should answer a question the research showed people actually ask.
• Keep the evidence attached to the step. A flow separated from its research becomes an opinion within a month.
• Map the unhappy paths from real observed failures rather than imagined edge cases.
• Distinguish what users did from what they were trying to do. Workarounds look like behaviour and are evidence of a missing path.
• A flow with no research behind a step is a hypothesis. Label it as one.

Steps Are Not the Unit

The common approach is to watch what people do, write down the sequence, and draw it. The result is an accurate diagram of the existing product, including its problems, presented as a design artifact.

The problem is that observed steps are a mix of three things: what the user wanted to do, what the interface required them to do, and what they did because they could not find the thing they wanted. Only the first is a genuine requirement. The second is your current design and the third is a defect.

A flow built from all three preserves all three.

Decisions are the durable unit. Underneath the steps, the user is making a sequence of decisions: is this the right product, do I trust this company enough to give them a card, is the cheap plan enough for me, can I undo this if I am wrong. Those decisions are stable across redesigns. The screens are not.

The reframe: instead of "user clicks Compare Plans", write "user needs to decide whether the cheaper plan will run out". The first tells you what exists. The second tells you what has to be answered and leaves the solution open.

A useful diagnostic: take any step in your current flow and ask what question the user is answering there. If the answer is "none, it is just how the product works", that step is a candidate for removal.

Extract the Questions

Go through your research (interviews, session recordings, support tickets, sales calls) and pull out every moment a user hesitated, asked something, backed out or did something unexpected.

For each one, write the question they were trying to answer.

Hesitation before entering a card: "will I be charged now?" Backing out at plan selection: "which of these am I?" Opening a second tab: "is this cheaper elsewhere?" Contacting support after signup: "did that work?" Abandoning at an upload step: "what happens to my file?"

Keep the quote. The exact words matter, because a paraphrase drifts and because in a review three months later, a real quote settles an argument that a summary cannot.

Note frequency and severity. A question asked by one participant out of eight is not the same as one asked by seven, and a question that caused abandonment is not the same as one that caused a pause. You will use both to decide what the flow must answer prominently and what can be a link.

Cluster and Sequence

Group the questions. Twenty extracted questions usually reduce to six or seven distinct concerns, because people ask the same thing in different words.

Then sequence them by when they arise, which is rarely the order your current product presents them.

This is where most flows are wrong. Products routinely ask for commitment before answering trust, or ask users to choose a plan before they have any basis for choosing. The research will show this clearly: the questions people ask early are frequently answered late in the current flow, or not at all.

Order the questions by when they occur in the user's head. Then design steps to answer them in that order.

Two rules for sequencing. Answer trust questions before you ask for anything irreversible. And answer "which one am I" before you ask someone to choose, which usually means the choice needs a recommendation rather than a comparison table.

Draw the Flow

Now the diagram. Each step is a place where one or more questions get answered.

Attach the evidence to the step. This is the part almost every workflow drops, and it is the difference between a flow that survives a review and one that does not.

Six weeks after you draw it, someone senior will ask why the plan selection comes after the workspace is created. If the flow carries the three quotes showing that people could not choose a plan before seeing what the product was, that is a thirty-second conversation. If it does not, it is your opinion against theirs, and the flow gets changed.

This is where a diagramming tool and a canvas differ in practice. Lucidchart and Whimsical produce clean flows and treat research as something that lives elsewhere, so the link is maintained by hand or not at all. On a Storyflow canvas the quote sits next to the step it justified, and because its AI reads the whole board you can ask which steps have no supporting evidence, which is the review question you want to answer before someone else asks it.

Label unsupported steps as hypotheses. Some steps will have no research behind them, because you have not tested that part. That is fine and it should be visible. A flow where the evidenced and the assumed look identical invites everyone to treat the whole thing as evidenced.

Map the Unhappy Paths From Real Failures

Most flows draw the happy path in detail and gesture at errors. The research usually contains the opposite emphasis, because the interesting material is where things went wrong.

Use observed failures, not imagined ones. Teams invent edge cases that never occur and miss the ones that happen constantly. Your support tickets are a list of the real ones, and they are usually a short list.

For each observed failure, three questions: how does the user find out, what can they do about it, and can they get back to where they were.

Recovery is the commonly missing piece. Flows show the error state and not the route out of it. In the research, the moment where someone realises they made a wrong choice and cannot see how to undo it is where trust is actually lost, more than the original mistake.

Workarounds Are the Best Signal

When a user does something the product did not intend (exporting to a spreadsheet to do a thing your product should do, keeping a separate list, using a field for something other than its purpose), that is the highest-value observation in the whole research set.

A workaround is a user telling you a path is missing, and telling you precisely enough that the design is nearly specified. They have already worked out what they need; they just had to build it from parts.

The mistake is treating workarounds as user error or as power-user behaviour. They are unmet requirements, and they are more reliable than anything a user says when asked what they want, because the workaround cost them real effort.

What Goes Wrong

The flow reproduces the current product. Built from observed steps rather than extracted questions.

Research is summarised, not attached. The flow cannot defend itself in a review, and the most senior opinion in the room wins.

Edge cases are invented. Time spent on failures that never happen while real ones stay unhandled.

Hypotheses look like findings. Unsupported steps drawn identically to evidenced ones, so the whole flow gets treated as validated.

Only the happy path is detailed. Recovery routes missing, which is where trust is lost.

Trust questions answered late. Commitment requested before the user has a reason to commit, which the research almost always shows.

The Bottom Line

Extract the decisions, not the steps. Pull every hesitation, workaround and question out of the research, cluster them, sequence them by when they actually arise, and design steps that answer each one at the right moment.

Keep the quotes attached to the steps, mark the parts you are guessing, and build the unhappy paths from failures you observed rather than ones you imagined. A flow that carries its evidence is a flow that still exists in six months.