Doherty Threshold
- 611 installs
- 2k repo stars
- Updated June 14, 2026
- owl-listener/designer-skills
doherty-threshold is a Claude Code skill that applies the Doherty Threshold UX principle so developers building interactive interfaces can keep system response times under 400ms and preserve user flow through targeted fe
About
doherty-threshold is an owl-listener designer skill grounded in Walter Doherty and Ahrvind Thadani's IBM research (1982) showing productivity rises when computers respond within 400ms. The skill helps developers audit interaction latency, set technical response targets, and design feedback patterns that keep users in flow instead of waiting. Developers reach for doherty-threshold when buttons, forms, or API-backed UI actions feel sluggish and perceived performance breaks concentration. The guide frames sub-400ms response as a measurable UX requirement linking backend latency, optimistic UI, and loading states to sustained task completion.
- doherty-threshold
Doherty Threshold by the numbers
- 611 all-time installs (skills.sh)
- +61 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #638 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/owl-listener/designer-skills --skill doherty-thresholdAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 611 |
|---|---|
| repo stars | ★ 2k |
| Last updated | June 14, 2026 |
| Repository | owl-listener/designer-skills ↗ |
How do you keep UI responses under 400ms?
Use doherty-threshold for development tasks
Who is it for?
Frontend and full-stack developers tuning perceived performance and interaction latency on data-heavy or API-driven interfaces.
Skip if: Batch offline jobs or background ETL pipelines where multi-second runtimes are expected and interactive flow is irrelevant.
When should I use this skill?
A developer reports sluggish UI, asks about perceived performance budgets, or needs sub-400ms interaction targets for forms and actions.
What you get
Latency audit findings, sub-400ms interaction targets, and feedback-pattern recommendations for flow-preserving UI.
- Latency audit report
- 400ms interaction budget
- feedback pattern spec
By the numbers
- Doherty Threshold response target: under 400ms
- Based on IBM research by Doherty and Thadani (1982)
Files
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
Related skills
Lark Openapi ExplorerInstantly explore, test, and generate calls against the full Lark (Feishu) OpenAPI surface without leaving their agent workflow.493k
Lark EventConsume real-time events from Lark/Feishu as structured NDJSON streams inside AI agent workflows.387k16kLark Openapi ExplorerWhen an existing Lark/Feishu skill or CLI command cannot fulfill a specific requirement and they need to discover and invoke the exact native OpenAPI endpoint.386k16k
Just ScrapeQuickly search, crawl, extract structured JSON, or monitor web pages without writing custom scraping code.245k41Lark AppsQuery the current visibility and permission scope of a Lark (Feishu) app without writing HTTP client code.235k16k
Design An InterfaceGenerate multiple radically different interface or API designs in parallel before committing to one.188k198kHow it compares
Use doherty-threshold for interaction-flow latency budgets rather than Core Web Vitals-only performance audits focused on page load.
FAQ
What is the Doherty Threshold response time?
doherty-threshold targets system responses under 400ms based on IBM research by Doherty and Thadani (1982). Interactions above that window break user flow and reduce productivity during interface tasks.
When should developers use doherty-threshold?
doherty-threshold applies when building interactive web or mobile UI where API latency or rendering delays hurt perceived performance. The skill identifies slow actions and prescribes feedback patterns to stay under 400ms.