What the Doherty Threshold really means
The Doherty Threshold is about <strong”>speed of interaction, not raw system speed.
It says this:
If a system responds to a user’s action in under 400 milliseconds, the user feels like they are working with the system, not waiting on it.
Once you cross that 400 ms mark, the brain notices the delay. Attention drops. Flow breaks.
So the magic number is < 400 ms.
Why 400 ms matters to humans
Humans are very sensitive to delays when they take an action.
Think about clicking:
- Click → instant response: feels smooth and satisfying
- Click → slight pause: feels laggy and annoying
- Click → nothing happens: user clicks again or gets frustrated
Under 400 ms:
- The brain perceives the response as immediate
- No mental context switch happens
- The user stays focused and productive
Over 400 ms:
- The brain starts thinking, “Is this working?”
- Trust starts dropping
- Friction increases
That’s the threshold.
“Productivity soars” explained simply
When neither the user nor the system has to wait:
- Users move faster
- They make fewer mistakes
- They feel in control
- The product feels “addictive” or “buttery smooth”
This is why fast tools feel fun to use.
The key takeaways, in plain language
1. Give feedback within 400 ms
Even if the real work isn’t done, show something quickly.
Examples:
- Button changes state
- Spinner appears
- Skeleton screen loads
- Input highlights or animates
The goal is:
Never leave the user wondering if their action worked.
2. Perceived performance > actual performance
Users don’t care how fast your backend is.
They care how fast it feels.
You can:
- Show content in chunks
- Load the most important part first
- Use placeholders instead of blank screens
If it feels fast, it is fast in UX terms.
3. Animation keeps attention while waiting
Animation is not decoration here. It’s communication.
Good animation:
- Says “we’re working on it”
- Keeps the user engaged
- Reduces anxiety
Bad animation:
- Too slow
- Too flashy
- Blocks interaction
Subtle and purposeful wins.
4. Progress bars make waiting tolerable
Even inaccurate progress bars help because:
- They give users a sense of control
- They set expectations
- They reduce frustration
A known wait always feels shorter than an unknown wait.
5. Sometimes slowing things down increases trust
This sounds weird, but it’s powerful.
Example:
- Instant success on a sensitive action (like payment or verification) can feel suspicious
- A short, intentional delay with feedback can feel more legitimate
So:
- Speed is good
- Believability is sometimes better
Where this shows up in real products
- Google search results feel instant
- iOS button taps respond immediately, even if loading continues
- Stripe shows payment processing steps
- Notion loads content progressively
- Figma feels “alive” because actions respond instantly
None of these wait silently.
One sentence to remember
Always respond to the user’s action in under 400 ms, even if the actual work takes longer.
That’s the Doherty Threshold.
