If a system answers within about 400 milliseconds, it feels instant.
Productivity soars when a system responds within 400ms. Below that, interaction feels instant.
The Doherty Threshold comes from "The Economic Value of Rapid Response Time", an IBM report from 1982 (Form GE20-0752-00) by Walter J. Doherty and Ahrvind J. Thadhani. It looked at how quickly computers answered people working at terminals and found that productivity rose sharply, and not in a straight line, as response times fell below about a second. The 400 millisecond figure designers quote today is how that work is usually summarised. It was a study of terminal work in the early 1980s, so read 400 ms as a practical target, not a law of nature. Do not confuse it with Jakob Nielsen's three response-time limits (0.1, 1 and 10 seconds, from his 1993 book Usability Engineering), which describe how delay feels at different lengths.
A search shows its spinner the instant you tap, so quick searches flash it on and off. Set how long the app waits before showing it, and run a fast and a slow search to feel the difference.
Confirm the visual response lands inside 400ms. Otherwise add a loading or optimistic state.
When results render in under about 400ms, people stay in flow and refine their query live. They treat search as a conversation. Past that threshold they stop, wait, and lose their train of thought. Instagram's “like” is the same idea applied to actions: the heart fills instantly and the network request syncs in the background, so the interface never makes you wait to feel responsive.
For deliberately weighty actions like submitting a payment or deleting data, a brief, honest pause with clear confirmation builds more trust than an instant, ambiguous “done”. Speed is not always reassurance. Sometimes a moment of visible work is what makes an action feel safe.
On the web, Google's Interaction to Next Paint (INP) measures how quickly a page visibly responds to interactions: 200 milliseconds or less counts as good, and more than 500 as poor. Check your most important interactions with INP or your browser's Performance panel, on a mid-range phone and not only on your own laptop.
The idea that people and computers work best when the system responds within about 400 milliseconds, so neither side waits for the other. It comes from a 1982 IBM report by Doherty and Thadhani on the economic value of rapid response time.
Treat 400 ms as a guide, not a hard cutoff. The underlying finding is that productivity rises sharply as response times shrink, and 400 ms is the figure designers use as a practical target.
Doherty is about the response time that keeps people and systems in step, about 400 ms. Nielsen's limits describe how delay feels: about 0.1 seconds feels instant, about 1 second keeps your train of thought, and about 10 seconds is the limit of focused attention. They are compatible but separate.
Acknowledge every action straight away, use optimistic updates and skeleton screens where the real result takes longer, and avoid blocking the whole screen. Perceived speed matters as much as server speed.
Yes, as a goal for visible feedback. With limits: for actions like payments or deletions, a brief and clear confirmation builds more trust than an instant, ambiguous done.
A settings toggle waits for the server before it flips, so for ~700ms after a tap nothing moves. Users assume it missed and tap again — silently undoing their own change.
A search screen returns in ~600ms but hides it behind a centered, blocking spinner. The wait is short; the frozen screen makes it feel broken.