Doherty Threshold
Fast feedback helps people keep their train of thought while they work with a system.
The useful threshold is the moment a delay starts interrupting the task.
You press Save and the button changes immediately to Saving. The server still needs time, but the interface has closed the loop. The wait becomes understandable because the system has confirmed the action and named the current state.
Origin
Doherty and Thadani's 1982 IBM paper linked faster terminal response with higher productivity. Its 400 millisecond target is a historical benchmark, not a universal cutoff for every task or device.
Acknowledge input immediately, even when the operation cannot finish immediately. A pressed state or status label can confirm that the action was received.
Separate response time from completion time. The interface can react quickly while clearly showing that saving, processing, or uploading is still underway.
Use optimistic updates only when failure is uncommon and easy to reverse. Never show a critical action as complete before the result is known.
Measure the whole interaction in context. A fast animation cannot compensate for a slow search, delayed data, or a workflow that repeatedly breaks attention.
Digital systems
An honest save state
The button responds on press, changes to Saving during the request, then confirms Saved or explains the error. Each state arrives when it is true.
Physical signals
An elevator call light
The button lights as soon as it is pressed. The lift may still be far away, but the immediate signal confirms that the request entered the system.
A delay arrives without acknowledgment or progress, so people repeat the action, lose context, or start wondering whether the system failed.
React to input quickly, show the true state of longer work, and give people a way to cancel, retry, or continue when the operation takes time.