Stepper

Forms with twenty fields stacked on one page used to be normal. Open a page where the submit button is five scrolls down and the first thing a person does is measure the length; judging it long, they don't start. On a form collecting business registration details, people kept filling in about half of it, asking when it would end, and closing the tab. The form wasn't broken; it simply announced its own length before it announced its purpose.

So the page got split. Twenty fields cut into four pages of five each makes any single page light. But splitting alone made some cases worse. Press next and move on, and there is still no way to know how many more times you'll press it — which feels like walking down a corridor with no visible end. That produces more unease than seeing all twenty fields at once.

Splitting and telling the user where they are had to arrive together. Stepper is the name for that pair. It cuts the process up while putting the total number of stops, the current position, and what has already been passed on the same screen.

The process gets cut into a handful of steps, and a list of those steps sits across the top of the screen marking the current position. Five things have to be decided when building one.

1. The number of steps. Three to five is typical. Two isn't worth splitting, and past seven the list no longer fits the width of the screen, which kills the position marker it exists for. When it doesn't fit, group similar steps together to shorten it. Two questions that ask about the same thing rarely need separate screens.
2. A name per step. Not "Step 1" but "Company details" and "Payment method" — what the step is about. Names let people see what's still ahead and go fetch a document before they get stuck on it.
3. Three visually distinct states. A check on steps already passed, emphasis on the current one, dimmed treatment on the ones still to come. Render all three the same way and the list is present but unreadable.
4. Whether going back is allowed. Leave passed steps clickable, and make sure values already entered are still there on return. If they're cleared, someone going back to fix step two ends up refilling step one.
5. Saving per step. Save only on final submit and anyone who closes the tab on step three restarts from nothing.

When validation runs belongs to the rules too. Check the values as the next button is pressed, within that step only. Validate everything at the end and the error list mixes in items from step three, leaving the user hunting for where to go back to.

For accessibility, focus has to move to the first input of the new step when the step changes. Focus is the state of being selected by keyboard, and without this handling the selection point stays on the previous screen after next is pressed, so a keyboard-only user never reaches the new step.

Use it where the order genuinely matters and the end is fixed. Sign-up and initial setup, a checkout running from address through shipping method to payment, business verification where an answer in one step changes what the next step asks for. Choose sole proprietor or corporation in step one and the documents requested in step two differ. One long page can't express that dependency without hiding and revealing blocks as the user scrolls.

Where not to use it is clearer still. Content that can be visited in any order belongs in tabs. General, notifications, and security in a settings screen have no before and after, so making them steps is wrong. A list that is merely long gets split into pages with pagination, and supporting detail that can stay collapsed goes into an accordion.

Small screens don't have the width for every step name. Truncating them leaves labels nobody can read, so the usual answer is showing the current step's name at full size and reducing the rest to a figure like "2/4". Even a bare figure still carries the total length and the current position, which is most of what the element is for.

"Seven steps. Let's group the similar ones and get it down to four."

The step count itself is the burden, so reduce the number.

"Validating at the end means one error sends you back to step three."

Validation should move into each step.

"These three have no order. Tabs are the right call here."

It's a set of categories, not a process, so a different element applies.

Pagedeck built its enterprise setup flow as a stepper: company details, inviting members, permission rules, payment method. The first version had seven steps, and Noa collapsed it to four after usability testing showed half of participants abandoning at step three.

Theo added per-step saving when implementing it, which is why Sofia can now tell a customer on a call that their account is through step two. Asking a stalled customer where they stopped became unnecessary, and the support conversation starts from the actual state instead of a guess.

The most common belief is that finer splitting is better. Fewer fields per screen looks like less burden, and taken one screen at a time it is. But what the user measures is not the length of one screen; it's the number of steps remaining. Split twenty fields across seven steps and each screen gets lighter while seven markers appear in the list, and on the third one the fact that they aren't halfway yet is plainly visible. Abandonment rising after steps were added is not unusual, which is why reducing the count is usually the first thing to try. Merging steps costs less than redesigning the screens inside them.

The other frequent view is that blocking backward movement is safer. When answers in earlier steps determine what later steps contain, editing backwards gets complicated, so locking it looks like a way to keep the data clean. In practice people abandon the whole thing over a single typo. Someone who mistyped one digit of a registration number and can't find the way back closes the tab and starts over, or gives up. Making an earlier edit force a recheck of the later steps always costs less than sealing the path shut — clearing only the later steps affected and asking for them again is how that's done.