Changing the target inside that window guarantees a mis-hit

What it is

A user has already launched a click or tap toward a location, and right before the finger lands, whatever was at that location gets replaced, moved, or removed. The finger will almost always still land at the original location, hitting whatever has just been swapped in rather than what the user meant to select. This isn't the user "not looking carefully" or a slip — once a movement crosses its launch threshold, the landing point is already fixed by parameters set earlier, and changing the target after that point gives the movement nothing to re-aim toward.

Why it happens

A pointing movement's landing point is programmed in advance based on where the target was when the movement was set up; once the non-cancelable window has closed, that parameter set no longer accepts revision. If the target shifts position in the brief interval before the window closes, the visual system genuinely can detect the change, but detecting a change and re-encoding it into the parameters of an already-executing movement are two different things — the latter requires running the full sense-compare-generate-new-command-conduct-to-muscle chain, and if not enough time remains for that chain to finish, the movement lands with the old parameters regardless. The later the target moves, the less time is left for re-programming, and the closer the probability of landing at the old location gets to certain.

Studying it

The classic way to study this makes a target jump to a new location at some point after a movement has been launched, systematically varying how long after movement onset the jump occurs, and observing whether the finger or cursor ends up following the new location or staying near the old one. When the jump happens early enough, participants smoothly re-aim at the new location; when it happens late enough, the landing point stays near the old location almost every time. Between the two lies a transition delay — the practical upper limit on how much time that movement actually has available for re-programming.

Where it stops holding

This transition delay varies with movement speed and with the distance and direction of the jump, so there's no single number that applies across every interaction style — faster, briefer movements leave a narrower window for re-programming. Lab-controlled target jumps are also a single, precisely timed displacement, whereas the displacements that cause mis-hits in real interfaces come from many different sources — a list reordering as new data arrives, a position shift mid-transition animation, a new element popping in once loading finishes — and the timing of these shifts is often outside the designer's precise control, making it hard to schedule a "safe" moment for displacement the way a lab study can.

Applying it

• Any content displacement that might occur in the brief interval after a user has already launched a click but before the finger lands — a list reordering as new data arrives, a button shifting due to a state change, a new element popping in once loading finishes — should be kept out of that short window right after the finger leaves rest; this can be done technically by freezing the layout of the region about to be tapped, or by delaying the shift until after the finger lifts.
• For weighty operations like delete or send, don't place their trigger control somewhere prone to being swapped out by an unrelated page refresh — if the content at that spot changes for reasons unrelated to the user's intent, a finger aimed at a safe action can land precisely on the dangerous one that just took its place.
• How to check: replay a screen recording of the two or three frames around each click, specifically checking whether the target control's position or content changed in the brief window right before the finger landed. Any case where such a change lands right next to a mis-tap confirms this mechanism is at work, and points to separating refresh timing from click timing.

Related

• Same group: A8.05.1 An action is programmed in full before it is launched · A8.05.2 Movement complexity increases the preparation time needed to program it · A8.05.3 A launched action has a non-cancelable window · A8.05.4 Cancelling an already-programmed action itself takes time and carries a cost
• Nearby: A8.08 Two-Phase Structure of Target Acquisition · A10.03 Omission Errors and Commission Errors
• Search terms: double-step target paradigm · target displacement · motor programming