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
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
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
- 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