How to build a multi-step form — so people actually finish it

A twelve-field form looks like work. Someone sees the wall, estimates the effort and closes the tab — before noticing that half those fields would have filled themselves in a second.

The same twelve fields across four screens of three look like "fine, a minute". Identical work. Different feeling. Here's how to build that without losing the answers on the way.

Step 1. Cut by meaning, not in half

Not "four fields per screen" but one idea per screen. The GOV.UK Design System puts it this way: start by asking one question per page — it helps people understand what is being asked and focus on the answer.

Grouping fields is fine when a person treats them as one thing: an address is a single idea even though it's four fields. "Phone number and favourite colour" is two.

Practical consequence: the screen heading is the question. "Where should we deliver?" beats "Step 2. Details".

Step 2. Collect answers in one place

The classic technical mistake is keeping answers in the fields themselves. Fields live exactly until the screen re-renders.

Keep one object and put answers in it:

const answers = {};

function saveStep(form) {
  const data = new FormData(form);
  for (const [key, value] of data.entries()) {
    answers[key] = value;
  }
}

In React it's the same idea: one state object for the whole form, not separate state inside each step.

And mirror it to localStorage straight away — one line saves the person who closed the tab by accident:

localStorage.setItem("draft", JSON.stringify(answers));

Step 3. Show where they are

"Step 2 of 4" removes the main anxiety of a long form: how much is left. Write it as text, next to the heading.

A progress bar is optional. GOV.UK suggests adding a progress indicator only if research shows it helps — on its own it takes space and explains nothing. With three steps, the numbers are enough.

Step 4. Make Back real

The most common failure of a multi-step form: someone hits Back and the fields are empty. They don't come back a second time.

What this needs:

• A Back link at the top of the screen — GOV.UK puts it there because some people don't trust the browser's back button while entering data.
• The browser button must still work properly: it should return to the previous screen in the state they last saw it.
• When returning to a step, refill the fields from your saved answers — they're already in the object from step 2.

function fillStep(form) {
  for (const field of form.elements) {
    if (answers[field.name] !== undefined) field.value = answers[field.name];
  }
}

Step 5. Validate on transition, not on every keystroke

Run validation when they press Continue, not when they leave a field. GOV.UK warns specifically that validating on field exit causes problems, especially for people who type slowly — they haven't finished the word and it's already flagged as wrong.

On each step validate only that step's fields. If something's off, show the screen again with the entered values still in place and say exactly what to fix. Decide which fields are required up front: with three fields on screen it's obvious either way.

Step 6. Make the second-to-last screen a review

Before submitting, list everything they entered: question — answer — "change" link. GOV.UK has a dedicated pattern for it, and it does three jobs at once: it lets people re-read, lets them fix something without walking the whole form again, and removes the "did I get that wrong and now it's final" fear.

Then protect submit from a double click by disabling the button immediately:

submitButton.disabled = true;

What you get

A form with two or three fields and a clear question per screen; where Back returns filled fields, not empty ones; where everything is visible before it's sent. The data goes out in a single request at the end — the server gets one complete set instead of four pieces to stitch together.

There's a useful side effect: this form is far easier to fix. If people quit on screen three, you know which question scared them off. In one long form that spot is invisible.

If you have five fields rather than twelve, don't split anything. A single screen with a plain form is faster and more honest.

How many steps is reasonable?

As many as you have meaningful groups of questions — usually three to five. Ten screens with one field each irritate people just as much as a wall: every transition is a click and a wait.

Should I save answers on the server between steps?

For a short form, no: keep them in a client-side object and send everything at the end. The server matters when filling takes a while and someone might come back tomorrow or from another device. Then save a draft after each step and hand it back on their next visit.