Multi-Step Flows
Breaking a long task into steps, which reduces per-screen load but adds navigation cost and abandonment points.
Definition
A multi-step flow divides a task into sequential screens. It reduces the amount visible at once and allows validation per step, at the cost of extra transitions and more places for the user to leave.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- Tasks are long and have natural phases.
- Branching logic is required.
- Users need to resume across sessions.
Common mistakes
- Data lost on back navigation.
- No visible progress.
- Splitting a short form for no reason.
- Focus not managed across steps.
- Reporting step completion as progress when the abandonment simply moved to a later step.
When splitting helps
- The task has genuinely distinct phases that map to how users think about it.
- Later steps depend on earlier answers, so branching is required.
- The full form is long enough to be intimidating as one screen.
- Progress needs to be saved and resumed across sessions.
Requirements
- Show total steps and current position, using step names rather than only numbers.
- Allow backward navigation without data loss.
- Save progress automatically at each step.
- Validate per step, so errors surface close to where they were made.
- Provide a review step before final submission for anything consequential.
- Manage focus on each transition: move it to the new step heading so screen reader users know the context changed.
Splitting a task well
Do
- Split on genuine boundaries, where one decision affects the next.
- Show how many steps there are, and which one this is.
- Save progress, so leaving is not losing.
- Offer a review step before anything irreversible.
Do not
- Split a short form to make each screen look tidy.
- Validate only at the end, so errors send the reader back three screens.
- Prevent going back to change an earlier answer.
- Add a step that collects nothing, such as a welcome screen.
Progress indicators, and what each one promises
| Indicator | Works when | Fails when |
|---|---|---|
| Named steps, all visible | Steps are few and meaningful to the reader | Names are internal jargon, such as Entity details. |
| Step n of m | The total is fixed and honest | Branching changes the total mid-flow, which reads as the goalposts moving. |
| A percentage bar | Steps are roughly equal in effort | Step four is longer than the first three together. |
| A checklist that persists | Setup that can be left and resumed | It never reaches complete, so it becomes furniture. |
| No indicator | Two steps, or a flow that is obviously short | Anything long enough that the reader wonders how much is left. |
In practice
- i.
Review before submit
Applications and checkoutA summary of everything entered, with edit links to each step, catches errors before submission and removes the anxiety of committing to something the user can no longer see.
- ii.
Seven steps, four fields
Splitting for its own sakeA signup split into seven screens each holding one field had four times the abandonment of the single-page version. Each transition is a place to leave, and the total work never changed.
Commonly confused with
Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.
Stepper
ComponentThe indicator naming the stages and marking the current position.
Key difference
A multi-step flow is the division of the task itself. A stepper is the small map that shows where you are inside it. Splitting a task without a stepper leaves people lost; adding a stepper does not make a badly split task better.
Use Multi-Step Flows when
- The decision is whether to split the task at all.
- The steps are genuinely sequential, not merely numerous.
- You are weighing per-screen load against abandonment.
Use Stepper when
- The split already exists and people need orientation.
- How many steps remain affects whether they start.
- Going back to a finished step should be possible and visible.
Local chart
PAT·016 · Region III · Grid F1
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Principles behind this
The reasoning this solution is an application of.
- User Control and FreedomHEUR·003 · Heuristic
- Goal-Gradient EffectLAW·014 · Law
Visible progress accelerates completion as the end gets closer.
- Zeigarnik EffectLAW·010 · Law
- Decision FatiguePSY·010 · Psychology
Often used with
These usually appear in the same screen or the same decision.
- Progress IndicatorCMP·026 · Component
- TabsCMP·016 · Component
- Input ValidationPAT·007 · Pattern
- User FlowTPL·005 · Template
Alternative approach
A different answer to the same problem, with a different cost.
- Progressive DisclosurePRIN·003 · Principle
One long form with disclosure, or several short steps. The choice turns on whether the parts are genuinely sequential.
Practical example
A worked decision where this was the deciding factor.
- One Long Form or Several Short StepsCASE·009 · Case study
- Whether to Require an Account at CheckoutCASE·001 · Case study
Check your work
Review passes that test whether this was done properly.
- Form UX ChecklistCHK·001 · Checklist
Related concept
Connected closely enough to change how you apply this.
- PRD to User FlowAI·002 · AI workflow
- User FlowsFLOW·009 · Workflow