Design Deletion and Recovery Flows That Respect Users
Feedback & States · undo, destructive actions
Updated 2026-07-28
- Avoid forcing every user through confirmation dialogs. A message like “Deleted. You have five seconds. Are you sure?” makes every user pay the cost of preventing a mistake made by a few. Prefer recovery patterns that protect users without interrupting everyone.
- Use undo whenever possible. Let the action happen immediately, then give users a short window to reverse it. The goal is to remove fear while keeping the workflow fast.
- Treat deletion as a state change, not a single event. Instead of permanently removing data instantly:
- Move items to a trash or recovery state.
- Mark them as deleted.
- Keep them recoverable for a defined period.
- Permanently remove them only after the recovery window expires.
- Add friction only when an action is truly irreversible. For high-risk actions, require users to intentionally confirm their choice. Make them prove they understand the consequence, such as typing the name of the item or project they are about to delete.
- Build undo systems that scale beyond a single action. A toast with an Undo button handles simple recovery, while a history stack allows users to move backward through multiple actions in sequence.
- Consider keeping a complete action history where appropriate. Tools that remember changes allow users to explore, recover, and reverse previous work instead of fearing mistakes.
- Use intentional delays for risky communication. A short send delay gives users a chance to catch mistakes like typos, incorrect recipients, or accidental replies before the action becomes permanent.
- Design destructive actions around confidence, not caution alone. The best systems allow users to move quickly while providing a safety net when something goes wrong.
Related guides