The Doherty Threshold

The law

People stay engaged and get more done when a computer responds in under about 400 milliseconds.

Below that point, the person and the system work at the pace of the person's thinking. Above it, the person starts waiting, and attention starts to drift.

Where it comes from

Walter J. Doherty and Ahrvind J. Thadani, both at IBM, published the finding in The Economic Value of Rapid Response Time, an IBM report from 1982. They studied people doing interactive work on mainframe terminals and looked at how productivity changed with the system's response time.

At the time, a response time of about two seconds was widely treated as good enough, a figure associated with Robert B. Miller's 1968 paper on response time in conversational computing. Doherty and Thadani reported that productivity kept rising well below two seconds, and rose sharply once responses came back in under about 400 milliseconds. Their argument was economic: faster systems paid for themselves in the work people got done.

The report was a company publication, not a peer-reviewed paper, and it measured terminal work in 1982. Treat the 400 milliseconds as a well-known reference point rather than a precise constant.

What it means for an interface

• Respond to every action at once. Even when the work takes longer, the interface can acknowledge the click or tap immediately: a pressed state, a spinner, an item appearing in a list.
• Make common actions fast in fact. Caching, preloading the likely next screen, and doing work in the background keep frequent actions below the threshold.
• Show progress for long waits. When an action will take seconds, say so and show progress, so people know the system is working and can decide whether to wait.
• Update the interface before the server confirms. For actions that almost always succeed, such as liking a post or ticking a task, show the result right away and handle the rare failure afterwards.

Examples

Search as you type. Results that update within a fraction of a second of each keystroke let people refine a query by looking at the results. If results take seconds, people type the whole query and wait instead.

Skeleton screens. A page that shows the outline of its content immediately and fills it in as data arrives feels responsive even when loading takes a while, because something happens at once.

Optimistic updates. A task app that ticks the box the moment it is tapped, and syncs in the background, feels instant. One that waits for the server before showing the tick makes people wonder whether the tap worked.

Where it is misapplied

• Faking speed with animation. Long transitions added to look smooth make every action slower. Animation that delays the result works against the threshold.
• Treating 400 milliseconds as a pass mark. The figure came from one company's study of terminal work. Faster is better well below it, and some interactions, such as dragging or typing, need feedback within a few tens of milliseconds.
• Hiding real delays. An immediate response must still be honest. Showing an item as saved when the save may fail, with no recovery path, trades a moment of speed for lost work.

Checklist

• Every click, tap and keypress gets visible feedback at once.
• The most frequent actions complete in under about 400 milliseconds.
• Longer operations show progress and, when it is known, the expected time.
• Optimistic updates have a clear message and a recovery path when they fail.
• Transitions never delay a result the person is waiting for.

Related

• Peak-End Rule: a long wait at the end of a flow colors how the whole flow is remembered.
• Fitts's Law: the other half of interaction speed, the time to reach a control.
• Patterns: Empty State.