Design Principles
Forgiving Formats & State Preservation
When something goes wrong, never make the user re-enter what they already gave you.
Where it comes from
It's a long-standing form-usability guideline, codified by Nielsen Norman Group among others: when something goes wrong, the system should preserve what the user has already done rather than discarding it and starting over.
Why it matters for your website
A mistake shouldn't cost the user their work. Preserving valid input on error, holding state across a failed step, and letting people pick up where they left off all turn a frustrating dead-end into a recoverable moment. Re-entering data you already typed is one of the fastest routes to abandonment.
The cardinal sin is the cleared form. A validation error that wipes everything — or a failed step that loses the user's place — turns a small correction into a full re-entry, and re-entry is one of the fastest routes to abandonment.
Forgiveness means the system absorbs the cost of a mistake instead of passing it to the user. Preserve valid fields when one fails, hold state across a dropped connection, let people resume where they left off. The user's work should survive their error — and yours.
Wrong vs right
A form that clears every field when one validation error occurs, forcing the user to retype everything.
Valid input preserved, with only the problem field flagged, so correcting the error is trivial.
A multi-step flow that loses all progress if a later step fails or the connection drops.
State held across steps and failures, so the user can resume exactly where they left off.
A timeout or error that discards a half-completed submission with no way to recover it.
The submission preserved and recoverable, turning a dead-end into a resumable moment.
Understanding Forgiving Formats & State Preservation
Forgiving formats and state preservation is the principle that a mistake — the user's or the system's — should never cost the user the work they've already done. When something goes wrong, the design should hold on to valid input, preserve progress across a failed step, and let people pick up where they left off, rather than discarding everything and forcing a fresh start.
The failure this guards against is acutely familiar: a form that clears on error, a multi-step flow that loses progress when a later step fails, a timeout that throws away a half-finished submission. Each converts a small problem into a large one, because the user must now re-do work they'd already completed — and re-doing work is exactly when people give up.
The underlying stance is that the system, not the user, should absorb the cost of an error. Preserving valid fields, holding state across failures, and offering a resumable path all turn a frustrating dead-end into a recoverable moment. It connects to error prevention, error recovery, and Postel's robustness principle.
How Kweri checks it
Whether a system preserves a user's work on error is largely a behavioural property that reveals itself when something goes wrong, which a static review can't fully exercise. Kweri can sometimes note risk factors — long forms with no obvious draft-saving, multi-step flows — and prompt you to check recovery behaviour. But genuinely confirming that valid input survives an error, or that a failed step doesn't lose progress, means deliberately triggering errors and watching what happens. So Kweri raises the risk and prompts the test, while verification comes from exercising the failure paths.
FAQ
What is state preservation in forms?
State preservation is keeping a user's valid input and progress when an error or interruption occurs, rather than discarding it. It means a mistake doesn't cost the user the work they've already done — they can correct the problem without starting over.
Why shouldn't a form clear on error?
Because re-entering data is one of the fastest routes to abandonment. Clearing a form over a single mistake turns a small correction into full re-entry, punishing the user for an error the system could have handled gracefully.
What does 'forgiving formats' mean?
It means the system absorbs the cost of mistakes rather than passing it to the user — preserving valid fields when one fails, holding state across interruptions, and accepting input flexibly so small errors don't derail the whole task.
How do I preserve work across a failed step?
Hold form state across steps and failures, save drafts where appropriate, and offer a way to resume exactly where the user left off. A dropped connection or failed submission should never silently discard everything they entered.
How is this related to error prevention?
Error prevention stops mistakes happening; forgiving formats and state preservation handle the mistakes that do happen gracefully. Together they ensure errors are rare and, when they occur, cheap to recover from rather than costly.
Related principles
Error messages should be plain English, name the exact problem, and suggest the fix.
User errors divide into two fundamentally different types: slips (right goal, wrong action — a lapse of execution) and mistakes (wrong goal — a failure of understanding). Each requires a different design response.
Errors should be flagged as users complete each field, not after the entire form is submitted — post-submit error discovery forces users to stop, hunt for problems, and often repeat work they've already done.
Attribution & sources
Identified by Nielsen Norman Group. Catalogued from Nielsen Norman Group — Error-Message Guidelines for Forms.
A long-standing form-usability guideline codified by NN/G and others; the linked article is the reference used here.
See Forgiving Formats & State Preservation on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →