interaction design
Doherty threshold
What is the Doherty threshold?
The Doherty threshold is the point - around 400 milliseconds - below which a system's response feels instant and keeps you in flow. Cross it and attention wanders: people doubt, re-check and disengage, even when the result is identical.
Prefer to watch?
Watch the recap 0:36
The demo
Tap the button. The instant it answers, say whether that felt instant or laggy. Eight taps, each with a different hidden delay - then we'll show you where your own line falls.
How did that feel?
What this demo shows (text version)
You tap a button eight times. Each tap answers after a different hidden delay - from instant to well over a second - and after each one you say whether it felt instant or laggy.
Sorted by delay, almost everyone's answers flip from "instant" to "laggy" somewhere around 300-400 milliseconds. That crossover is the Doherty threshold: below it a response feels immediate and you stay in flow; above it you notice the wait, doubt the system and disengage - even though the result is exactly the same.
Under about 400 milliseconds a response feels instant and you stay in flow; cross that line and people notice the wait, doubt the system and disengage. When the work itself can't be faster, make the response faster - a progress bar or optimistic UI answers inside the window.
You waved the quick responses straight through, then started calling them laggy long before a full second had passed. That line, near 400 milliseconds, is the Doherty threshold: under it an interface feels like an extension of your thought; over it, you notice the wait and begin to doubt.
Watch the recap 0:36
Read the transcript
The Doherty threshold is the point - around 400 milliseconds - below which a system's response feels instant and keeps you in flow. Cross it and attention wanders: people doubt, re-check and disengage, even when the result is identical.
You waved the quick responses straight through, then started calling them laggy long before a full second had passed. That line, near 400 milliseconds, is the Doherty threshold: under it an interface feels like an extension of your thought; over it, you notice the wait and begin to doubt.
This is why responsiveness is a feature, not a nicety. When a real operation can't beat the threshold - a network round-trip, a heavy query - the fix often isn't to make it faster but to keep the system answering: optimistic UI that assumes success, a skeleton screen, a progress bar that actually moves. You stay in flow because something responded inside the window, even while the real result is still on its way.
Faster isn't unconditionally better, though. A result that returns too instantly can read as cheap or untrustworthy - "we searched 4,000 listings" in ten milliseconds invites suspicion, which is why a short, honest pause (the labour illusion) sometimes earns more trust than raw speed. And a spinner that flashes for a tenth of a second is worse than none at all. The threshold is a line to clear, not a number to obsess over.