Status feedback must appear within a reasonable time

What it is

A reasonable time is not one fixed millisecond budget for every action; feedback type must match perceptual expectation. A tap needs immediate pressed or selected confirmation, submission needs a short received cue, and the result may arrive later if its timing is stated. Late response feedback is interpreted as no response.

Why it happens

Users predict systems on the time scale of bodily action: pressing, scrolling, and dragging expect immediate visual change, while the psychological window after submission is shorter than the server’s processing time. If the system is silent before confirmation, repeated taps, exits, and reentry become likely; if only the final result appears without an acknowledgment, users cannot know the request entered the pipeline. Layered feedback resolves this: acknowledge the action first, then update the real result.

Studying it

Record time from input event to first visual feedback, state change, and final result, then align those times with interruption, repeated clicks, escape scrolling, and error reports. Experiments can vary acknowledgment delay and final wait while measuring duplicate operations, subjective wait, trust, and completion. Networked products should analyze P50 and P95 separately, not averages alone.

Where it stops holding

Premature optimistic feedback misleads; showing “saved” when saving fails is worse than silence. Animation also has limits, and long transitions slow frequent operations. Accessibility and poor-network contexts may need different budgets; for screen readers, feedback order and reachability matter more than visual shimmer.

Applying it

• Set feedback budgets for each input type, with separate targets for immediate acknowledgment, state update, and final result.
• After submission, show “sent/processing” before claiming success based on server completion.
• When the budget is exceeded, switch to a cancellable waiting state and state the expected time or next step.
• Test P95 paths on real networks and assistive technology, recording the gap between first acknowledgment and final result.

Related

• Same group: B3.01.1 Users should always know what the system is doing · B3.01.3 Long tasks need progress rather than only a busy indicator · B3.01.4 The test is whether users can always answer what the system is doing and where they are · B3.01.5 After waiting long enough, feedback must upgrade from a momentary cue to a persistent status presentation · B3.01.6 Background tasks also need visibility; leaving the current screen does not make the task disappear · B3.01.7 Status should express progress and remaining work, not merely that the system is busy
• Nearby: B2.06 Feedback · I1 State, Time, and Response
• Search terms: response time · optimistic UI · perceived latency