Long Forms Lose People: Building Multi-Step Forms That Get Finished

Sooner or later every product grows a long form: an application, a booking with details, an onboarding questionnaire, a settings maze. Presenting the whole thing as one page is the standard mistake, and the usual fix, splitting it into steps, is a mistake about as often. Whether a wizard helps depends on how the steps are cut, whether progress survives an interruption, and whether the final page can still reject something the user thought was done two screens ago. Those three decisions are the whole design.

Cut steps where the topic changes

A step should be a subject, not a quota. Contact and address belong together; payment belongs alone; anything conditional branches off its trigger. Two heuristics that hold up:

Fields in a step should be answerable from the same mental context. If the user has to think about their household and their bank account in the same screen, the split is wrong.
Steps with a single field are usually noise. They exist to pad a progress bar, and users notice. Merge them or give the step a real reason, like a review panel.

Name steps in plain words, "About you", "Payment", "Review", and number them. A progress bar showing "Step 2 of 4" with named steps sets expectations; an anonymous bar just measures anxiety.

Save progress, or the wizard is a trap

The strongest argument for a multi-step form is that it lets people leave and come back. That argument is false unless each step persists. Submitting everything only on the final screen turns the wizard into one long form with a loading screen in the middle and loses the whole session on a tab close.

Save each completed step to the server. With Inertia and Laravel, a step submit is a normal POST that stores a partially filled model or draft, returns, and advances:

public function storeStep(QuoteRequest $request)
{
    $draft = $request->user()->quoteDraft()->updateOrCreate(
        [], $request->validated()
    );

    return redirect()->to(route('quote.step', $draft->next_step));
}

Server-side storage beats localStorage here for one specific reason: a draft tied to the account can be resumed on another device and can carry the user an email, "finish this tomorrow from where you left off." That notification regularly recovers applications nothing else would.

Validate per step, then again at the end

Client-side per-step validation keeps the pace honest: nobody reaches step four with an invalid email from step one. Server-side, validate each step on arrival, but keep the full final validation too, because the server must never trust that a client walked the path in order. Re-validate the complete dataset at submit:

$validated = $draft->validateComplete();

and make the final screen a review of everything entered, with an edit link per section. If the review page ever reveals a validation error, it should say which step owns it and jump there. A wizard that dead-ends with a red summary is the failure users remember.

Two small details worth the ten minutes each:

Back must not lose data. Every field should rehydrate from the stored draft, browser back included.
Autofill and autocomplete attributes, name, address-line1, cc-number, work across steps the same as on one page. Browsers fill per field, not per page, and every field the browser fills is friction removed.

When one page is still right

Short forms, and forms where fields are corrections to each other, pricing calculators, configurators, belong on one page. Splitting five fields into three steps is the pattern people bounce off: every step boundary is a chance to leave, and you'd be adding chances without adding clarity.

The test for a wizard is simple. Can a user fill half of it today and the rest tomorrow on a different device, with nothing retyped? If yes, the steps earned their place. If it all hinges on one sitting and one page state, build a single form with good grouping instead.