Doherty Threshold
Productivity soars when a computer and its users interact at a pace (<400 ms) that ensures neither has to wait on the other.
Read the original on lawsofux.com →
The scenario: searching a company knowledge base. Both versions below are live — try them. The backend is equally “slow” in both; only the way the interface handles the wait differs.
What's wrong here?
Press Search and… nothing. No spinner, no state change, no acknowledgment for three full seconds.
Users double-click, assume it's broken, or switch tabs. Try it.
Knowledge base
What changed?
The interface responds within 100 ms of every action: the button acknowledges the click, skeleton rows appear
instantly, and results stream in as they're ready. The backend didn't get faster — the feedback did. Try it.
Knowledge base
🔍 What changed
- Every click is acknowledged in under 400 ms — button state, status text, skeleton placeholders.
- Perceived performance improved without touching the backend: results stream in instead of arriving all at once.
- Skeleton rows set the expectation of what is coming and that it's coming.
- No dead time where the user wonders whether the system heard them.
💼 Explaining it to stakeholders
“Users don't abandon slow systems — they abandon silent ones. Keeping every response under 400 ms, even if it's just ‘working on it…’, keeps people engaged and in flow. This is often a one-sprint UI fix, not a six-month infrastructure project.”