Snackbar

The old way to make an irreversible action safe was to ask once more before running it. Press delete, a dialog asks whether you really mean it, press confirm and it's gone. The logic is sound, and after the hundredth time the same question appears, pressing confirm becomes a hand movement rather than a decision.

Pagedeck had that dialog on document deletion, built as a modal — the layer that covers the screen behind it and blocks everything else until you answer. When Noa opened the records, 2 percent of the time someone pressed cancel. The other 98 percent pressed confirm. And complaints about documents deleted by mistake still arrived every week. The dialog wasn't preventing the mistakes, and it was spending the other 98 percent's time.

A snackbar reverses the order. Run the action, then offer the way back on the spot. Right after a document is deleted, a line saying so appears at the bottom of the screen with an undo button next to it. The 98 percent who made no mistake press nothing and move on; the 2 percent who did press once. Instead of charging everyone the cost of being blocked, only the people who were wrong take one extra step.

The action runs, a result line and an undo button appear along the bottom of the screen, and a few seconds later they disappear on their own. Five things get decided.

1. Position and count — bottom center or bottom left, and only one at a time. Successive actions either replace the previous notification or collapse into one line like "3 documents deleted." Two stacked on top of each other make it impossible to tell which button undoes what, and the wrong guess is itself destructive.
2. Wording — past tense, describing what already happened. Not "delete this?" but "Document deleted." Naming what disappeared saves the user from checking before deciding whether to undo. A generic line forces a trip back to the list.
3. The button — exactly one. Undo alone is the rule; add undo and view details together and the user hunts for which one is undo at the worst moment.
4. Duration — between 5 and 10 seconds. Reading it, deciding something went wrong, and moving a hand to press all take time. That's why it stays up longer than a notification with no button. Anything under 5 seconds turns the button into decoration.
5. When the deletion actually happens — two approaches. Hold the action while the snackbar is up and commit it when the snackbar disappears, or commit immediately and restore if undo is pressed. The first is simpler to build, but for those few seconds the document still exists on another device. The second keeps the state consistent everywhere at the cost of building a restore path.

One more item comes from accessibility, the work of making a product usable regardless of disability or circumstance. A notification that vanishes on its own leaves too little time for someone using a screen reader or anyone slow to move a pointer. So the timer pauses when focus enters it, and the undo button has to be reachable from the keyboard alone. A button nobody can reach in time is the same as no button.

It suits reversible destructive actions best: deleting a document, moving one to an archive, moving one between folders. It's especially useful after a bulk action. Delete twenty selected documents with no undo and the user has to go find all twenty again. The larger the action, the more the button earns its place.

It also works for reporting something the product did on its own. Attach undo to a line saying the sort order changed automatically or duplicate entries were merged, and a user who disagrees with that judgment has a route back.

Three situations call for something else.

1. Irreversible actions — an approved payment, an invitation email already on its way out. Anything that can't be recalled once it runs still needs the question asked first, and that's still a modal.
2. Notices you can't afford to miss — a message about an expired payment card must not vanish after a few seconds. That belongs in a banner, which sits at the top of the screen and stays there until someone deals with it.
3. Confirmations with nothing to undo — a line saying something saved has no target for an undo button, so a notification without one does the job.

"Let's drop the delete dialog and use a snackbar. Undo is all we need."

Offering the way back after the action instead of asking before it.

"The snackbar is set to 3 seconds. That's not long enough to press undo."

A notification with a button has to stay longer.

"This can't be undone, so a snackbar is wrong for it."

Don't use this element where undo can't be implemented.

Noa changed the deletion flow. The dialog came out, and after a delete a snackbar carrying the document's name and an undo button stayed up for 8 seconds. Theo built it as a held action rather than a delete-and-restore, hiding the document from the list during those 8 seconds.

Complaints about accidental deletion went from three a week to almost none. Undo was actually pressed 2.4 percent of the time — nearly the same rate as cancel in the old dialog. What changed is that the other 97 percent stopped having to dismiss a window.

The most common belief is that a snackbar can always replace a confirmation dialog. The reasoning is tidy: if it can be undone, there's no need to block. But undo only holds inside our own database. Once an invitation is in someone else's inbox or a charge has gone to the card network, there is nothing to undo. Leave the misreading in place and you ship a screen where pressing undo does nothing, and the trust lost there costs more than one dialog ever did.

The other common belief is that a generous duration means everyone sees it. Fifteen seconds sounds like nobody could miss it. But a notification that disappears never reaches someone looking at a different screen, however long it lasts, and the longer it stays the more it covers. A bar parked along the bottom hides the last row of a list. Content you can't afford to have missed doesn't get fixed by more seconds; it moves somewhere that doesn't disappear.