Do not place destructive actions on an accidental-activation path

What it is

A destructive button can still be hit by a slip even when it does not look like a primary. An accidental-activation path is the trajectory a finger, pointer, or keyboard focus follows while completing an ordinary action: beside the primary, at the end of a list swipe, at the landing of a back gesture, in the next Tab stop after a dialog’s default. Destructive actions should not sit on those trajectories. Bad placement produces a slip: the intent was save or back; the movement landed on delete.

Why it happens

Pointing has spatial noise. Fitts’s law says smaller, closer targets have more endpoint scatter; two small neighbors will absorb some endpoints meant for Save. Touch also has a contact patch whose lift-off tends to land low and inward, so a Delete under or inside the primary eats the release. Keyboard users walk controls linearly; if a destructive action sits just before Next, Enter or one extra Tab activates it. Swipe-to-delete parks destruction at the gesture’s natural end, mining the extension of every browse swipe. Path is independent of look: a green key labeled Delete will still be slid onto if it sits against Send.

Studying it

Record landing distributions in a pointing task. Vary spacing and size of the main versus destructive target; count landings on the wrong one. On touch, log contact centroid relative to the visual center. On keyboard, count Tabs from Next to Delete and Enter misactivations.

Independent variables: spacing, relative placement (left/right/above/below), shared gesture path, input channel. Dependent variables: slip rate, direction of lift-off bias, immediate corrections of the form “I didn’t mean to delete.”

Isolated squares in the lab scatter more optimistically than icon buttons in a real list row. Measure with real row height and real thumb posture to see swipe-to-delete and paired sticky-bar keys as they actually fail.

Where it stops holding

On a large desktop with ample spacing and a precise pointer, a destructive control at the edge is safer than on a phone. A laptop trackpad click in motion still slips. Safety-critical systems sometimes put danger behind a change of grip; that lengthens the path on purpose and does not contradict “keep it off the way-by.” A trash can or undo lowers consequence without lowering slip rate; the path problem remains, the accident becomes recoverable. Remote desktop and eye tracking are noisier still and need wider isolation than everyday UI.

Applying it

• Do not park Delete against Save, Send, or Back; leave a gap larger than the contact scatter, or move it into an overflow menu.
• Do not let swipe-to-delete share an end direction with back or tab-bar gestures.
• In keyboard order, do not insert a destructive action in the stop before default submit; Enter must land on a non-destructive action.
• Verify with a hundred fast taps on the primary on-device and see whether the contact heatmap invades Delete; then have people “save and leave” without being told a delete key exists. One “I didn’t mean to delete” means the paths overlap.

Related

• Within the group: E1.03.1 Destructive actions need a visual signature distinct from ordinary actions · E1.03.3 Color cannot be the only danger cue
• Adjacent: B1.01 Fitts’s law · C2.09 Accidental touch and palm rejection · E1.07 Button hit targets · J3.13 Guarding against accidental activation
• Search terms: accidental activation · slip · Fitts's law