Doherty Threshold
Responses faster than 400ms keep users in flow. Slower than that and you lose them.
01 — TL;DR
Two sentences.
The Doherty Threshold — published by IBM researchers Walter Doherty and Ahrvind Thadani in the IBM Systems Journal in 1982 — established that computer response times under 400 milliseconds keep users in a state of cognitive engagement and productive flow, while response times over 400ms break the interaction loop, shift users into a waiting state, and produce measurable reductions in productivity, engagement, and satisfaction that compound across a session. The threshold is not a usability preference but a cognitive boundary: under 400ms, users treat the computer as an extension of their thought process; above 400ms, attention is forced out of the task and into awareness of the computer itself.
The three response time zones
Under 100ms — perceived as instantaneous; the system feels like part of the user's own action. Target for direct manipulation (drag, scroll, hover, typing). 100–400ms — perceivable but not disruptive; users notice a brief delay but stay in the loop. Simple feedback maintains engagement. 400ms–4s — Doherty Threshold crossed; users notice the wait and allocate attention to it. Loading states and skeleton screens are required. Above 4s — most users abandon, switch tasks, or form a lasting negative quality assessment.
Trigger phrase
When users are leaving a flow, abandoning a task, or reporting that an interface feels slow — and the team needs to understand what response time threshold matters psychologically, not just technically.
02 — When to Use
Apply this when…
When NOT to apply it
Skip Doherty framing for interactions where users explicitly understand and accept a wait — long-running background tasks, processing-intensive operations, large file uploads — where the design goal is comfortable, transparent waiting rather than eliminating it. Skip it when the technical constraint is genuinely immovable and no perceived performance technique can mask the latency adequately — design priority shifts to making the wait feel productive and reassuring. And skip it when response time is already comfortably sub-200ms for all conditions — further speed investment produces diminishing cognitive returns.
03 — How It Works
The mechanism
The threshold defines the boundary of the human-computer interaction loop — the cycle time within which a user can maintain the computer as a transparent extension of their cognitive process. Doherty and Thadani's 1982 study measured user productivity on IBM 3270 terminals and found a step-change, not a linear improvement: productivity approximately doubled when response times fell below 400ms compared to 700–1000ms. The mechanism is what they called interactive momentum — the user's ability to maintain continuous cognitive engagement when responses arrive before attention has time to drift. Above 400ms, attention is allocated to the wait itself and the task loop breaks.
Perceived performance ≠ actual performance
A true 300ms response and an optimistic UI that visually simulates a 300ms response (while actual processing takes 800ms in the background) produce equivalent user experience at the moment of interaction — because the threshold operates on perceived, not measured, response time. This separation creates significant design leverage. But perceived performance techniques are not unlimited: optimistic UI can produce jarring reversals on failure, skeleton screens that resolve after 4+ seconds shift users into negative evaluation regardless of design quality, and prefetching that mispredicts wastes bandwidth. Use them to close the last 200–300ms — not to mask multi-second processing.
04 — Real Example
Google's 200ms search and the infrastructure built around a single threshold
Google has published extensively on the relationship between search response time and user behaviour, providing the most comprehensive real-world validation of the Doherty Threshold at scale. Marissa Mayer's 2006 report on adding 10 additional results per search page found that increasing results from 10 to 30 raised page generation time from 400ms to 900ms — and produced a 20% drop in search traffic from users who had previously been conducting those searches. Users had not been asked whether they preferred fewer results; they simply stopped using the product as heavily once response times crossed the threshold.
Subsequent Google research on search latency — including work by Jake Brutlag and others on the Site Reliability Engineering team — established a near-linear relationship between search latency and search volume: each additional 100ms of response time correlated with roughly 1% of users doing fewer searches. The effect is not a one-time abandonment event; it is a cumulative engagement tax that compounds across the duration of a session and across users' long-term relationship with the product.
05 — In the Wild
Test yourself & see real examples
No examples yet — be the first.
Spotted a product whose interactions feel so instant they are invisible — or one where every action produces a visible pause that breaks the flow of the task? Submit a screenshot and annotate what you see. Every approved example gets attributed to you.
Seen the Doherty Threshold respected or ignored in a real product? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
Connected ideas
The Doherty Threshold is a performance psychology principle at the intersection of cognitive science and engineering. Its closest relationships are with the principles that describe what happens to users when response time exceeds the threshold.
The most important pairing is the Doherty Threshold with perceived performance design. The threshold defines the psychological target; perceived performance techniques are the design tools for achieving or approaching that target when actual technical performance falls short. Optimistic UI updates, skeleton screens, progressive content loading, and prefetching are not performance engineering — they are the design layer that translates psychological understanding of the threshold into product decisions that maintain user engagement under real-world performance constraints.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Solo · No prep
Open your product on a mid-range mobile device (not a developer-grade laptop) on a standard mobile data connection — not WiFi. Navigate to the most frequently used interaction in your product: the search, the primary navigation, the core action button, the main data load.
1. Perform the interaction five times and count in your head — one-Mississippi, two-Mississippi — from the moment you tap to the moment the response appears. Note whether you can complete your count to "one" before the response (over 1000ms), or the response appears around "Mississippi" (~500–600ms), or you barely register the count (under 400ms).
2. For any interaction where you can complete "one-Mississippi" before the response arrives, you have confirmed a Doherty Threshold violation that is likely visible to your average mobile user. Write down the specific interaction and the approximate felt latency.
3. For each violation, classify the cause: is this a performance engineering problem (actual processing takes too long), a network problem (data transfer is slow), or a perceived performance problem (processing is fast but no feedback is shown until it's complete)?
4. The classification determines the fix: an engineering sprint, a CDN investment, or a loading state design change. The Doherty Threshold is why the fix is worth prioritising — and the cause classification is how you direct that prioritisation to the right team.