Skip to content
UX Atlas
Plate LAW·006 · LawGrid B2 · Rev. 2026-08-14

Doherty Threshold

Below roughly 400 milliseconds of system response, people stop waiting on the machine and productivity rises sharply.

LawEstablished researchIntermediate

Definition

Walter Doherty and Ahrvind Thadani's 1982 IBM study found that reducing computer response time below about 400 milliseconds produced a disproportionate increase in user productivity, because the interaction becomes conversational rather than turn-taking.

Established research. Originates in published research and has been replicated. The effect is real. Its size in your product still needs measuring.

On this plate
  1. 1Definition
  2. 2Perception thresholds worth designing around
  3. 3Perceived speed levers when you cannot make it faster
  4. 4Working with the number instead of against it
  5. 5In practice
  6. 6Local chart
  7. 7Sources
  8. 8Continue from here

Reach for this when

  • Designing any action that triggers a network request.
  • Choosing between a spinner, a skeleton and no indicator at all.
  • Prioritising performance work against feature work.

Common mistakes

  • Quoting 400ms as a hard universal threshold.
  • Showing indeterminate spinners for sub-second waits.
  • Measuring server time instead of the time until the user sees a useful change.
  • Treating the 400 millisecond figure as a modern target rather than as a finding from a specific 1982 study of terminal work.

Perception thresholds worth designing around

These come from Robert Miller's 1968 response-time work and Nielsen's later summaries. They are the practical bands most teams use.

DurationHow it feelsWhat to do
Under 100 msInstantaneous, direct manipulationRespond in the frame. No feedback needed beyond the state change.
100 ms to 300 msFast, still a direct responseOptimistic UI. Show the result and reconcile if it fails.
300 ms to 1 sNoticeable delay, flow is preservedShow an inline state change. A spinner here often makes it feel slower.
1 s to 10 sAttention wandersShow a skeleton matching the final layout, or a determinate progress indicator.
Over 10 sTask is abandoned or backgroundedGive a percentage, an estimate and a way to leave and come back.

Perceived speed levers when you cannot make it faster

  • Optimistic updates: apply the change locally, reconcile on the server response, and roll back visibly if it fails.
  • Skeleton screens shaped like the real content, which read as loading progress rather than as a pause.
  • Prefetch on hover or on intent, so the navigation has already started when the click lands.
  • Stream partial results rather than waiting for a complete response.
  • Fill the wait with something useful, such as letting the user continue filling the next field.

Working with the number instead of against it

Do

  • Respond to the input immediately, even when the result is not ready.
  • Reserve the space the result will occupy, so nothing jumps when it lands.
  • Prefetch the thing they are obviously about to ask for.
  • Show partial results as they arrive rather than holding everything for the slowest part.

Do not

  • Add an artificial delay to make work look substantial. It reads as slowness, not as effort.
  • Show a spinner for something that will finish in 200 milliseconds.
  • Block the whole screen for an operation that affects one row.
  • Measure response time on the development machine and call it fast.

In practice

  1. i.

    Search as you type

    Site search

    Suggestion lists that return under 200ms turn search into a conversation. The same feature at 800ms is worse than a plain submit button, because the user is now typing into a UI that keeps changing beneath them.

  2. ii.

    Optimistic like and save actions

    Social and content products

    The icon fills instantly and the request runs in the background. The rare failure surfaces as a small revert with an explanation, which is a far better trade than making every success wait for the network.

  3. iii.

    Fast, and wrong

    The cost of optimism

    An action that confirms instantly and fails silently in the background is under the threshold and worse than a slow one. Optimistic responses need a visible, honest correction when the server disagrees.

Local chart

LAW·006 · Region I · Grid B2

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

FlowPSY·005 · WHY THIS WORKSProgress IndicatorCMP·026 · APPLIED THROUGHAutocomplete and TypeaheadPAT·003 · APPLIED THROUGHLoading StatesPAT·011 · APPLIED THROUGHOptimistic UIPAT·013 · APPLIED THROUGHSkeleton ScreensPAT·012 · APPLIED THROUGHMotionFND·052 · APPLIED THROUGHPerformance as User ExperienceFND·054 · APPLIED THROUGHLoading and Progress CopyWRT·011 · APPLIED THROUGHWebPageTestTOOL·032 · OFTEN USED WITHDashboard UX ChecklistCHK·004 · CHECK YOUR WORKInteraction to Next PaintTERM·126 · SHORT DEFINITION

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

  1. [1]

    The economic value of rapid response time

    W. J. Doherty and A. J. Thadani, IBM, 1982

  2. [2]

    Response time in man-computer conversational transactions

    R. B. Miller, AFIPS Fall Joint Computer Conference, 1968

    Source of the 0.1, 1 and 10 second perception bands.

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

A DashboardA Mobile AppA Search ExperienceAn AI Product

Why this works

The reasoning this entry rests on.

  • FlowPSY·005 · Psychology

Applied through

Where this shows up as a concrete interface decision.

Often used with

These usually appear in the same screen or the same decision.

Check your work

Review passes that test whether this was done properly.

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.