Laws of UX
Doherty Threshold
People stay engaged when a system responds in under ~400ms — past that, attention drifts.
Where it comes from
It comes from a 1982 paper by Walter Doherty and Arvind Thadani at IBM, who found that when a computer responded to a user in under about 400 milliseconds, productivity rose sharply — not just because waiting was reduced, but because the fast response kept users in a state of flow.
Why it matters for your website
Speed is a UX feature, not just an engineering one. The Doherty Threshold says that when systems respond in under about 400 milliseconds, users stay in flow. Above that, attention starts to wander and frustration builds — so even unavoidable waits need visible feedback.
Below the threshold, the interaction feels instantaneous and attention stays locked on the task. Above it, the mind starts to wander in the gap — and once attention has left, getting it back costs more than the wait itself did. The 400ms figure is a guide, not a law of physics, but the principle is robust: response time shapes engagement, not just satisfaction.
Crucially, perceived speed is what matters, and it can be designed. When real work genuinely takes longer, optimistic UI (showing the result before it's confirmed), skeleton screens, and well-judged progress feedback keep the experience feeling responsive — buying you time without breaking flow.
Wrong vs right
A search box that freezes for a second after each keystroke before showing results, so typing feels laggy and attention drifts.
Instant, sub-400ms feedback as the user types, keeping them in the flow of searching.
A button that does nothing for two seconds while a request completes, leaving the user unsure it registered.
An immediate response — a spinner, an optimistic state change — so the action feels acknowledged at once even if the work continues behind it.
A page that loads its content in one slow lump, showing a blank screen until everything is ready.
A skeleton screen that appears instantly and fills in, so the page feels fast even while loading.
Understanding Doherty Threshold
The Doherty Threshold is the finding that interactions feel effortless — and keep users engaged — when the system responds in under roughly 400 milliseconds. The original IBM research showed that crossing below this point didn't just reduce frustration; it changed behaviour, pulling users into a productive rhythm where they worked faster and stayed absorbed. Speed, in other words, is a feature of the experience, not merely a technical metric.
What makes the principle useful for designers is that perceived performance is partly a design problem, not only an engineering one. When you can't make the work genuinely faster, you can make it feel faster: acknowledge actions instantly, show optimistic results, use skeleton screens instead of blank ones, and give honest progress feedback for anything that genuinely takes time. The goal is to never leave the user staring at an unexplained pause.
The threshold connects responsiveness to attention. An unresponsive interface doesn't just annoy — it breaks concentration, and broken concentration is expensive to rebuild. Keeping interactions inside the threshold, or convincingly appearing to, is one of the highest-leverage things a product can do for engagement. It pairs with the related ideas of feedback and layout stability.
How Kweri checks it
Actual response time is something best measured on your live system under real conditions, and Kweri is clear that a static review can't fully capture it. What Kweri can do is flag design-level signals associated with poor perceived performance — for instance interactions or page loads that appear to give no immediate feedback, or layouts that would show a blank state rather than a responsive one. So Kweri points to where responsiveness feedback looks missing, while noting that true timing measurement needs performance tooling on your real traffic.
FAQ
What is the Doherty Threshold?
The Doherty Threshold is the finding that users stay engaged and productive when a system responds to them in under about 400 milliseconds. Below that, interaction feels effortless; above it, attention starts to wander.
Why is 400 milliseconds significant?
A 1982 IBM study by Walter Doherty and Arvind Thadani found that response times under ~400ms kept users in a state of flow and measurably raised productivity. It's a guideline rather than an exact constant, but the principle is well supported.
How can I make my site feel faster without making it faster?
Use perceived-performance techniques: acknowledge actions instantly, show optimistic UI before confirmation, use skeleton screens instead of blank loading states, and give clear progress feedback. These keep the experience responsive even when real work takes time.
What is optimistic UI?
Optimistic UI shows the expected result of an action immediately — before the server has confirmed it — then reconciles if anything goes wrong. It keeps interactions feeling instant and within the Doherty Threshold.
How does response time affect engagement?
Fast responses keep users absorbed and working in a rhythm; slow ones break concentration. Because regaining lost attention costs more than the delay itself, staying responsive directly supports engagement, not just satisfaction.
Related principles
Content that moves unexpectedly while a page loads causes misclicks, reading disruption, and loss of trust — layout must be visually stable from the moment content appears.
The brain has a limited processing budget — demand too much and performance collapses.
Every action should produce an immediate, clear response confirming it registered.
Attribution & sources
Identified by Walter J. Doherty and Arvind J. Thadani (1982). Catalogued from Laws of UX (Jon Yablonski).
From the 1982 IBM study by Doherty and Thadani; popularised for designers by Jon Yablonski's Laws of UX.
See Doherty Threshold on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →