Feedback must be timely; delay is attributed to nonresponse

What it is

Feedback latency is the wait between a person's action and a perceptible result. People attribute a change that closely follows action to their operation. When waiting lasts too long, even a system that is working is easily judged as an unregistered click, broken network, or frozen interface, prompting repeated submission, navigation away, or abandonment. Timely does not always mean instant completion; it means promptly communicating “received and processing.”

Why it happens

Temporal proximity between action and result helps establish causality. Short delay can be bridged by continuing state signals—a pressed state, local placeholder, progress, queue position, or expected wait. Without them, people can only infer from silence. Repeated action can then create concurrent requests, duplicate orders, or state conflicts, turning a performance issue into a comprehension and recovery problem.

Studying it

Measure input-to-first-acknowledgment, continuing state, and final result across representative devices, networks, and load, not final completion alone. Observe repeated clicks, undo, departure, help seeking, and perceived state at different waits. Compare forms of immediate acknowledgment and progress to see whether they reduce uncertainty; test long tasks, background work, and failed retries particularly carefully.

Where it stops holding

For extremely short, visible, reversible changes, extra animation can slow the rhythm. For long, unpredictable work, false progress or optimistic remaining time quickly harms trust; honest uncertainty is better. Performance optimization remains important: feedback is not decorative cover for perpetual waiting and does not replace reliable idempotency or error recovery.

Applying it

• Give visible acknowledgment immediately after receiving input, and communicate current processing state or when more information will become available during the wait.
• Prevent one consequential action from firing unintentionally more than once while letting people inspect, cancel, or safely retry it.
• Review latency using real networks and end-to-end timing; when fast completion is impossible, state scope of impact, work that can continue, and how the result will arrive.

Related

• Same group: B2.06.1 Every action needs perceptible information about its result · B2.06.3 Feedback intensity should match action importance · B2.06.4 Excessive feedback is actively ignored
• Nearby: B2.11 Error prevention · B2.07 Consistency
• Search terms: feedback latency · response time · perceived performance