H3.06.3friction does not replace undodesign

Friction is not a substitute for recoverability

Aliases: friction versus undo · recoverability · cannot replace undo

What it is

Friction lowers the chance that an error occurs. It does not lower the cost once it has. Not a substitute for recoverability means: after isolation, delay, and typing are all done, if the act is still irreversible, one click-through or one mistaken judgment becomes the end state. Recoverability is another layer—undo, soft delete, compensation—and no thickness of friction buys that layer. This entry splits the two layers. It does not grade friction, and it does not specify undo windows.

Why it happens

Friction and recoverability act at different points on the timeline. Friction works before the act, assuming the person will look again; recoverability works after, assuming they already got it wrong. The first assumption often fails for skilled users; the second is where slips actually land. Thickening friction to cover “there is no undo” doubles the tax on the first layer and avoids engineering the second. Once click-through happens, thick and thin friction share the same end state. Only if the world can still be pulled back is a failure at the probability layer not a disaster.

Where it stops holding

Acts that are irreversible and uncompensatable (a key already leaked, a broadcast already sent) really have only friction and process approval left; when recoverability cannot be built, say so, and do not pretend a trash exists. Security responses sometimes must widen scope irreversibly; recoverability then becomes a tool for the attacker. Recoverability has windows and scope of its own, which does not change the layering: ask first whether it can be pulled back, then how thick the tax should be before the act.

Applying it

  • For every destructive act, fill in “how do we pull it back if this is wrong.” If there is no equivalent pull-back, then enter the friction menu, and state irreversibility on the surface.
  • Acts that already have trash or undo should drop the duplicate confirm and delay, to avoid double billing.
  • In incident reviews, split “friction did not catch it” from “it was caught but could not be pulled back.” The first changes intensity or tool; the second adds recoverability.
  • Verify by walking the friction to the end and submitting one wrong act on purpose. If the world cannot return to the pre-act state in the agreed time, the path has staked everything on the moment before the act—and needs recoverability, or irreversibility stated so clearly it cannot be missed.

Related

  • Within the group: H3.06.1 Destructive friction is isolation, delay, and typing · H3.06.2 Friction has to scale with harm
  • Adjacent: H3.04 Undo over confirm · H3.08 Soft delete and trash · H3.01 Prevention first
  • Search terms: recoverability · friction versus undo · error tolerance

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H3.06.3