Doherty Threshold
The principle from IBM research that system response times under 400 milliseconds keep users in a state of flow and productivity, while delays beyond this threshold break concentration and reduce engagement.
What Is the Doherty Threshold?
The Doherty–Thadani work is commonly summarized as evidence that shorter, sub-second feedback can improve interactive productivity. Treat 400 milliseconds as a historical design heuristic, not a universal flow or conversion boundary.
Also Known As
- UX and design: "flow threshold," "instant-feel target"
- Product and engineering: "400ms budget," "responsiveness SLA"
- Marketing and growth: "page speed impact on conversion"
- Performance teams: "interaction latency target"
How It Works
Illustrative test: a team compares delayed filter feedback with immediate, accurate progress feedback while the request resolves. Measure errors, task completion, and downstream behavior; do not assume crossing one latency threshold will raise conversion.
Best Practices
- Set performance budgets by interaction type and user need, then measure real-user latency and task completion.
- Use optimistic UI, skeleton screens, and progressive loading to maintain the feel of responsiveness even when the network is slow.
- Show immediate visual feedback (button press state, spinner within 100ms) so the user knows the click registered.
- Prioritize first-interaction latency over average latency; a fast initial response sets expectations for the session.
Common Mistakes
- Optimizing only total page load time while ignoring post-load interaction latency, where most flow breaks occur.
- Showing a full-screen spinner for sub-second operations, which actually emphasizes delay instead of hiding it.
Industry Context
Dashboard filters, variant swaps, cart updates, validation, and autocomplete all benefit from clear, timely feedback. Define acceptable latency from the task and measure user behavior rather than importing a universal 400-millisecond conversion rule.
The Behavioral Science Connection
Timely feedback can help preserve task continuity, but one latency cutoff does not determine flow or a System 1/System 2 state.
Key Takeaway
Make interactions responsive and keep users informed during unavoidable waits. Use real speed where possible and accurate progress feedback where it is not.