31 · Doing
Doherty Threshold
People and computers work best together when the computer answers in under a second, and the faster the better. The number that stuck is 400 milliseconds.
Evidence: Holds, with limitsWhat we do with it
- 01
Acknowledge every tap at once, even when the work takes longer. A button that changes the moment it's pressed stops double orders.
- 02
Test speed on a mid-range phone on an ordinary connection. A laptop on office Wi-Fi is the best case, not the typical one.
- 03
Ryan Buell and Michael Norton found in 2011 that people sometimes value a result more when they can see the work behind a wait. We don't pad waits. If something takes time, the screen says what it's actually doing.
Examples
Getting it wrong, getting it right.
Don't
A button that does nothing visible for two seconds, so people click it again and send the order twice.
Do
The button changes on the first tap and disables itself, then the result loads.
The evidence
What the research says.
The 1982 paper drew on productivity data from IBM's own systems more than on a controlled experiment, and it never names 400 milliseconds. It argues for response times under a second, and its own data points are 3, 2, 1, 0.6 and 0.3 seconds: programmers completed 180 transactions an hour at 3 seconds and 371 at 0.3. The 400 figure is the one that stuck. Later work agrees that faster is better and that the wait itself can be shaped. In 2007 Chris Harrison and colleagues found people judged identical 5.5-second waits differently depending on how the progress bar moved. In 2009 Google slowed its results page by 100 to 400 milliseconds for some users, and they searched 0.2% to 0.6% less. The users who got the slowest pages kept searching less for weeks after the delay was removed. Fiona Nah found in 2004 that people would wait about 2 seconds for a web page before giving up, and longer when the page showed it was loading.
How our view changed
We aim for under a second and acknowledge every tap at once. We don't treat 400 milliseconds as a cliff.
Sources
- Doherty, W. J., & Thadani, A. J. (1982). The economic value of rapid response time. IBM, November 1982.
- Brutlag, J. (2009). Speed matters for Google web search. Google, June 2009.
- Miller, R. B. (1968). Response time in man-computer conversational transactions. AFIPS Fall Joint Computer Conference.
- Harrison, C., Amento, B., Kuznetsov, S., & Bell, R. (2007). Rethinking the progress bar. UIST '07.
- Nah, F. F.-H. (2004). A study on tolerable waiting time: How long are Web users willing to wait? Behaviour & Information Technology, 23(3).
- Galletta, D. F., Henry, R., McCoy, S., & Polak, P. (2004). Web site delays: How tolerant are users? Journal of the Association for Information Systems, 5(1).
Last reviewed November 7, 2026. How we keep this current