Undo

Somebody filters a list of orders, selects everything, and archives it. The filter was not what they thought it was, and 12,000 records are now out of the way.

Undo beats an "Are you sure?" box. Hear why on your walk, add it to your product this week.

Listen to the full Undo course on DesignPath
Share
Share

Nothing about that sequence was a mistake in the product's terms. Every click did what it said. The person was wrong about one thing for about four seconds, and there was no way to say so afterwards.

Jakob Nielsen's third heuristic asks for exactly this: people choose functions by mistake and need a clearly marked emergency exit, so support undo. Most products answer it with a confirmation dialog instead, which is a different thing. A dialog asks somebody to be certain in advance. Undo lets them be wrong briefly and fix it, which is closer to how people actually work.

The distinction runs through the whole module. Almost every "Are you sure?" in a product is there because nobody built the thing that would have made it unnecessary.

Anatomy of an Undo

Undo is not one mechanism. It is three, and choosing between them is a question about time rather than about technology.

The Five Parts

Every version has the same pieces.

The action somebody took. The window, meaning how long it stays reversible. The affordance, which is the visible way to reverse it. The restore, which puts things back and has to put back everything the action touched. And the permanent point, after which the window has closed and the thing is gone.

The permanent point is the part nobody specifies, and it is the one people ask support about.

Three Shapes

Each covers a different length of time.

Immediate undo is a control that appears with the confirmation and lasts seconds, usually in a toast. Soft delete moves the thing somewhere recoverable, a trash or an archive, and lasts days or weeks. Version history keeps successive states of a document so any of them can be returned to, and lasts as long as the product keeps them.

They are not alternatives so much as a ladder, and a product that only has the first one has covered mistakes noticed within a few seconds.

Choosing by How Long Noticing Takes

The question that picks the shape is how long somebody might take to realize.

Deleting the wrong row from a visible list is noticed at once, so a toast is enough. Deleting a file inside a folder they then close is noticed next week, which is what a trash is for. Overwriting a paragraph in a document is noticed when somebody reads it again, which is version history. Match the window to the noticing rather than to what is convenient to build.

What Restore Has to Put Back

An undo that returns some of the state is worse than none, because it looks like it worked.

Restoring a deleted item means its position in the list, its relationships to other things, and anything that was cascaded when it went. Data Tables & Filtering covers the bulk case, where an action across thousands of rows rarely lands uniformly and the undo has to know which ones actually changed.

Pro tip: Write down the permanent point for the three most destructive actions in your product. If nobody on the team knows the answer, neither does the person asking support to get their data back.

Found this useful? Pass it on.
Share