Productivity soars when a computer and its users interact at a pace of under about 400 milliseconds, so that neither has to wait on the other.
Overview
Speed is a feature. When a system responds almost instantly, people stay engaged, keep their train of thought, and work faster. When it pauses, even briefly, attention drifts and the rhythm of work breaks.[1]
In 1982, IBM researchers Walter Doherty and Ahrvind Thadani challenged the then-common assumption that a response time of up to two seconds was acceptable. They reported that as response times dropped below one second, productivity rose sharply, costs fell, and people got more satisfaction from their work.[2] The threshold is commonly stated today as about 400 milliseconds (four-tenths of a second).[1]
Not every operation can be that fast. When real speed is not possible, perceived speed matters: showing immediate acknowledgement, displaying content progressively, and keeping people informed makes waits feel shorter.[3][4]
Why it matters
Response time multiplies across every interaction, every user, every day. A one-second delay on a screen used hundreds of times a day by thousands of people adds up to substantial lost time, and to frustration that shapes how people feel about the whole system.
Performance is also a design decision, not only an engineering one. Choices about how much data to load, how many steps a task requires, and how feedback is shown all affect how fast an experience feels.
Key takeaways
- Aim for responses that feel immediate. Under about 0.1 seconds feels instantaneous; staying well under a second keeps people in rhythm.[1][3]
- Acknowledge input instantly, even if the full result takes longer: a pressed state, a spinner, or an optimistic update.
- Show progress for longer waits. Skeleton screens and progress indicators make waiting feel shorter and more predictable.[4][5]
- Load what matters first. Display the most important content quickly and fill in secondary content afterwards.
- Measure real-world responsiveness. Modern web metrics such as Interaction to Next Paint (INP) consider 200 milliseconds or less to be good.[6]
- Do not add artificial delays without purpose. A brief, deliberate pause is occasionally useful to signal that something important happened, but should be the exception.
In practice
Common patterns in business applications, portals, and internal tools:
Supports the principle | Undermines the principle |
|---|---|
Buttons respond visually the moment they are pressed. | No visible change until the server responds seconds later. |
Skeleton screens show the page structure while data loads. | A blank page followed by everything appearing at once. |
Search results update as people type, with fast responses. | Every filter change reloads the entire page. |
Long operations run in the background with a notification on completion. | People must wait on a frozen screen for a batch process. |
Performance budgets are set and tracked for key workflows. | Performance considered only after users complain. |
Questions to ask in a design review
- How long do the most frequent actions on this screen take to respond?
- What do people see in the first fraction of a second after they act?
- Where are people waiting, and could that work happen in the background?
- Are we measuring responsiveness under real-world conditions and data volumes?
Origin
The threshold comes from Walter J. Doherty and Ahrvind J. Thadani‘s 1982 IBM paper The Economic Value of Rapid Response Time, which presented case studies showing that sub-second response times significantly increased productivity in interactive computing, in one project raising programmer output by more than half.[2]
It built on earlier research into response times, notably Robert Miller’s 1968 study of conversational computing, and was later echoed in Jakob Nielsen’s widely cited response-time limits of 0.1, 1, and 10 seconds.[1][3]
Related concepts
- Feedback — immediate acknowledgement of every action
- Flow — fast responses keep people focused
- Goal-Gradient Effect — visible progress keeps people motivated
- Zeigarnik Effect — unfinished operations stay on people’s minds
- Selective Attention — delays allow attention to drift
- Peak-End Rule — a frustrating wait can define the memory of an experience
References and further reading
- Yablonski, J. Doherty Threshold. Laws of UX. https://lawsofux.com/doherty-threshold/
- Doherty, W. J., and Thadani, A. J. (1982). The Economic Value of Rapid Response Time. IBM (reproduced on Jim Elliott’s Mainframe Blog). https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html
- Nielsen Norman Group. Response Time Limits. https://www.nngroup.com/articles/response-times-3-important-limits/
- Nielsen Norman Group. Progress Indicators Make a Slow System Less Insufferable. https://www.nngroup.com/articles/progress-indicators/
- Nielsen Norman Group. Skeleton Screens 101. https://www.nngroup.com/articles/skeleton-screens/
- Google web.dev. Interaction to Next Paint (INP). https://web.dev/articles/inp
- Google web.dev. Measure Performance with the RAIL Model. https://web.dev/articles/rail
- Yablonski, J. Laws of UX (format inspiration for this series). https://lawsofux.com/