---
title: What Gmail Figured Out
slug: exemplar-gmail
kind: exemplar
summary: That when an action is frequent and reversible, undo beats confirmation — and that changing an action's reversibility is better than adding friction to it.
problem: >-
  High-volume decisions get protected with confirmation dialogs, which are paid
  by everyone on every action to prevent a mistake a few people make
  occasionally. People then click through them without reading, so the
  protection is gone and only the cost remains.
family: [act, recover]
principles: [friction, orientation]
status: stable
visibility: public
related:
  - title: Confirmation vs Undo
    url: /patterns/confirmation-vs-undo
    summary: The decision this exemplar settles, and the table for making it yourself.
  - title: Review Queue
    url: /patterns/review-queue
    summary: The regime where this matters most — one decision repeated all day.
  - title: Empty State
    url: /patterns/empty-state
    summary: Inbox zero as a finished-queue state, and why emptying it feels like an achievement.
---

## The insight

**When you cannot make an action safe, make it reversible.** Sending an email
genuinely leaves your system — the classic argument for a confirmation dialog.
Gmail's answer was not a dialog. It was a short delay, which converts an
irreversible action into a reversible one and makes undo possible where it
should not have been.

That is a different kind of move from anything in an interface pattern library:
they changed the *property of the action* rather than the interface around it.

## What is worth stealing

**Undo, not confirm, for anything frequent.** Archiving is the highest-volume
action in the product and it never asks. It happens, and a toast offers undo.
Multiply a saved dialog by the number of archives per day and the design pays
for itself many times over.

**Undo send.** The single best example of reframing reversibility. Whenever you
are about to add a confirmation to something irreversible, ask first whether the
irreversibility is negotiable — a delay, a draft state, a soft delete. Usually
it is, and the answer is better than the dialog.

**The keyboard loop.** j, k, e, and the queue empties. One item, decide,
auto-advance. This is the [review queue](/patterns/review-queue) pattern at
scale, and it works precisely because the decision is trivial and the volume is
enormous.

**"You're all caught up."** Finishing is designed as success rather than as
absence. That is why emptying an inbox feels like an accomplishment, and it is a
free win almost every queue-shaped product leaves on the table.

## Where it does not transfer

Undo requires that you can genuinely restore the previous state. For actions
with external side effects that cannot be recalled — a payment taken, a
webhook consumed, a document filed with a regulator — a delay window is the only
version available, and sometimes not even that.

Consumer-scale ergonomics also assume high frequency. A rarely-used destructive
action gets no muscle memory, so a confirmation is cheap there and worth having.

## The extraction

> **Before adding friction to a dangerous action, ask whether you can make it
> less dangerous instead.**

A confirmation dialog is an admission that the action cannot be taken back. Trash
instead of delete, delay instead of send, draft instead of publish — each one
removes the need for the dialog rather than justifying it.