limiar
Doherty threshold
Productivity increases when a computer and its users interact at a pace of under 400 milliseconds.
Respond in under 400 ms, even if only to say it is processing.
There is a point at which the machine stops responding and starts making you wait, and it comes sooner than it seems, at around 400 milliseconds. Walter DohertyMeasured, at IBM in 1982, the productivity gain when the computer responds in under 400 ms. It is the origin of the threshold that bears his name.One reference in this work:1982The economic value of rapid response timeSee in the bibliography → and Ahrvind Thadani arrived at that number at IBM in 1982, measuring the productivity of operators at terminals. The finding was counterintuitive for the time: speeding the system up below that threshold did not just leave people more satisfied, it left them measurably more productive, because below it the action still feels like the person’s own, and above it, it turns into waiting.
Why there is no neuroscience here
The biological mechanism behind the effect, and how much of it was actually measured.
The 400 ms number came out of a productivity measurement on an IBM terminal, not a neuroscience laboratory: Doherty and Thadani timed real work and saw output rise when the system responded below that limit, and rise enough to pay for the cost of improving the machine. There is no established neural mechanism for this specific boundary. The effect is real and was measured in operator productivity, not in the brain.
The body this law presumes
Who it was measured on, and what changes when the body on the other side is another.
The 400 ms came out of IBM terminals in 1982, with trained operators on a machine the company controlled entirely. On an unstable connection or an old device that number is unreachable, and demanding it from whoever designs helps nobody. What still holds is more modest. When the response takes longer than that, the screen needs to say where it stands.
How design translates it
What to do with it on a screen, without turning a finding into a rule.
How to measure this in your product
Responding fast is not always possible, but responding is. A tap on the send button needs to change something on the screen before the person wonders whether they tapped: the button sinks, an indicator appears, an intermediate state takes its place. When the real response is going to take a while, say where it stands, loading, processing, waiting for the network, because what makes waiting feel like a freeze is the silence, and not the delay. The graph Walter Doherty and Ahrvind Thadani published in an IBM technical report in 1982 shows the number of transactions shooting up when the response falls below the threshold, and it is what supports the first half of the rule, which is the real response under 400 ms. Confirming by image or sound that the tap was registered is good design practice, not an IBM finding.
Where it breaks
Where the law does not hold, holds less, or holds in reverse.
Faking speed does not solve it. Skeleton loaders on everything hide the problem, and a progress bar that does not match the real progress costs more trust than an honest wait.
Related neuromyths
What gets said about this concept out there, and what the evidence actually shows.
-
The delay causes an “amygdala hijack” and the person loses the ability to reason.
The term came from popular science, not from the laboratory, and the physiology does not add up, because cortisolThe stress hormone, and a slow hormone: it takes twenty to forty minutes to peak, so it is not what explains the irritation with a frozen screen, but rather what builds up over a whole day of bad work. Sustained, it brings down working memory.See it in Emotion →See in the glossary → takes tens of minutes to peak. Half a second of waiting irritates, and irritation is already enough of an argument, without a hormone.
-
Human attention has dropped to 8 seconds, less than a goldfish’s.
There is no study. The number has circulated since 2015 attributed to a consultancy that credited it to a source that never published it, and the comparison with the fish has no scientific origin. Attention is not a single quantity measured in seconds.
Um caso
A real product where this showed up, with what happened and where to check it.
Four hundred milliseconds, measured at Google
In 2009 Google deliberately delayed the results page for a fraction of people, by between 100 and 400 milliseconds, for six weeks. A 400-millisecond delay reduced the daily number of searches per person by 0.44% in the first three weeks and by 0.74% in the following three. The effect grew with exposure time and did not vanish when the delay was removed. In the five weeks after the delay was removed, the group still searched, on average, 0.21% less than the control group. Four hundred milliseconds is not much time, and even so it changes how much the person uses the system, and the lost habit does not come back the moment the speed does. The experiment measures real latency, not the feeling of response a progress indicator gives, so it supports the first half of the threshold and leaves the second as good practice. Slowness charges even when nobody complains about it.
Experimente
A piece to check in your own body what the text has just claimed.
When a response becomes a wait
Adjust the delay and click Save. Do it a few times, varying the delay, and notice at what point the action stops feeling like yours and starts feeling like you are waiting for the machine.
- How it is perceived
- as a response — the action feels like yours
Only the four marked points were measured; the dashed line joins the ends and does not describe the path between them. Source: Doherty and Thadani, IBM, 1982.
Below 400 ms the action feels like yours; above it, it feels like you are waiting for the machine. The turn does not happen when the time doubles or triples, it happens in that narrow band around 400 ms, and it holds just the same for a save button and for an entire search.
Fontes
Enunciado citado de Doherty; Thadani, 1982.
- DOHERTY, W. J.; THADANI, A. J. The economic value of rapid response time. IBM, 1982. (IBM Technical Report GE20-0752-0.) Source
Leitura complementar: Doherty Threshold Laws of UX em inglês