doherty-threshold
The Doherty Threshold skill identifies where system response latency breaks user flow and recommends feedback patterns to keep interactions under 400ms, the cognitive boundary where users remain engaged. Use this when designing interfaces where response time directly affects user productivity, such as inline interactions, search results, autocomplete, or transitions, and when planning graceful feedback for operations that cannot meet the threshold.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/doherty-threshold && cp -r /tmp/doherty-threshold/interaction-design/skills/doherty-threshold ~/.claude/skills/doherty-thresholdSKILL.md
# 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: 1. **Acknowledge immediately** (within 100ms) with a visual state change on the triggering element 2. **Show a loading indicator** if completion will take 400ms–3s 3. **Show progress** (not just a spinner) if completion will take more than 3s 4. **Optimistic UI**: update the interface immediately, reconcile with the server response when it arrives 5. **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
Design an A/B experiment — hypothesis, variants, primary metric, and sample size. Use when a change can be measured quantitatively at scale. For observing behaviour qualitatively, use `test-scenario`.
Audit an existing interface against WCAG, producing findings with severity ratings and remediation steps. Use when you have a design or build to assess now. Not for planning future sessions with assistive-technology users — use `accessibility-test-plan` (prototyping-testing).
Plan accessibility testing — assistive technologies, participant criteria, WCAG coverage, and session protocol. Use when scheduling testing with real AT users. Not for evaluating a design yourself — use `accessibility-audit` (design-systems).
Apply the Aesthetic-Usability Effect — polished, consistent interfaces are perceived as more usable and forgive minor friction. Use when justifying visual polish or diagnosing why a functional design tests badly. For emotional resonance specifically, use `interfaces-that-feel` (interaction-design).
Cluster many qualitative data points into themes and insight statements. Use when synthesising across multiple sessions or sources. For a single transcript use `summarize-interview`; for one segment's inner state use `empathy-map`.
Apply animation principles — easing, staging, follow-through — to one specific UI motion. Use when tuning how an animation feels. For product-wide duration and easing tokens use `motion-system` (design-systems); for a full interaction spec use `micro-interaction-spec`.
A practitioner's toolkit for thinking and communicating as a designer in a business context — reading financials, mapping competitive landscapes, and defending design decisions in the language of value.
Analyse open or closed card sort results into a proposed grouping and label set. Use after running a sort study. For turning that evidence into a full structure, use `information-architecture` (ux-strategy).