doherty-threshold
owl-listener/designer-skills
Keep system response under 400ms to preserve user flow and productivity.
What is doherty-threshold?
The Doherty Threshold is a design principle establishing that system responses under 400ms keep users in cognitive flow, while delays above this threshold cause noticeable disruption. Apply it when diagnosing perceived slowness, setting performance budgets, or designing feedback for unavoidable waits.
- Identify interaction latency thresholds where user flow breaks (0–100ms instant, 100–300ms fast, 300–400ms boundary, 400ms+ slow)
- Design immediate visual feedback on triggering elements within 100ms, even when backend operations take longer
- Apply loading indicators, skeleton screens, and progress feedback for operations exceeding 400ms
- Optimize latency budgets for high-frequency user interactions
- Distinguish between perceived wait time and intentional motion design
How to install doherty-threshold
npx skills add https://github.com/owl-listener/designer-skills --skill doherty-thresholdHow to use doherty-threshold
- 1.Measure actual interaction latency on target devices and network conditions, not just in development
- 2.Identify which interactions users expect to be immediate (toggles, tab switches, button presses, search filters)
- 3.For interactions completing under 400ms, ensure no loading state is shown to avoid disruptive flashing
- 4.For interactions taking 400ms–3s, show a loading indicator immediately upon user action
- 5.For interactions taking over 3s, display progress feedback or skeleton screens that maintain spatial context
- 6.Apply visual state changes to the triggering element within 100ms to acknowledge the action, regardless of backend completion time
- 7.Test with real latency conditions and measure perceived responsiveness, not just raw response times
Use cases
- Diagnosing why a UI feels sluggish by measuring interaction latency against the 400ms threshold
- Setting performance targets for slide transitions, tab switches, and dropdown interactions
- Designing loading states and skeleton screens for search results or autocomplete that cannot complete sub-400ms
- Implementing optimistic UI updates to acknowledge user actions immediately while server responses complete
- Prioritizing performance optimization for the most frequently used interactions in a product
- Product designers optimizing perceived performance
- Frontend engineers setting latency budgets and measuring real-world interaction times
- UX researchers investigating user productivity and flow
- Performance-focused teams diagnosing slowness complaints
doherty-threshold FAQ
No. The 400ms threshold emerged from observed productivity patterns in terminal systems and represents a design target, not a strict empirical boundary. Modern applications often exceed it; the goal is to minimize the perception of waiting through feedback design.
Only if the action will take 400ms–3s. For actions under 400ms, showing a spinner is itself disruptive. For actions over 3s, show progress feedback or skeleton screens instead of a bare spinner.
The threshold applies to perceived wait time, not intentional motion. A deliberate 250ms entrance animation is fine; what matters is that users do not perceive they are waiting for a system response.
Acknowledge the action immediately with a visual state change (within 100ms), then show appropriate feedback: a loading indicator for 400ms–3s delays, progress or skeleton screens for longer waits, or optimistic UI that updates immediately and reconciles with the server response.
Focus on high-frequency interactions users expect to be immediate: button feedback, toggles, checkboxes, tab switches, inline filters, autocomplete suggestions, and view transitions. Measure latency on real devices and network conditions to identify bottlenecks.
Full instructions (SKILL.md)
Source of truth, from owl-listener/designer-skills.
name: doherty-threshold
description: Apply the Doherty Threshold — keep system response under 400ms to preserve user flow. Use when diagnosing perceived slowness or setting a performance budget. For what to show during unavoidable waits, use loading-states.
Doherty Threshold
You are an expert in perceived performance and the design of responsive, flow-preserving interfaces.
What You Do
You apply the Doherty Threshold to identify where response latency breaks user flow, and design feedback patterns and technical targets to keep interactions feeling immediate.
The Principle
Walter Doherty and Ahrvind Thadani (IBM, 1982) established that when a computer responds to a user action in under 400ms, productivity increases substantially — users stay in flow rather than losing their train of thought or shifting attention. Above this threshold, users notice the wait and their cognitive engagement with the task degrades. The key thresholds:
| Response time | User perception |
|---|---|
| 0–100ms | Instant — the system feels like a direct extension of the action |
| 100–300ms | Fast — perceptible but not disruptive |
| 300–400ms | Approaching the boundary — some users notice |
| 400ms–1s | Slow — users are aware of waiting; a response indicator is needed |
| 1s+ | Definitely slow — progress feedback required; flow is broken |
| 10s+ | Task-level disruption — users switch context |
Design Applications
Where Sub-400ms Matters Most
- Slide and view transitions: switching between screens or slides should complete in under 400ms; beyond this, the transition itself becomes a wait
- Inline interactions: toggles, checkboxes, dropdowns, tab switches — all should feel immediate
- Search and filter: results should begin appearing before 400ms; if not, show a skeleton or spinner immediately
- Autocomplete: first suggestions should appear within 300ms of typing
- Button feedback: visual state change on press must happen within 100ms, regardless of whether the underlying action completes
When You Cannot Meet the Threshold
If the system genuinely cannot respond in under 400ms:
- Acknowledge immediately (within 100ms) with a visual state change on the triggering element
- Show a loading indicator if completion will take 400ms–3s
- Show progress (not just a spinner) if completion will take more than 3s
- Optimistic UI: update the interface immediately, reconcile with the server response when it arrives
- Skeleton screens: preferred over spinners for content that has a known layout — they maintain spatial context and feel faster
What the Doherty Threshold Is Not
- It is not a strict empirical threshold beyond which all productivity is lost — it is a design target that emerged from observed productivity patterns in terminal systems
- It does not mean that animations and transitions must be under 400ms total; a deliberate 250ms entrance animation is fine. The threshold applies to perceived wait time, not to intentional motion
- Modern applications with complex data fetching will sometimes exceed it; the goal is to minimize the perception of waiting through feedback design, not to guarantee sub-400ms API responses
Best Practices
- Measure real interaction latency on target devices and network conditions, not just in development
- Treat 400ms as the outer bound for any interaction that a user expects to be immediate
- Never show a loading state for actions that complete under 400ms — the flash of a spinner is itself disruptive
- Prioritize latency budgets for the interactions users take most frequently
- Pair response time optimization with motion design: a well-timed 200ms transition feels fast; an abrupt 50ms flash can feel broken
Related skills
More from owl-listener/designer-skills and the wider catalog.
empathy-map
Build Says, Thinks, Does, Feels maps to align teams around user understanding from research data.
error-handling-ux
Design error prevention, detection, and recovery across multi-flow products.
experience-map
Map the full ecosystem of touchpoints, channels, and relationships across a multi-channel service.
feedback-patterns
Design confirmations, status updates, and notifications that acknowledge user actions.
fitts-law
Apply Fitts's Law to size and position controls for faster, more accurate interaction.
form-design
Design forms that reduce abandonment and errors through clear layout, smart validation, and accessibility.