Forgiveness
An interface people can explore without fear produces confident users and fewer support tickets.
Definition
A design principle holding that systems should tolerate exploration and error, making most actions reversible, most states recoverable, and consequences visible before they are permanent.
Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.
On this plate
Reach for this when
- Designing content creation and editing.
- Any operation with wide or delayed effects.
- Products where exploration is the main learning path.
- Usage data shows people using a narrow, safe subset of a much larger product.
Common mistakes
- Undo windows shorter than the time it takes to notice a mistake.
- Version history that is hard to read or restore from.
- Reversibility that exists technically but is not visible to the user.
Fear is a usability cost
Users who are unsure whether an action is safe will avoid it. That shows up as unused features, as duplicate records created because someone was afraid to edit the original, and as support requests asking what a button does.
Forgiveness is what makes exploration a viable learning strategy. Without it, the only safe way to learn a product is documentation, and most people will not read it.
Mechanisms
- Undo for anything reversible, available long enough to be used.
- Version history for content, so an edit is never a loss.
- Soft delete with a restore window rather than immediate destruction.
- Autosave with visible drafts, so interruption costs nothing.
- Preview before commit for anything with a wide effect.
- Non-destructive defaults: duplicate rather than overwrite, add rather than replace.
Mechanisms, from cheapest to most involved
| Mechanism | Protects against | Cost |
|---|---|---|
| Undo | The action just taken | Low, and it removes most confirmations |
| Autosave with history | Lost work and bad edits | Moderate, needs storage and a way to browse |
| Draft and publish separation | Publishing something unfinished | Moderate, and it changes the mental model |
| Soft delete with a restore window | Deletion regretted later | Moderate, plus a policy on when it really goes |
| Sandbox or test mode | Learning on real data | High, and it must be obviously distinct |
In practice
- i.
Version history in collaborative editors
DocumentsFull history plus named versions makes editing a shared document safe. Without it, teams create copies defensively and the single source of truth stops being single.
- ii.
Draft and publish separation
Content managementSeparating the editing state from the published state makes experimentation free. The user can be wrong in private, which is the point.
- iii.
Exploration depends on it
What fear costsIn a product with no undo, people stop clicking things they have not clicked before. The cost does not appear as errors. It appears as features that are never tried and a product that feels smaller than it is.
Local chart
PRIN·006 · Region I · Grid A2
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
The Design of Everyday Things
D. A. Norman, Basic Books, 1988, revised 2013
Forgiveness is developed through Norman's treatment of error, constraints and recovery rather than as a single named chapter.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Why this works
The reasoning this entry rests on.
- Loss AversionBIAS·002 · Cognitive bias
- Paradox of the Active UserPSY·007 · Psychology
Applied through
Where this shows up as a concrete interface decision.
- Activity TimelinesPAT·019 · Pattern
- CollaborationPAT·026 · Pattern
- ConfirmationPAT·008 · Pattern
- Destructive ActionsPAT·009 · Pattern
- Optimistic UIPAT·013 · Pattern
- UndoPAT·022 · Pattern
- Confirmation and Destructive CopyWRT·012 · UX writing
Practical example
A worked decision where this was the deciding factor.
- Designing an AI Suggestion Feature People Would UseCASE·010 · Case study
Related concept
Connected closely enough to change how you apply this.
- Error PreventionHEUR·005 · Heuristic
- Help Users Recognise, Diagnose and Recover From ErrorsHEUR·009 · Heuristic
- User Control and FreedomHEUR·003 · Heuristic
- Peak-End RuleLAW·007 · Law
- Postel's LawLAW·012 · Law