Action and feedback
Doherty Threshold and responsiveness
Respond promptly and show what is happening. A single timing number cannot describe every interaction.
The idea in plain language
What it means.
Doherty and Thadhani's historical report describes productivity gains from faster terminal responses. The familiar 400-millisecond shorthand should not become a universal cutoff. Modern web measurement separates input response from task completion: a button can acknowledge a request quickly while a report takes longer to generate.
Evidence and interpretation
What supports it.
Historical system-performance observations plus current engineering guidance. The reviewed report transcription supports benefits from faster responses, not a universal 400 ms boundary across tasks and devices.
From principle to interface
Where you could use it.
Proposed applications, not tested outcomes. The expected effects are hypotheses to check with realistic tasks and users.
Application 1
Generate a large report
Acknowledge the request, display a truthful queued or running state, and provide the finished download when it exists.
Expected effect to test
The person knows whether the request was accepted and what can happen next.
Keep in view
Do not fabricate a percentage or show success before the output is ready.
Application 2
Save an editable preference
Update a low-risk preference promptly, show its saving state, and restore or explain the prior value if the server rejects it.
Expected effect to test
The interface stays responsive while making the persistence result visible.
Keep in view
Optimistic feedback needs a recovery path; payment, permission and destructive operations need explicit treatment of pending and confirmed states.
Turn the idea into a check
Use it deliberately.
- Measure response and completion separately on representative devices.
- For web responsiveness, use INP guidance: 200 ms or less at the 75th percentile of field page loads is the good threshold, segmented by mobile and desktop.
- Make relevant status messages available to assistive technology without unnecessary focus changes.
Where the rule gets complicated
Keep the limits attached.
- INP is a defined browser metric, not a total task-duration target or an accessibility certification.
- Average latency can conceal slow interactions and devices.
- Loading animation does not fix a slow operation, and apparent success must not hide failure.
A named principle does not settle an accessibility requirement, prove a conversion lift or replace testing the particular interface.
Application and implementation boundaries
What the application check shows.
The simulated operation exposed pending, failure and success states in order and disabled duplicate activation while pending. Its fixed delay is not a performance benchmark.
Methods: Local application example. A completed check covers the stated sample; it is not a safety certification.
- Target
- Original IonBin synthetic interface example; no external product or human-participant study.
- Version or capture
- 2026-10-19 local fixture
- Integrity scope
- SHA-256 f85d1056afd667225a1e0364edfb8f25b4693ffa7b2b8c7d7af5b92338b85ee4 identifies the exact HTML fixture only.
Test conditions
- 155.0.8059.82 Chromium; fresh context with all network requests blocked.
- Synthetic inputs, memory-only state, reduced-motion preference, 1280px and 320px viewports.
Individual checks and observations
Pending is not success
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: Pending state appeared and duplicate activation was disabled before the simulated operation completed.
Honest failure
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: Failure was stated in text and did not erase the input or claim a successful save.
Honest completion
passLocal application example: Exercise the original local application fixture and inspect the resulting controls or DOM state.
Observed: Completion offered review/edit wording after the simulated success state.
Security findings and boundaries
Review of the local example’s stated interaction boundaries; no backend, authentication, production permissions or external service was exercised.
Practical advice · caution
Fast feedback must not invent success
The fixture announced success only after its simulated outcome. Production systems need truthful server outcomes, idempotency and uncertainty handling.
Practical caveats
- Measure real interaction latency and task completion separately; a spinner does not prove acceptable performance.
What remains untested
- This checks an authored application example, not the truth, effect size or generality of the named principle.
- No users, assistive-technology participants, physical devices or production task outcomes were evaluated.
Security limits
- The example has no real authorization or persistence layer; its UI behavior cannot establish the security of a deployed workflow.
Evaluation sources
- Doherty and Thadhani: The Economic Value of Rapid Response Time (1982)
Third-party transcription of the original report; scan fidelity not independently established.
- web.dev: Interaction to Next Paint
Metric definition and current field-performance thresholds.
- W3C: Status Messages
Programmatic status communication.
Go to the source
Research and further reading.
- Doherty and Thadhani: The Economic Value of Rapid Response Time (1982)
Third-party transcription of the original report; scan fidelity not independently established.
- web.dev: Interaction to Next Paint
Metric definition and current field-performance thresholds.
- W3C: Status Messages
Programmatic status communication.
Related questions
More on action and feedback.
Research finding
Fitts's Law and target distance
Give controls enough room to hit and put related actions within a sensible reach.
Engineering principle
Postel's Law and input boundaries
Help people enter valid information while keeping the system's accepted meanings explicit.