Say it before you do it

Interfaces that tell you what an action will do, then tell you what happened. Three small patterns you can try right here.

In 20 seconds

The two gaps every click has to cross.

Three patterns: preview it, confirm it in place, undo it.

Why \

dialogs stop working.

setFiles(start)} className="focus-ring -my-1 shrink-0 rounded-xs py-1 text-ink-2 underline underline-offset-3 hover:text-ink"> Reset

Are you sure?

This action cannot be undone.

Two gaps in every click

Don Norman, who basically wrote the book on this, describes two gaps between you and any machine. The first: how do I make it do what I want? The second: did it actually do it? He calls them the gulfs of execution and evaluation.

Most interfaces only half-cross them. The button says "Deploy" but not what will deploy, or where. Then something happens somewhere, and you check three places to be sure.

Before you click, the interface should tell you what will happen. After you click, it should tell you what did.

Before: say what it will do

Researchers call this feedforward: information that tells you what an action will do before you take it. Button labels are short on purpose, so they can't say everything. A hint can. Point at the button in both versions.

Bad: One word. Deploy what? To whom? How long?

Bad: You find out what it did by doing it.

Bad: The shortcut is a secret.

Good: Says the consequence: main, to everyone.

Good: Says the scale: 3 services, about 40 seconds.

Good: Shows the shortcut right where you are looking.

During: confirm where your finger already is

"Are you sure?" dialogs feel safe, but they stop working fast. Jef Raskin pointed out years ago that people get used to them and click OK on autopilot. So you get the interruption without the protection.

An inline confirm asks right on the button: press once and it changes to "Delete it?", press again to mean it, wait and it cancels.

Bad: A box jumps over everything you were looking at.

Bad: OK and Cancel make you read again to know which is which.

Bad: After the tenth time, nobody reads it.

Good: The question appears on the button you pressed.

Good: Press again to confirm, or just wait and it cancels.

Good: Nothing covers the list you are working on.

After: say what happened, offer a way back

Two of the classic usability rules are "show what's going on" and "let people undo". Gmail's Undo Send is the famous example: it doesn't ask if you're sure, it just gives you a few seconds to take it back.

Bad: \

Bad: Done what? Where did it go?

Bad: No way back if you clicked the wrong row.

Bad: The button just goes grey.

Good: Says what happened in plain words.

Good: Undo is right there, in the same spot.

Good: Mistakes cost one click, not a support ticket.

The kindest confirmation is an undo button.

How to do it in your app

For every important button, finish the sentence "This will..." and put that in a hint.

Replace confirm dialogs with an inline confirm for small things and undo for everything you can reverse.

After every action, say what happened in the place it happened, in words a person would use.

Keep modals for real decisions, the kind where people need to stop and think.

Sources

[1] The Design of Everyday Things (revised edition). Don Norman. Basic Books, 2013.

[2] Crossing the bridge over Norman's Gulf of Execution: revealing feedforward's true identity. Jo Vermeulen, Kris Luyten, Elise van den Hoven and Karin Coninx. ACM CHI, 2013.

[3] 10 Usability Heuristics for User Interface Design. Jakob Nielsen. Nielsen Norman Group, 1994, updated 2024. https://www.nngroup.com/articles/ten-usability-heuristics/

[4] The Humane Interface. Jef Raskin. Addison-Wesley, 2000.

Full component index: llms.txt