What is the Doherty threshold?

The rule says that productivity rises when computer and user interact at a pace where neither has to wait for the other. According to Laws of UX, the threshold is under 400 milliseconds.

Do the Doherty threshold and Nielsen’s limits contradict each other?

No. Nielsen sees 0.1 second as an instant reaction and 1 second as the limit for the flow of thought. 400 ms sits between them and gives a target for a fast response.

Skeleton screen or spinner?

According to NN/g, a skeleton screen fits full-page loads under 10 seconds, and a spinner fits a single card or video. Under 1 second, neither is needed.

When do you use a progress bar?

According to Nielsen and NN/g, for tasks over 10 seconds. For uploading, downloading and converting files, you also use a progress bar instead of a skeleton screen.

The Doherty Threshold: the 400 ms Rule

In short

When a user presses a button, something has to happen on the screen right away. Even if the result isn’t ready yet, there has to be a response. The Doherty threshold gives this “right away” a number: 400 ms.

The second half is perceived speed. If you can’t shorten the real time, you can make the wait feel shorter. The skeleton screen is one of the tools for that.

Choose the delay and the indicator yourself in the demo below. You’ll feel the difference between 300 ms and 2,500 ms after a few tries.

Live demo: you choose the delay

Set the delay with the slider between 0 and 3,000 ms. Then choose what shows while waiting, and press Load. The result box gives the elapsed time and the limit it falls into.

Delay experiment

This demo needs JavaScript. If it’s off, you only see the loaded content below; the text explains the same idea.

My orders

Wireless headphonesOn the way
Running shoesDelivered
Book setPreparing

The delay isn’t a real network request but a timer that waits as long as you chose. The rating of the time is based on Nielsen’s limits, and the indicator notes on the NN/g article on skeleton screens. This mapping is mine. Because NN/g writes that shimmering skeleton animations can be distracting, the skeleton is static. If reduced motion is set, the spinner doesn’t spin, and the progress bar fills in steps of 10%.

I especially recommend watching the difference between “No indicator” and “Skeleton screen” at 2,000 ms. The time is the same, but waiting in front of an empty card feels longer.

Origin: Doherty and Thadani, 1982

According to Laws of UX, Walter J. Doherty and Ahrvind J. Thadani published a paper in the IBM Systems Journal in 1982. The paper set a goal of 400 ms for computer response time.

According to the same source, the previous standard had been 2,000 ms, or 2 seconds. Laws of UX writes that applications responding in under 400 ms were described as addicting.

I wasn’t able to open and read the paper itself. That is why I give the 400 ms figure and the citation as Laws of UX states them. Use the number as a target within your team too.

Nielsen’s three limits: 0.1, 1 and 10 seconds

Another well-known framework for response times comes from Jakob Nielsen. Nielsen wrote these limits in 1993 in chapter 5 of his book Usability Engineering. In a 2014 note, he said the same limits apply to web applications too.

0.1 sInstantNielsen: the user feels the system reacts instantly. Showing the result is enough.
0.4 sDoherty thresholdLaws of UX: if feedback comes within this time, attention is kept and productivity rises.
1 sLimit for flow of thoughtNielsen: the flow of thought stays uninterrupted. Beyond this, a sign that work is happening is needed.
10 sLimit for attentionNielsen: while waiting, the user wants to switch to other tasks. A percent-done indicator and a way to cancel are needed.

Figure: Nielsen’s three limits and the Doherty threshold between them. The scale isn’t even.

0.1 second: the user feels the system reacts instantly. According to the 2014 note, within this time they feel they are directly manipulating the objects in the interface themselves.

1 second: the user notices the delay, but their thought isn’t interrupted. According to Nielsen’s 2014 note, if the delay exceeds 1 second, you should show that the computer is working.

10 seconds: up to this time, the user’s attention stays on the screen. For longer tasks, show when the computer expects to be done. Also give the user a way to interrupt the task.

The Doherty threshold sits between 0.1 and 1 second in this framework. I combine the two like this: a response within 400 ms, and an indicator once 1 second is exceeded.

Perceived speed and the skeleton screen

Perceived speed is how long the user experiences the wait, and it doesn’t always match the clock. The first way to close this gap is to show the system status. That is Nielsen’s first heuristic, visibility of system status.

According to the 2023 NN/g article, a skeleton screen is a draft of the page, similar to a wireframe. It is used only for full-page loads and imitates the page layout with light grey boxes. The article writes that it shortens the perceived load time.

The same article also sorts out which indicator fits when:

Wait time	What to show
Under 1 second	Nothing. A screen that flashes by quickly can make people feel they can’t keep up.
2 to 10 seconds, one element	A spinner, for example for a single video or a dashboard card.
Under 10 seconds, full page	A skeleton screen.
Over 10 seconds	A progress bar and a clear time estimate.
Uploading, downloading, converting files	A progress bar. A skeleton screen doesn’t fit here.

NN/g adds two warnings. Shimmering or pulsing skeleton animations can be distracting and cause accessibility problems. An empty frame that only shows header, footer and background is no different from a spinner.

To me, the article’s most important warning is this: a skeleton screen doesn’t replace performance improvements. The page loads just as fast; the skeleton only makes the wait easier.

Reaching 400 ms in the interface

Even if the server’s response takes over 400 ms, the interface’s response doesn’t have to. Response and result are two things. When reviewing screens, I measure them separately.

The pressed button changes right away. When you press “Send” in a banking app, the button should switch to its pressed state and show “Sending”. Even if the result takes a few seconds, the user knows the request has arrived.

For low-risk tasks, show the result in advance. In an online store, the heart on a saved product can fill right away. If the request fails, the heart empties again and a short message appears. I don’t do this for a money transfer; there I wait for the real result.

Don’t clear the screen while a list refreshes either. Leave the old rows in place and show a small refresh sign at the top, and the user keeps reading.

My note

The most common mistake in my audits: nothing changes when a button is pressed. The user presses again, and the same payment or form goes out twice. Having the button switch to its pressed state right away and not accept another press usually solves this.

In second place is the habit of adding a spinner to every load. A ring that flashes briefly for a 300 ms filter makes the work seem slower than it is. For tasks under 1 second, I remove the indicator.

Then there is the skeleton screen that doesn’t match the real content. A skeleton with three rows appears, then a single row loads, and the page jumps. Drawing the skeleton with the dimensions of the real components prevents that. I set it up as a component in the design system.

If you want to improve the waiting moments and feedback in your product together, the Design & Ship Sprint delivers design and code together. If you want to see the problems first, start with the UX Audit.

The empty screen also has a lasting state. I describe the screen with no data in the empty state pattern. For loading order on screens full of cards, see the dashboard pattern.

The other laws are in the list of laws of UX. For the size and position of targets, Fitts’s law is a good next step. How to measure response times on the web is covered in the guide to Core Web Vitals.