The 1982 IBM Study
In November 1982, IBM researchers Walter J. Doherty and Ahrvind J. Thadani published "The Economic Value of Rapid Response Time" in the IBM Systems Journal. They studied hundreds of programmers and data-entry staff working on time-sharing terminal systems, comparing productivity at different system response times - the delay between a command and the system's reply. Below 400 milliseconds, productivity didn't inch up, it jumped, and both work pace and error rate improved together. Past roughly one second, users started noticing the wait and their attention began to drift; the study's own language described sub-400ms systems as "addicting" to the people using them.
"Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other." - Walter Doherty & Ahrvind Thadani, 1982
Worth being precise about what was actually measured: Doherty and Thadani tested mainframe command-response latency for people doing sustained, repetitive work at a terminal - not page-load time, animation duration, or general app snappiness. The 400ms figure UX writing borrows today is an extrapolation from that specific finding, not a direct replication of it in a browser context.
Flow State and Interaction Pace
Mihaly Csikszentmihalyi's concept of flow - full immersion in a task that's challenging but manageable - depends on uninterrupted momentum. Every wait past the threshold risks breaking that state. In tools people use for sustained sessions - editors, dashboards, anything creative or analytical - the Doherty Threshold isn't a nice-to-have; it's the difference between a tool people stay immersed in and one they keep checking out of.
Response Time Guidelines
A separate, complementary set of numbers comes from Jakob Nielsen's usability research rather than Doherty and Thadani's study: three thresholds tied to human perception, not system architecture.
- 0.1 second: Feels instantaneous - the response reads as a direct effect of the user's own action.
- 1 second: The user notices the delay but their flow of thought stays unbroken; no loading indicator is strictly required below this.
- 10 seconds: The upper limit for keeping attention on the task at all. Past this, show a progress indicator or explain what's happening, because attention has already started to wander.
Design Techniques for Perceived Performance
- Optimistic UI: Update the interface immediately on user action and reconcile with the server after. (Instagram likes, X/Twitter retweets.)
- Skeleton screens: A structural placeholder reads as faster than a blank screen with a spinner, even at identical load times.
- Lazy loading: Load what's visible first; defer anything below the fold.
- Animation as bridge: A well-timed 200ms transition can mask a 300ms network call and keep the whole interaction inside the threshold.
Key Takeaways
- Doherty and Thadani's 1982 IBM study measured system response time for sustained terminal work, not general UI latency - the 400ms figure is borrowed context, not a literal replication.
- Nielsen's separate 0.1s / 1s / 10s thresholds are about human perception and apply more directly to everyday interface work.
- Optimistic UI and skeleton screens improve perceived performance even when actual load time doesn't change.
- Performance is a design decision, not just an engineering one - measure it and design around the thresholds deliberately.
