Beyond that threshold, action and result are perceived as two events

What it is

Press, then a beat of stillness, then the text appears — people no longer say “I changed it”. They say “I sent a request, then the system answered”. Once feedback leaves the instantaneous window, action and consequence split into two events. That split is action-result decoupling: the same causal pair, recoded from “something I did” into “something I waited for”, solely because the interval opened.

Decoupling is not a failure. It is a change of perceptual mode. Once it happens, people start needing a different class of information: did the system take it, is it still working. That is no longer a question of instantaneity.

Why it happens

Temporal binding has a cutoff. Past it, the visual transient is no longer merged into the motor event, and working memory holds two slots: one occupied by “I pressed”, one empty for “it changed”. The empty slot triggers monitoring — gaze parked on the object, or a sweep for any change. Monitoring costs attention and also changes tolerance for later delay: the person has entered a dialogue, not a manipulation.

The experience is asymmetric. A few tens of milliseconds late, most people cannot name what is wrong, only that it feels dull. Later still, they clearly feel an extra layer. Once that layer is felt, a prettier completion animation cannot restore the unity of “I did it”; it can only explain the second event.

Studying it

Hold the control fixed and walk feedback delay from inside the window to outside it; mark when people switch from “I caused that” to “the system responded”. A forced choice helps: “was this a direct act, or a request-and-reply?” Gaze often leaves the object briefly after decoupling, hunting a status light or the button itself.

Independent variables: whether delay crosses the instantaneous window, whether a pressed state appears immediately, whether arrival of the result has its own motion. Dependent variables: two-event report rate, time from press to status-seeking, ratings of dull / stuck / normal.

Do not substitute a satisfaction score for a decoupling judgement. People can be satisfied with a slow, clear submit and still accurately report “that was two times”.

Where it stops holding

Flows already modelled as request-and-reply — search, checkout, generation — treat decoupling as the default; there is no need to fake direct causation. In games and instruments, decoupling reads as broken feel, with far less tolerance than a form. Screen-reader users do not use the visual window; decoupling sits between gesture end and speech of the change, and the threshold is when speech starts. An arrival animation that itself starts late simply lengthens the decoupling.

Applying it

• Once an action cannot finish inside the instantaneous window, design it as two events: “accepted”, then “result arrived”. Do not keep pretending it is a flick.
• The acceptance signal must precede the result: button into a working state, row selected at once, field blurring at once, so the first event has somewhere to land.
• When the result arrives, give it its own arrival cue (a row inserting, a validation message appearing). Do not silently swap content and leave people thinking they misread.
• How to check: stretch completion to 400–800 ms and ask someone outside the team “did you just change it, or send a request?” If the latter, the UI owes two pieces of feedback, not a switch costume.

Related

• Same group: I1.01.1 Feedback inside a very short delay is perceived as direct causation · I1.01.3 Direct manipulation depends on that threshold holding
• Nearby: I1.02 Continuity-of-thought threshold · I2.07 Perceived performance
• Search terms: action-result decoupling · request-response perception · delayed consequence