A multi-step form should show progress, preserve work appropriately and distinguish a saved draft from a submitted record. Define validation, session expiry and resume behaviour across the whole journey. Autosave is useful only when users can understand what was saved and the product can recover it consistently.
Let’s plan your form recovery journey.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Group steps by meaning
Arrange fields around coherent decisions rather than dividing a long list into arbitrary screen counts. Explain optional stages and the information needed before starting.
W3C's multi-page form guidance discusses logical grouping and visible progress. Apply those ideas to the implemented interaction, including page titles, headings and errors, rather than treating a decorative stepper as sufficient.
Define the draft lifecycle
| State | Meaning to communicate | Test case |
|---|---|---|
| Editing | Changes may not yet be saved | Navigate away during entry |
| Saving | Persistence is in progress | Network interruption |
| Draft saved | Work is stored under a defined identity | Reopen on another supported device |
| Incomplete | Required work remains | Resume at a useful location |
| Ready to submit | Review is available | Change an earlier answer |
| Submitted | Authoritative record accepted | Repeated click or refresh |
Do not use a single Saved label for both local storage and confirmed server persistence. The distinction matters when a device is lost or another person signs in.
Revalidate dependencies
For a hypothetical business application, changing an organisation type in step one may alter required fields later. Preserve useful answers, but identify those that need review rather than silently submitting inconsistent data.
On resume, check current eligibility, permissions and external choices. A draft may refer to a slot, price or record that no longer exists. Explain what changed without discarding unrelated work unnecessarily.
Handle sessions and shared devices
Define who can access a draft and how long it remains. Avoid exposing one account's entered information after sign-out or account switching. Decide whether anonymous drafts are supported and communicate their recovery limits.
Test final submission separately from saving. Prevent accidental duplicate records, retain a useful reference and show rejected fields in context. A successful draft save does not establish that the final action is accepted.
Form questions
Should every field autosave immediately?
Choose a persistence pattern that fits sensitivity, validation and expected use. Explain the resulting save state accurately.
Should Back discard later answers?
Only where dependencies require it, with a clear explanation. Preserve unaffected work and mark changed assumptions for review.
Use the accessible form checklist, and discuss the complete draft journey with Drema's UI/UX team.
This article explains what to build, not legal advice. Rules change; confirm against the current official text before relying on it.
