Loading & Skeletons

Now the export runs twice. The screen finally changes, they see one file, and they spend a minute wondering whether the second one is coming. Nothing was slow enough to be a bug, and the whole problem was the two seconds where the screen said nothing at all.

Engineering usually owns how long things take. What the screen does during that time is yours, and it decides whether the same 800 milliseconds reads as instant or as broken.

Response-Time Thresholds

A team adds a spinner to every action in their product, on the reasoning that feedback is always better than silence.

The result is a screen that flickers. Actions that finish in 90 milliseconds show a spinner for a single frame. That reads as a glitch rather than as speed, and the product feels less reliable than it did with nothing there.

Feedback is not always better. What it needs to match is the length of the wait, and three numbers set it before you draw anything.

The Three Limits

Jakob Nielsen set these out in Usability Engineering in 1993, and they have held up because they describe people rather than hardware.

0.1 seconds is the limit for something feeling instantaneous. Under it, a person experiences the result as directly caused by what they did, and no indicator is needed or wanted.

1 second is the limit for uninterrupted thought. Somewhere under it people notice the delay but stay inside what they were doing. Nothing is needed beyond the result arriving, though the action itself should acknowledge the press.

10 seconds is the limit for holding attention on the task. Past that, people switch to something else, and the wait needs to be something they can leave and come back to.

Between 1 and 10 seconds is where indicators earn their place, and that band is most of what this module is about.

The 400 Millisecond Finding

One older number explains why fast products feel different rather than merely quicker.

Walter Doherty at IBM measured this in 1982 and found productivity rose sharply once system response dropped below 400 milliseconds. The gain was larger than the time saved, because at that speed people stop planning around the wait and start working continuously. It is the difference between a tool you operate and a tool you think through.

When the Answer Is No Indicator

Anything that usually finishes under a second should show nothing at all.

A loader that appears and vanishes inside 200 milliseconds is a flash of noise, and it makes a fast action look unstable. So hold the indicator behind a short delay, commonly around 300 to 500 milliseconds, and let quick responses stay clean. Only genuine waits get anything drawn.

Then guard the other end. If the indicator does appear, keep it up long enough to be read, since one that arrives at 320 milliseconds and leaves at 380 is worse than either alternative. A minimum visible time of around half a second stops that.

Measure Before You Design Any of This

Every choice here rests on how long things actually take, and nobody knows that from memory.

So get the real numbers first, at the percentiles rather than the average. A median of 300 milliseconds with a slow tail at 4 seconds is a completely different design problem from a steady 800, and the average hides both. Ask for the 50th, 75th and 95th percentiles of the calls behind each screen.

Then check them on the connection your customers have rather than office wifi, because the tail is where the design work is.

This is also the part no model can do for you. A model told "the reports page loads" has no idea whether that is 200 milliseconds or six seconds, so every recommendation it makes about indicators is a guess until you bring the measured times.

Pro tip: Ask an engineer to add an artificial two-second delay to one real screen for an afternoon. Sitting with the wait you are designing for teaches more than any specification, and it usually changes which of the three limits you think you are working inside.