The controlled removal of data from a system, balancing user confidence with protection against accidental loss. Deletion exists in tension with creation and modification, requiring careful consideration of consequences, reversibility, and user intent.
Anatomy
- Trigger: The initiating action
- Confirmation: Verification of intent (varies by consequence severity)
- Execution: The actual deletion operation
- Feedback: Communication of result
- Recovery: Mechanism for reversal when available
Discarding without removing
The ladder below assumes the act is removal and asks how much ceremony it deserves. Often the actor wants something short of that — the thing out of the way, out of circulation, or harder to find, without it being gone.
- Demote — moved somewhere less prominent, still reachable
- Withdraw — taken out of circulation, retained for its owner
- Obscure — still present, deliberately harder to find
- Expire — removed on a schedule set in advance, not by an act
- Lock — marked so no discarding action can reach it
Confirmation
Which safeguard a deletion deserves is the action consequences framework applied to one action; the decision tree below walks it. The two lightest rungs are moves with pages of their own — undo riding on transient feedback, and inline confirmation — while the heavier rungs live here.
No confirmation, with/-out undo
For low-consequence actions that can be easily reversed.
Inline
Modal
Typed
For critical, irreversible actions, users must type a specific phrase to proceed.
Integration with save/cancel workflow
Deletion can be part of a broader editing session where changes are staged until explicitly saved. This approach treats the save button as the confirmation mechanism for all changes, including deletions.
Benefits
- Implicit confirmation: The save action confirms all changes, reducing confirmation fatigue
- Batch review: Users can see all pending changes before committing
- Safe experimentation: Users can try different configurations without immediate consequences
- Unified mental model: All changes follow the same commit pattern
This approach aligns with the Saving pattern’s hybrid model, providing a safety net while maintaining user control. It’s particularly effective for:
- Form-based interfaces with multiple fields
- Configuration screens with interconnected settings
- Bulk editing sessions
- Scenarios where deletions affect calculated values or totals
States
Deletion states
- Available: Delete action is accessible
- Confirming: Awaiting user confirmation
- Deleting: Operation in progress
- Deleted: Successfully removed
- Failed: Deletion unsuccessful
- Recovering: Undo in progress
Visual states
- Pending deletion: Marked for deletion but not yet committed
- Soft deleted: Logically deleted but recoverable
- Hard deleted: Permanently removed
Recovery mechanisms
- Undo
- Soft delete: Items moved to archive; configurable retention period
- Version history
Decision tree
Related components
- Action bar – Common surface for bulk deletion
Consequences
- a removal path matched to the severity, reversibility, and scope of the loss — confirmation, undo, soft delete, or typed challenge
- the data is gone; whether that holds is now a question of recovery — a completed deletion is exactly the state undo acts on
Resources & references
- Vitale, Odom & McGrenere (2019) Keeping and Discarding Personal Data: Exploring a Design Space, DIS ‘19 — the design space behind the discarding vocabulary above
- Ankenbauer & Brewer (2025) Time’s Sublimest Target: Practices of Forgetting in HCI and CSCW — six practices of forgetting
Appears in
Making changes
- Making changes safe, step 2 — Match the deletion safeguard to the risk rating
Memory and continuity
- Enforcing the limits on memory, step 1 — Decide what removal leaves behind
Related patterns
Precedes
- Undo — the data is gone; whether that holds is now a question of recovery — a completed deletion is exactly the state undo acts on
Related to
- Action consequences — Framework for evaluating appropriate confirmation methods
- Saving — Staged deletions within save/cancel workflows
- Status feedback — Communicating deletion results
- Activity log — Historical record of deletions
- Notification — Alerting about deletion events
- Inline confirmation — the action it most commonly guards; deletion's decision tree recommends it for items that take minutes, not seconds, to recreate
Enabled by
- Selection — How the scope of a deletion gets staked