#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