Doherty Threshold
Below roughly 400 milliseconds of system response, people stop waiting on the machine and productivity rises sharply.
Definition
Walter Doherty and Ahrvind Thadani's 1982 IBM study found that reducing computer response time below about 400 milliseconds produced a disproportionate increase in user productivity, because the interaction becomes conversational rather than turn-taking.
Established research. Originates in published research and has been replicated. The effect is real. Its size in your product still needs measuring.
On this page
Perception thresholds worth designing around
These come from Robert Miller's 1968 response-time work and Nielsen's later summaries. They are the practical bands most teams use.
| Duration | How it feels | What to do |
|---|---|---|
| Under 100 ms | Instantaneous, direct manipulation | Respond in the frame. No feedback needed beyond the state change. |
| 100 ms to 300 ms | Fast, still a direct response | Optimistic UI. Show the result and reconcile if it fails. |
| 300 ms to 1 s | Noticeable delay, flow is preserved | Show an inline state change. A spinner here often makes it feel slower. |
| 1 s to 10 s | Attention wanders | Show a skeleton matching the final layout, or a determinate progress indicator. |
| Over 10 s | Task is abandoned or backgrounded | Give a percentage, an estimate and a way to leave and come back. |
Perceived speed levers when you cannot make it faster
- Optimistic updates: apply the change locally, reconcile on the server response, and roll back visibly if it fails.
- Skeleton screens shaped like the real content, which read as loading progress rather than as a pause.
- Prefetch on hover or on intent, so the navigation has already started when the click lands.
- Stream partial results rather than waiting for a complete response.
- Fill the wait with something useful, such as letting the user continue filling the next field.
In practice
Search as you type
Site searchSuggestion lists that return under 200ms turn search into a conversation. The same feature at 800ms is worse than a plain submit button, because the user is now typing into a UI that keeps changing beneath them.
Optimistic like and save actions
Social and content productsThe icon fills instantly and the request runs in the background. The rare failure surfaces as a small revert with an explanation, which is a far better trade than making every success wait for the network.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
The economic value of rapid response time
W. J. Doherty and A. J. Thadani, IBM, 1982
Response time in man-computer conversational transactions
R. B. Miller, AFIPS Fall Joint Computer Conference, 1968
Source of the 0.1, 1 and 10 second perception bands.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Applied through
Where this shows up as a concrete interface decision.
- Progress IndicatorComponent
- Autocomplete and TypeaheadPattern
- Loading StatesPattern
- Optimistic UIPattern
Optimistic updates are how a network round trip stays under the threshold that keeps attention.
- Skeleton ScreensPattern
- MotionUI foundation
- Performance as User ExperienceUI foundation
- Loading and Progress CopyUX writing
Check your work
Review passes that test whether this was done properly.
- Dashboard UX ChecklistChecklist
Short definition
The one-paragraph version, for when that is all you need.
Related concept
Connected closely enough to change how you apply this.
- Visibility of System StatusHeuristic
- Parkinson's LawLaw
- FeedbackPrinciple