UIREADY.dev
30% offEnding soon
FSD-018Frontend system design Premium

Design a Wizard and Multi-Step Form Engine

Design a production multi-step form with branching, validation, resumable drafts, browser navigation, accessible errors, analytics, and safe submission.

Intermediate 55 min read

A production wizard is a versioned workflow over one canonical answer model. The step graph decides what is reachable, validation guards transitions, revisioned drafts preserve progress, and final submission remains one authoritative server operation.

A basic multi-step form can be a page index and a collection of values. That model breaks when an earlier answer removes three later steps, browser Back returns to an obsolete screen, a phone saves a newer draft than a laptop, or the server upgrades the schema while a user is halfway through.

The useful shift is to stop treating the wizard as a slideshow. Model it as a directed graph. Each step owns a set of fields. Guarded edges inspect canonical answers and choose the next reachable step. The visible progress indicator, browser history, validation scope, and submitted payload are projections of that model.

Start with the product contract

Clarify whether the flow is a short onboarding sequence, a long regulated application, an anonymous survey, or a money-moving checkout. Ask whether users can resume on another device, whether branches can change after review, how long drafts live, and whether more than one actor can edit them.

For this interview, assume six to twelve possible steps, conditional branches, authenticated resumable drafts, browser Back and Forward support, occasional offline editing, and one final server submission. A generic schema renderer, workflow authoring UI, simultaneous collaborative editing, and payment processing are separate systems.

The public interview prompt

Design a wizard and multi-step form engine. Explain:

  • the versioned step graph, guarded branches, and reachable-path derivation;
  • canonical answers, hidden-field retention, validation scope, and error focus;
  • browser URL and history behavior, reload, deep links, and restoration;
  • local and server drafts, autosave, revisions, conflicts, migration, and offline recovery;
  • idempotent final submission, whole-payload validation, and business authorization;
  • accessibility, internationalization, privacy, analytics, observability, and testing;
  • loading, stale, partial, failed, expired, and schema-upgrade states;
  • simpler alternatives, rollout, and an interview-depth rubric.

What the premium solution covers

The full solution builds the graph evaluator, canonical answer store, transition guard, branch cleanup policy, history adapter, revisioned draft protocol, conflict UX, and idempotent submission envelope. It also covers accessible progress and errors, schema migration, security, privacy-safe analytics, performance, testing, rollout, and interviewer follow-ups.

Original media follows a branch change through path pruning and draft persistence, maps graph and state ownership, and traces the final submission transaction. Two deterministic labs expose branch and draft-conflict decisions directly.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

What is the core model for a multi-step form?
Use a versioned directed graph. Nodes are steps, guarded edges choose the next step from canonical answers, and terminal nodes submit or end the flow. Derive the reachable path instead of storing it as mutable truth.
Should each step be a separate HTML form?
Each screen can use native form controls and submission behavior, but the wizard owns one canonical answer model across steps. A step commit validates its declared scope without pretending the final server command has already succeeded.
What happens to answers when a branch disappears?
Choose and document a field policy: retain for possible return, clear immediately, or quarantine outside the active payload. Never let hidden answers silently reach final submission.
How should Back and Forward work in a wizard?
Put a stable, reachable step ID in browser history and keep form data in the wizard store or draft system. On popstate, re-evaluate reachability and redirect to the nearest valid step if the old entry is no longer reachable.
How do resumable drafts avoid lost updates?
Every save carries a schema version, base draft revision, and idempotency key. The server rejects stale revisions or returns a conflict that the client resolves explicitly. An old response must never overwrite newer local typing.
Does per-step validation replace final validation?
No. Per-step validation provides timely feedback. The server must authorize and validate the complete reachable payload again during one idempotent final submission.