Latency is a design decision

An engineering team spent six weeks cutting median response time from 4.2 seconds to 2.6. Satisfaction scores did not move. We changed the interface in three days and they moved considerably.

This is not an argument against performance work. It is an argument about where the perceived cost of waiting actually comes from.

Waiting is not the problem. Not knowing is.

Four seconds of a progress indicator that names the current step reads as competence. Two seconds of an unexplained spinner reads as breakage. The second one is faster and feels worse.

What people are actually intolerant of is uncertainty about whether the system is working, and that is a design variable, not an infrastructure one.

Three things that work

Name the step. “Reading the 41 attached documents” beats a spinner by a wide margin, and it costs nothing but a status field on the stream.

Show partial output. Streaming tokens is the obvious case, but the same principle applies to any pipeline: the first stage’s result is usually useful before the last stage finishes.

Make cancellation obvious and cheap. A visible cancel button reduces anxiety even when it is never pressed. It converts waiting from something happening to the user into something they are choosing to continue.

Where the milliseconds do matter

Below roughly 300 milliseconds, interaction feels direct and no explanation is required. If you can reach that, reach it — it is a categorically different experience.

Between 300 milliseconds and about ten seconds, the interface is doing most of the work and engineering effort has sharply diminishing returns. Past ten seconds you are no longer designing a wait, you are designing a background job with a notification, and it should be built as one.