The Doherty Threshold
What exactly is the Doherty Threshold?
In 1982, Walter J. Doherty and Ahrvind J. Thadani (IBM) analyzed the business value of rapid response. Their work is often summarized this way: keep system feedback under ~400 ms to sustain flow and increase throughput. In other words, human–computer interaction works best when neither side waits on the other. The paper The Economic Value of Rapid Response Time became a classic reference in usability and performance circles.
You’ll see the 400 ms figure repeated in modern UX summaries because it’s a clear, memorable design target. Think of it as the “feel-fast” zone for interactive feedback, such as button taps, toggles, field validation, menu reveals, and micro-state changes.
How it fits with other timing guidelines
Jakob Nielsen’s well-known response-time limits complement this nicely: ~0.1 s feels instantaneous, ~1 s keeps the user’s flow, and ~10 s risks losing attention entirely. The 400 ms target sits comfortably within that “keep the flow” window—fast enough to feel snappy, safely below the point where minds wander.
On the modern web, Google’s Interaction to Next Paint (INP) metric defines good responsiveness as ≤ 200 ms (75th percentile). If you can hit 200 ms, you’re automatically meeting the Doherty threshold for most interactions. That’s a great stretch goal for product teams.
Why designers and product teams should care
- Speed builds trust. Fast feedback tells users “your tap worked.” Doubt disappears; confidence grows.
- Speed reduces cognitive load. Fewer micro-questions (“Did that click register?”) means more mental space for the task at hand.
- Speed lifts metrics. In my projects, sub-400 ms micro-feedback consistently correlates with higher task completion and fewer backtracks—because people don’t stall between steps.
The original IBM work tied faster response to measurable productivity improvements—a reminder that performance is not only a dev topic; it’s core to UX value.
How to implement the Doherty Threshold in UX/UI
Here’s my field playbook that blends micro-interaction craft with system performance realities.
1) Prioritize “perceived” speed where it matters most
Not every interaction needs heavy lifting. Start with taps, toggles, menu opening, input focus, and inline validations—these must feel instant. Even when the back-end requires longer processing, return lightweight UI feedback within ~100–200 ms (press state, skeleton, optimistic UI). This keeps you under the Doherty threshold for perceived response, even if final data lands slightly later.
2) Use progressive disclosure to avoid slow, heavy screens
If a screen requires expensive data, don’t block the first paint. Stage complexity: show the first needed decision now, fetch secondary panels lazily. Users experience momentum, not a wall. (You’re aligning with the 0.1–1s comfort band while protecting the 400 ms “feel fast” on primary actions.)
3) Design micro-feedback that lands before 400 ms
- Visual state changes: Button depress → success tick/check, chip selection fill, tab underline move.
- Micro-motion: 150–250 ms eased transitions signal causality without feeling sluggish.
- Inline confirmation: “Saved,” “Added,” or count-badge increments the instant the user acts.
These are tiny, but they close the loop fast—users rarely notice the exact millisecond count; they notice certainty.
4) Pair UX choices with INP-oriented engineering
- Reduce long tasks on the main thread; avoid heavy JavaScript during input.
- Batch or defer non-critical work; keep layout shifts to a minimum so feedback appears quickly.
- Measure INP at the 75th percentile and aim for ≤ 200 ms. If you fall between 200–500 ms, your UI “needs improvement”—and you may drift above the 400 ms threshold in the wild.
5) Respect known limits for longer waits
Sometimes the system must work for more than 1 second (e.g., report generation). In those cases, the Nielsen guidelines apply: show progress indicators (or skeletons) quickly, keep users informed, and consider backgrounding with toasts/notifications.
How UXGen Studio turns this into a process
- Speed-of-Feedback Audit: We catalog interactions and tag them as ‘must feel instant,’ ‘should feel fast,’ or ‘can take longer.’
- Micro-interaction design: We specify the first 200–400 ms of feedback for each control (press states, optimistic UI, skeletons).
- Performance pairing: We collaborate with engineering to target INP ≤ 200 ms on the moments that matter, utilizing field data rather than lab estimates.
- Proof, not opinions: We instrument time-to-first-feedback, INP, backtracks, and completion in pre- and post-tests so stakeholders can see the lift.
Bring us your “laggy” moments. We’ll help you turn them into confidence cues.
FAQs
Q1. Is 400 ms a hard law?
No—it’s a valid target, as classic research shows that productivity and engagement rise with fast feedback. Use it to design the first confirmation. Some flows can tolerate longer steps, but keep micro-feedback quick.
Q2. If Google says INP ≤ 200 ms is “good,” should I ignore 400 ms?
Use both: aim for INP ≤ 200 ms (the modern standard) and ensure your UI still feels responsive under the classic ~400 ms threshold. If you meet the INP goal, you’ll naturally meet the Doherty target for most interactions.
Q3. What if my database is slow?
Return immediate UI confirmation (state change/skeleton) while heavier work completes. If the wait may exceed a second, add progress/UI messaging so users don’t drift.
Next Steps
Explore how we can help you transform your business with human-centered design and strategic consulting. Contact us
today to discuss your next project.
Prepared by: UXGen Design Studio
Website: www.uxgenstudio.com
Contact Information: info@uxgenstudio.com
Mobile: 9718540053