← UX laws

Doherty Threshold

Doherty & Thadhani, 1982Response timeInteractive

Keep the machine's answer under about 400 milliseconds and the person stays with it. Go over, and they start to leave — a bit at a time, without noticing.

Two IBM researchers were arguing with accountants. Faster terminals cost money, and the case for buying them assumed people would save exactly the time the machine saved. What Doherty and Thadhani found was that the saving was much larger than that, and the reason was not in the machine at all. Below a certain response time people stopped treating the computer as something they submitted work to and started treating it as something they were working with. Their own thinking got faster.

Which means slowness has two prices. There is the wait, which everyone counts, and there is what the wait does to the person on the other side of it, which nobody does. The second one is the expensive half.

Thirty rounds below. A shape appears, you press the matching button, and the next shape arrives after a delay I control. The delay changes round to round. What is being measured is not the delay — I already know that — but your own time: the gap between the shape appearing and you answering. If the second one is a constant, waiting costs exactly what it says on the tin. If it isn't, it doesn't.

PRESS START BELOW
thirty rounds, five different delays
The two buttons never move and never change size, so the physical part of the task is identical at every delay — otherwise this would be measuring Fitts's Law again. The five delays are interleaved rather than run in order, so getting better at the task as you go spreads evenly across all of them instead of flattering the ones that came last.

What it costs you

400 milliseconds is not a target, it's a cliff edge. The difference between 200ms and 400ms is barely worth arguing about. The difference between 400ms and 1 second is the difference between a tool and a form you submit.

A progress bar is an admission, not a solution. It makes a long wait tolerable, which is worth doing, but it does not put the person back in flow. Nobody thinks faster because the bar is moving.

Optimistic responses buy the whole budget. Showing the result immediately and reconciling with the server afterwards is the only technique that actually gets under the threshold once there's a network in the way. It is also the one that requires you to design what happens when the reconciliation fails, which is why it usually gets dropped.

This is the law that AI products keep losing. A model that takes four seconds to answer is not a fast tool with a pause in it — it is a different kind of tool, used differently, and mostly used less. Streaming the first tokens quickly is not a trick to look faster. Under this law it genuinely is faster, because the person re-engages the moment something moves.

I have sat in a meeting agreeing that 2.5 seconds was acceptable because the old system took nine. It was an improvement and it was still the wrong side of this line, and I knew that at the time.

← UX laws

Where the list comes from. The collection I'm working through is Laws of UX by Jon Yablonski — the canonical version, and worth reading in full. His content is licensed CC BY-NC-ND 4.0, which permits sharing but not rewriting, so none of the wording here is his. The laws themselves belong to the psychologists who found them.

Who wrote it. Claude did. The prose, the demonstrations and the statistics, all of it, working from my direction and my edits. I picked the laws, decided what each page had to prove, and threw out the versions that did not. I would rather say that than let you assume otherwise.