Doherty Threshold: The Pace That Keeps Focus
The Doherty threshold suggests responding within 400 ms so nobody waits on the system. What the IBM study says, what Kent Beck criticizes, and how to apply it.
What does the guideline say?
Laws of UX puts it this way: productivity soars when a computer and its users interact at a pace that ensures neither has to wait on the other. It recommends providing system feedback within 400 ms (Laws of UX: Doherty Threshold). The practical idea is that an immediate response keeps the person inside the thread of what they were doing.
It does not say everything must finish in 400 ms. It says the first response, the signal that something happened, must arrive quickly. That distinction matters more than it seems.
Where does it come from?
The guideline is attributed to a 1982 paper by Walter J. Doherty and Ahrvind J. Thadani, from IBM. According to Laws of UX, that paper proposed that computer response time should be 400 ms, replacing the two-second standard that had been the norm. Kent Beck, who wrote about the figure, confirms the context: the IBM research challenged the belief that two seconds was acceptable (Kent Beck: The Precious Eyeblink).
Network World summarizes the same work, titled “The Economic Value of Rapid Response Time” and credited to Arvind Thadhani, with a broader idea: productivity improved non-linearly when response time fell below one second (Network World). None of the cited sources details the study’s method, so 400 ms works better as a design target than as an exact experimental result.
What does Kent Beck criticize?
Beck accepts that the IBM research was real and that productivity improves when responses are fast. But he raises two points. First, no research says attention starts to slip at exactly 400 ms. Second, the threshold is “practically motivated,” meaning a useful boundary for design rather than a constant of the human brain. He describes the boundary as fuzzy (“give or take”) and calls the figure “a specification to design around.”
That critique is useful for a designer: the number works as a design target, not as an argument to stop measuring. If your screen responds in 380 ms but the result takes four seconds, the person is still waiting.
How does it relate to the other limits?
Jakob Nielsen proposes three response-time limits, which UX Tigers summarizes as follows: 0.1 seconds (100 ms) creates the illusion of an instantaneous response; a subsecond response lets people keep a seamless flow of thought; and 10 seconds is the maximum delay before the person’s attention drifts (UX Tigers: Time scales of UX). Beck places the Doherty threshold inside this framework: 400 ms sits between the first limit and the second.
In practice, treat these figures as design guidelines, not exact cutoffs: each one describes a band of perception, not a switch that flips at one precise millisecond.
What should you do when the response is slow?
The useful principle is to respond immediately even when the result takes longer. Laws of UX notes that progress bars help even when they are not perfectly accurate. In practice, that means:
- Change the button state at the exact moment of the click: disable it, show a spinner, or change the label to “Saving”.
- Show something useful while the result arrives, such as a skeleton of the list. See skeleton vs. optimistic UI to choose the pattern.
- Use action feedback, such as a visual change or a haptic pulse, before the server response arrives.
- Show a clear message when the wait exceeds several seconds, with a way out if possible.
What does not help is a beautiful animation that takes longer than the real work. That turns the wait into a decorative pause.
Illustrative example
Illustrative example: a notes app takes 900 ms to save each change and shows nothing during that time. People click “Save” again, and sometimes the note is duplicated. The team changes the button to “Saving…” at the exact moment of the click and shows a discreet mark when it finishes. The real time did not change, but the first response arrives in under 100 ms. Duplicates drop because people know something is happening.
If you want to go deeper into the relationship between waiting and feedback, read feedback and feedforward, and review perceived performance design, which treats waiting as a design problem, not only an engineering one. And if the system is slow for a reason the person cannot understand, look at status awareness.
Common mistakes
- Believing the threshold is an exact scientific law.
- Optimizing only server time and forgetting immediate feedback.
- Showing an indefinite spinner without explaining what happens when the wait gets longer.
- Adding long animations to a response that was already fast.
- Measuring performance on a powerful laptop instead of a mid-range phone with a weak connection.
What you can do tomorrow
- List the five most frequent actions in your product and note how long the first visible response takes for each.
- For the ones above 400 ms, define a loading state or a button change that appears at the moment of the click.
- Ask engineering for the real time on a mid-range phone, not only on a laptop.