---
title: "Doherty Threshold"
source: "/reference/doherty-threshold"
description: "Interaction feels fluid when feedback arrives quickly enough that users can maintain a continuous task rhythm."
---
# Doherty Threshold
Interaction feels fluid when feedback arrives quickly enough that users can maintain a continuous task rhythm.
### Principle
Interaction feels fluid when feedback arrives quickly enough that users can maintain a continuous task rhythm.
### Why it matters
The historical Doherty Threshold is commonly associated with roughly 400 milliseconds, but modern product performance should be evaluated across several feedback horizons rather than one universal number. Immediate acknowledgement, responsive input, progressive rendering, optimistic updates, and honest progress indicators can preserve continuity even when backend work takes longer.
### Deeper design interpretation
Responsiveness is experienced as a sequence, not as one number. Users act, expect acknowledgement, observe progress, and decide whether to continue. A system can take several seconds to complete a task and still feel controlled when it immediately acknowledges input and accurately communicates what is happening.
The historic threshold is useful as context, yet modern interfaces should distinguish several latency layers: input response, visual acknowledgement, data availability, durable completion, and background work. Treating all of them as one metric leads to misleading optimizations.
Layr should focus on continuity and truthfulness. A fast-looking interface that declares success before persistence is complete can create more serious problems than a slower interface with honest state.
### What the agent should reason about
Measure or inspect each stage of the action-feedback loop. Determine when the user receives acknowledgement, when useful partial results are available, when server state becomes durable, and whether the user can safely repeat, cancel, or leave the task.
For long-running jobs, the ideal UI often shifts from “wait here” to “this is now a durable process you can revisit.”
### Common failure patterns
- Buttons remain visually unchanged while requests are in flight.
- Duplicate jobs are created because users retry an apparently unresponsive action.
- Blocking spinners hide partial content that could already be used.
- Optimistic success is shown for actions that may fail irreversibly.
- Long-running operations have no durable job page, stage, or retry state.
### Audit questions
- How quickly does the interface acknowledge the action?
- When is the operation actually durable?
- Can the user safely navigate away or retry?
- Is progress truthful enough to support the next decision?
### Example agent finding
> **High — Starting a migration has an eight-second silent period.** The CTA remains enabled and unchanged until the server returns, allowing duplicate starts. Disable or transition the button immediately, create an idempotent job, and expose the durable job state while processing continues.
### Agent directive
> Prioritize immediate acknowledgement and continuous feedback. Measure real latency and distinguish input response, visual feedback, data completion, and background work.
### Apply this when
- Search, filters, editors, navigation, save actions, command palettes, drag/drop, AI generation, imports, and long-running tasks.
### Observable signals
- A click produces no visible response while work is in progress.
- Repeated user input is accepted because the first action appears to have failed.
- A blocking spinner hides partial results that could be useful earlier.
- The UI reports completion before server state is actually durable.
- Long-running operations provide no progress, stage, cancellation, or recovery information.
### Recommended actions
- Acknowledge input immediately through pressed, pending, skeleton, progress, or status states.
- Render useful partial content when safe.
- Use optimistic updates only when rollback is reliable and the consequence is low enough.
- For long jobs, expose durable job state and allow users to leave and return.
- Measure latency before prescribing animation as a performance fix.
### Do not over-apply
Do not fake speed by hiding failure or claiming success early. Performance perception must remain truthful about durable state.
### Example
**Weak:** A 'Start migration' button remains unchanged for eight seconds, inviting repeated clicks and duplicate jobs.
**Stronger:** The action immediately enters a pending state, creates one durable job, reports current stage, and lets the user navigate away safely.
### Evaluation notes
- **Default severity:** High for duplicate actions, data loss, or core interaction lag; medium for perceived slowness.
- **Typical confidence:** High with performance traces; medium from UI behavior alone.
- **Primary evidence:** Performance metrics, network timing, pending states, duplicate events, job model.
- **Related rules:** Flow, Fitts's Law, Peak-End Rule, Pareto Principle
### References
- [Laws of UX — Doherty Threshold](https://lawsofux.com/doherty-threshold/)
## Related rules
- [Flow](/__layr/pages/reference/flow.md)
- [Fitts's Law](/__layr/pages/reference/fitts-law.md)
- [Peak-End Rule](/__layr/pages/reference/peak-end-rule.md)
- [Pareto Principle](/__layr/pages/reference/pareto-principle.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Interaction, Performance & Error Tolerance.
## Retrieve
- Canonical page: https://layr.design/reference/doherty-threshold
- Markdown for agents: https://layr.design/__layr/pages/reference/doherty-threshold.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "doherty-threshold"
title: "Doherty Threshold"
category: "Interaction, Performance & Error Tolerance"
origin: established
canonical_url: "https://layr.design/reference/doherty-threshold"
principle: "Interaction feels fluid when feedback arrives quickly enough that users can maintain a continuous task rhythm."
directive: "Prioritize immediate acknowledgement and continuous feedback. Measure real latency and distinguish input response, visual feedback, data completion, and background work."
applies_when:
- "Search, filters, editors, navigation, save actions, command palettes, drag/drop, AI generation, imports, and long-running tasks."
observable_signals:
- "A click produces no visible response while work is in progress."
- "Repeated user input is accepted because the first action appears to have failed."
- "A blocking spinner hides partial results that could be useful earlier."
- "The UI reports completion before server state is actually durable."
- "Long-running operations provide no progress, stage, cancellation, or recovery information."
audit_questions:
- "How quickly does the interface acknowledge the action?"
- "When is the operation actually durable?"
- "Can the user safely navigate away or retry?"
- "Is progress truthful enough to support the next decision?"
recommended_actions:
- "Acknowledge input immediately through pressed, pending, skeleton, progress, or status states."
- "Render useful partial content when safe."
- "Use optimistic updates only when rollback is reliable and the consequence is low enough."
- "For long jobs, expose durable job state and allow users to leave and return."
- "Measure latency before prescribing animation as a performance fix."
avoid_when:
- "Do not fake speed by hiding failure or claiming success early. Performance perception must remain truthful about durable state."
common_failure_patterns:
- "Buttons remain visually unchanged while requests are in flight."
- "Duplicate jobs are created because users retry an apparently unresponsive action."
- "Blocking spinners hide partial content that could already be used."
- "Optimistic success is shown for actions that may fail irreversibly."
- "Long-running operations have no durable job page, stage, or retry state."
evidence_types:
- "Performance metrics"
- "network timing"
- "pending states"
- "duplicate events"
- "job model"
default_severity: "High for duplicate actions, data loss, or core interaction lag; medium for perceived slowness."
typical_confidence: "High with performance traces; medium from UI behavior alone."
related_rules:
- { id: "flow", title: "Flow", url: "https://layr.design/reference/flow" }
- { id: "fitts-law", title: "Fitts's Law", url: "https://layr.design/reference/fitts-law" }
- { id: "peak-end-rule", title: "Peak-End Rule", url: "https://layr.design/reference/peak-end-rule" }
- { id: "pareto-principle", title: "Pareto Principle", url: "https://layr.design/reference/pareto-principle" }
```
## What to reason about
Measure or inspect each stage of the action-feedback loop. Determine when the user receives acknowledgement, when useful partial results are available, when server state becomes durable, and whether the user can safely repeat, cancel, or leave the task. For long-running jobs, the ideal UI often shifts from “wait here” to “this is now a durable process you can revisit.”
## Routing
Route a review here when evidence is measurable in interaction behavior: latency, target geometry, validation, parsing, task completion, duplicate actions, failed input, or recovery. Prefer instrumented evidence over aesthetic judgment.
## Review procedure
For every finding:
1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.
## Finding contract — emit exactly this shape
```yaml
finding:
rule_id: string
location: string
evidence:
- observable fact
impact: string
severity: low | medium | high | critical
confidence: low | medium | high
recommendation:
change: string
rationale: string
preserve:
- existing design-system behavior
- valid product constraints
```
## Example finding for this rule
High — Starting a migration has an eight-second silent period. The CTA remains enabled and unchanged until the server returns, allowing duplicate starts. Disable or transition the button immediately, create an idempotent job, and expose the durable job state while processing continues.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html