F1.07.2isolation versus confirmationdesignresearch

Spatial isolation outperforms confirmation dialogs

Aliases: habituation · confirm-dialog fatigue · spatial isolation

What it is

A “Delete — are you sure?” confirm, after a few weeks, is tapped through with the primary — the dialog becomes the next beat of the motor program, and the sentence is no longer read. Take Delete off Send’s side and put it behind an overflow, or behind a drag to the trash, and the hand cannot fuse the two taps into one phrase. Spatial isolation outperforms confirmation because isolation changes the trajectory. Confirmation adds a beat on the same trajectory, and that extra beat is eaten by habituation.

Confirmations are not useless. They do not stop the already-automatic tap. They are better at catching a decision error: the intention really was delete, but the object was the wrong one.

Why it happens

Habituation drains information from a repeated modal: visually it is still there; as a decision it is already “tap once more”. A Fitts-style trajectory that has been lengthened through a distant entry cannot be merged into the frequent action’s program — the program has no such path. Isolation turns a miss from “the landing tail swept the neighbour” into “a conscious navigation has to be started”, and the two errors have different base rates, the latter much lower.

Drag-to-trash, typing the object’s name, parking the action in a layer that appears only after a menu opens, all lengthen the trajectory. The cost is real, so they can only be spent on a few destructive actions. Lengthening every action makes the product unusable.

Studying it

Compare three defences: adjacent plus a confirm, isolated with no confirm, isolated plus a confirm. People repeat the frequent action under time pressure, with an occasional trial of “this time you really should delete”.

Independent variables: defence type, how many weeks the confirm has been appearing (habituation time), isolation distance or number of intervening steps. Dependent variables: unwanted deletes, extra time when a delete is intended, whether the confirm is still read after it opens (eye tracking, or asking what it said).

If unwanted deletes in the adjacent-plus-confirm group climb back toward the undefended rate after a few days, while the isolated group stays low, habituation has been measured.

Where it stops holding

The wrong object (the other email) is not an adjacency problem; isolation does not help, and preview, undo, or typing the name does. Fast, complete undo (“undo send” in mail) can lighten both confirm and isolation, but isolation should stay — undo has a window, and the window closes. When law or security mandates a confirm, still confirm, but do not take that as a licence to put the destructive button back beside the frequent one. Children or users with cognitive disabilities may not complete “open overflow, then find delete”; give a supervised path rather than dismantling isolation for everyone.

Applying it

  • Take the destructive action off the frequent trajectory first, then decide whether a confirm is still needed. A confirm is not a permit to sit adjacent.
  • Do not place the confirm’s primary at the same screen coordinates as the original frequent button, or a double-tap will automate the confirm too.
  • Deletions that can be undone can be weakly isolated (overflow). Transfers and unlinks that cannot be undone take strong isolation (a separate page, typing the object’s name).
  • How to check: people who have used the product for two weeks or more, a hurried script of consecutive sends with one delete slipped in. If the delete still happens without the confirm sentence being read, the defence is still sitting on the dialog, not on isolation.

Related

  • Same group: F1.07.1 Destructive actions must not sit next to frequent ones · F1.07.3 Isolation has to hold at every breakpoint
  • Nearby: E1.03 Destructive action buttons · D1.15 Feedback intensity matched to consequence
  • Search terms: habituation · confirmation dialog · spatial isolation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/F1.07.2