Doherty Threshold

When computers were slow, waiting was the user's job. Cutting the wait meant buying more expensive hardware, so nobody counted the delay as something worth fixing, and the industry settled on a rule of thumb that anything under two seconds was good enough.

Watching people at a terminal showed something else. During those two frozen seconds, a person lost track of what they had been about to do next. Someone picking an item off a list would start a conversation with the desk next door while the screen sat still, come back, and re-read the screen to find their place again. The machine spent two seconds; the person lost more than that.

In 1982, Walter Doherty and Arvind Thadani at IBM actually measured the relationship between response time and work completed. When responses dropped from two seconds to 0.4, the same people finished noticeably more transactions in the same hours — and the gain was larger than the drop in waiting time could account for on its own. People did not just speed up in proportion to the machine; the way they worked changed once the pause was gone. That 0.4 seconds took their name.

Measure the gap between the moment someone acts and the moment the screen visibly changes, then check whether that gap sits under 0.4 seconds. What gets measured is when the person noticed a change, not when the server finished its job. If the server answered in 0.2 seconds but the screen took another 0.5 to repaint, the person experienced 0.7.

The 0.4 figure comes from how long attention holds. When action and response sit close together, what you just clicked is still in your head and you go straight into the next move. Stretch the gap and that memory fades, so after the result arrives you spend time all over again reconstructing what you were trying to do.

The experience changes by band.

1. Under 0.1 seconds — it feels like your own hand did it. Type a character and it appears; flip a switch and it lights.
2. Around 0.4 seconds — you notice a pause, but your train of thought survives it. This is the band the threshold points at.
3. Past 1 second — the flow breaks. People start watching the screen and wondering whether anything is happening.
4. Past 10 seconds — they leave. They switch windows or pick up a phone.

The same bands showed up at Pagedeck. Filtering the document list by tag responded in 0.9 seconds on average, and users read that pause as nothing happening and clicked the tag a second time. The duplicate request made the whole thing slower in practice.

The threshold only applies to actions where a result is expected right away — pressing a button, picking an item from a list. Something a person starts knowing it will take a while, like exporting 100 documents, is judged by a different yardstick.

It shows up whenever a team decides what to do about how fast a screen answers. There are three directions to take: make it genuinely faster, make it look faster, or explain the wait.

1. Make it faster — fetch less per request, hold the result of a repeated request for a short while and reuse it, load frequently used lists ahead of time. Getting that 0.9-second tag filter down to 0.3 means never needing the other two.
2. Show it as finished before it is — this is where optimistic UI fits. The screen assumes success and updates without waiting for the server. Click a star and it fills immediately; if the server comes back with a failure, the change is rolled back then. It is reserved for actions that succeed nine times out of ten or better.
3. Explain the wait — loading states and skeleton UI live here. A skeleton draws grey placeholder shapes where the content will land. Nothing gets faster, but people stop reading the screen as frozen. It carries about a second; past that, a progress count or some other signal of how much is left has to take over.

The threshold also sets the pace for feedback, which is the practice of answering an action on the spot. How fast "on the spot" has to be is what this number fixes. It is the same reason the micro-interaction that makes a button look pressed has to land inside 0.4 seconds — the save behind it may take two, but the fact that the click registered cannot wait.

"This takes 0.9 seconds to respond after the click. That's well past the Doherty threshold."

Arguing for a fix with a measured number rather than an impression of slowness.

"If we can't get the server any faster right now, let's at least put a skeleton in."

The route of actually reducing the time is blocked, so the team moves to explaining the wait instead.

"The save can take a while, but the pressed state has to show up immediately."

Separating the whole operation from the first response. The 0.4 seconds applies to the first response.

At Pagedeck the number comes up when Noa hands off a design. For each action she writes down separately what changes the instant it is clicked and what changes once the server answers. Theo replies first on whether the immediate half is achievable, and where the second half looks likely to run past a second, the two of them decide on the spot what fills that gap.

The most common mistake is reading 0.4 seconds as a server response target. Engineering usually measures the time until the server returns an answer, so the number slides into that slot easily. But this threshold describes time as the person experienced it, which includes the network round trip and the work of repainting the screen. Set a 200-millisecond server target, hit it, and a screen where users wait close to a full second still reads as passing on the dashboard.

Reading it as a deadline for every operation is the other one. "Threshold" sounds like a ceiling on everything, which makes the reading natural. What the number asks for is the start of a response, not the completion of the work. An export that runs for 30 seconds still feels responsive if a progress indicator appears the moment it is clicked. Left uncorrected, this misreading leads teams to write the target off as unachievable and stop measuring at all, which leaves the small interactions that could easily have fit inside 0.4 seconds untouched.