Past that point, wait feedback is required

What it is

Once a step crosses about one second without a result, the interface can no longer pretend it is still the same beat. People have started to doubt whether the action was taken at all. Wait feedback is then obligatory: the system heard you, it is still working, park your thought here. The duty to signal starts at this second, not at ten. Ten seconds is when people leave their seat; one second is when they start to think the UI is dead.

This leaf only decides whether to signal. Spinner, skeleton, or a line of “Opening…” is a later choice.

Why it happens

The moment continuity breaks, the empty working-memory slot takes “broken” as the default explanation — because the last beat produced no new input. Wait feedback’s job is to rewrite that default to “still in flight”. What it offers is not progress. It is proof of life. The proof has to arrive before doubt sets. Once doubt lands, people retry, go back, or judge the window unresponsive; a later indicator reads as an excuse.

Inside the instantaneous window, “no change” can still be coded into the act. Past the continuity threshold, “no change” is coded only as failure. The cost of silence therefore jumps after 1 s; it does not worsen linearly with time.

Studying it

Compare complete silence against “any wait signal once 1 s is crossed”, at delays of 0.5, 1, 2 and 3 s. Watch retries, back-navigation, and spoken reports of “is it stuck”.

Independent variables: whether a wait signal appears at the 1 s crossing, whether it occupies the original control, total delay. Dependent variables: premature retry count, abandonment, rate of labelling the delay as a fault.

Lab instructions to “wait for the result” suppress retries. Use a naturalistic prompt: “finish the step; if it seems unresponsive, do what you would normally do”.

Where it stops holding

Local operations that will finish inside 1 s should not be force-fitted with wait feedback; that itself is a pointless mode switch. If motion is already happening (a page pushing in, a list expanding), the motion is the wait feedback — do not stack a spinner on it. Silent background sync is not on the user’s current chain and does not trigger this duty; nobody parked a thought on that sync. A full-screen blocking spinner turns “give feedback” into “steal the context”: continuity is not preserved, and the goal cue is covered.

Applying it

• Any user-initiated request expected to finish mid-chain that is still open after about 1 s must show an in-progress state on the original control. Do not wait for the user to start double-tapping.
• Put the signal where the person is looking: the button in a loading state, a working mark on the row being opened — not a spinner in a distant corner.
• Requests that finish inside 1 s must not flash an indicator; the indicator itself needs an appearance threshold so feedback does not become a new interruption.
• How to check: pin the API at 1.2 s. The silent version should produce retries and back-taps; the signalled version should keep the same people waiting rather than retrying. Run both. Do not only test the signalled path.

Related

• Same group: I1.02.1 Within a one-second delay, the user's train of thought stays intact · I1.02.3 This interval needs status confirmation, not a progress bar
• Nearby: I1.03 Attention-holding ceiling · I2.01 Choosing skeleton versus spinner
• Search terms: wait feedback · delay acknowledgement · 1 second rule