A familiar sequence hijacks the current intention

What it is

A capture error is a specific type of slip: the action sequence a user meant to carry out gets taken over midway by another, more familiar and more frequently performed sequence, and the user ends up completing the habitual path instead of the one they actually intended right now. The two sequences share identical opening steps; at the point where they should diverge, the more familiar one wins, and the user's hands follow it instead of the intended branch.

Why it happens

It's called "capture" because control switches over abruptly: at the exact point where the shared path ends and a branch should be chosen, that choice is supposed to be driven by the current intention — but if no dedicated attentional check confirms which branch is actually being taken at that moment, the path with more practice and a lower activation threshold fires automatically and crowds out the one that was meant to run. This doesn't require the user to have "thought wrong" — they knew the whole time what they meant to do; the action-level choice at the branch point was simply won by the stronger habit, and by the time it's noticed, the outcome already belongs to the other path.

Studying it

Capture errors are identified by checking whether the outcome of a failed action exactly matches the full result of the other, higher-frequency sequence that shares its prefix — if the erroneous outcome precisely corresponds to what that other frequent action would produce, rather than looking like random deviation, it's capture rather than a generic slip. This match can be found by batch-analyzing operation logs; individual interviews aren't necessary, because the action sequence itself already reveals which branch it went down.

Where it stops holding

Capture only occurs when two sequences share a prefix and one of them is clearly more frequent — if the two sequences never had a common path to begin with, there's no branch to be hijacked at, and it isn't capture, at most some other error type. If the two sequences run at similar frequencies, there's also no stable tendency to "always drift toward that one" — capture needs a clear frequency imbalance to produce a predictable direction of failure.

Applying it

Audit which operation sequences in an interface share their opening steps while one of them runs far more often than the other — these branch points are where capture concentrates. Put the distinguishing treatment right at the branch point itself (a visibly different response, a confirmation specific to that branch), targeting the exact moment where everything up to now looked identical, rather than adding a generic reminder somewhere earlier in the flow. Verification: pull the failure logs for a low-frequency action and check whether the erroneous outcome consistently matches what the high-frequency action sharing its prefix would produce. If it does, this is capture, and the fix belongs at the branch point of the shared path — adding hints elsewhere won't help.

Related

• Same group: A10.05.2 A longer shared prefix and a bigger frequency gap amplify capture · A10.05.3 Old habits carrying over after a redesign · A10.05.4 Post-change transition protection instead of a one-shot cutover
• Nearby: A6.09 Procedural memory and automatization · A11.04 Novice–expert behavioral differences
• Search terms: capture error · capture slip · shared action prefix