Stepper (UI)

A stepper breaks a task into ordered steps and shows where somebody is in the sequence. It appears as a row or column of stages, with the current one marked and completed ones distinguished.

One disambiguation first. The same word is used for the small plus-and-minus control that increments a quantity, which is an unrelated component. This entry is about the progress indicator.

When a stepper helps and when it hurts

It helps when the sequence is real: later steps depend on earlier answers, or the work genuinely happens in an order. Setting up an integration where the second step depends on which provider was chosen is a sequence. Filling in five independent fields is not.

It hurts when it is used to make a long form feel shorter. Splitting twelve independent fields across four screens does not reduce the work; it hides the total, adds three transitions, and usually lowers completion. People judge length once, at the start, and a stepper that conceals it is answering a question dishonestly.

The honest use of a stepper on a long form is the opposite: to make the length visible and finite, so somebody can see that there are three stages rather than an unknown amount of scrolling.

What it must show

The total. How many steps exist. Without it, the sequence reads as potentially endless and somebody has no basis for deciding whether to start now.

Where you are. Marked clearly enough to be seen at a glance, not only by colour.

What is done. Completed steps distinguished from pending ones, so returning is easy.

What each step is. Labels that name the content, not "Step 2". If the labels are too long to fit, that is a signal about the number of steps.

Behaviour that decides whether it works

Back must always work, with everything preserved. Losing entries by navigating backwards is the fastest way to lose somebody entirely.

Let people look ahead where the steps are independent. Many people want to see what is coming before committing to the first screen, and blocking that reads as concealment.

Validate per step, not at the end. Discovering on the last screen that something on the second was wrong means going back through everything.

Save progress. In B2B a multi-step task is frequently interrupted by needing information from a colleague. A sequence that cannot be resumed tomorrow is a sequence that gets abandoned today. See onboarding.

Do not trap on the last step. Somebody reviewing before submitting should be able to return and change something without starting again.

Steppers in B2B products

Interruption is the norm. Credentials, approvals and information from other departments all stall a sequence mid-way. Persistence is not a refinement here; it is the difference between a flow that completes and one that does not.

Steps often belong to different people. An admin does the setup, IT approves an integration, finance approves the spend. A stepper drawn for one person hides that the sequence has handoffs, and each handoff needs its own answer for what happens while waiting.

Branching is common and rarely drawn. Choosing a provider on step one changes what step three contains. A linear indicator over a branching flow will show a step count that turns out to be wrong.

Long forms are still long. Splitting configuration across six screens does not make it shorter, and in a professional tool people often prefer one dense page they can complete in one pass.

Numbers, and what they promise

A stepper makes a commitment the moment it is shown: this task has exactly this many parts.

Breaking that promise is the component's characteristic failure. A four-step indicator that reveals a fifth after the third, or that skips step two silently because of an earlier answer, undermines the one thing a stepper was there to provide.

Where branching is genuine, two honest options exist. Show phases rather than steps, so the count stays true across paths. Or show the count for the path the person is actually on, updating it at the branch and making the change visible rather than letting the number quietly move.

The dishonest option, and the common one, is a fixed indicator drawn for the simplest path.

In practice

An account setup uses a four-step stepper: company, team, integration, done.

Completion is poor and the drop concentrates on step three, where the integration asks for credentials most people do not have. They leave to email their IT department, come back the next day, and the flow has reset to step one with nothing preserved.

Two changes. The sequence saves after every step, so returning resumes in place. And step three becomes skippable, with a clear route back to it, because an account that works without the integration is worth more than one abandoned in front of it.

The stepper itself was fine. What was missing was an answer for the interruption that the sequence made inevitable.

Where teams get it wrong

• Hiding the total. A sequence with no visible end.
• Splitting a short form. Clicks added, length concealed, completion lower.
• No persistence. An interruption becomes an abandonment.
• Validating only at the end. A long walk back for an early mistake.
• A linear indicator over a branching flow. A step count that turns out to be untrue.
• Blocking the way back. Reads as concealment, and often is.