Latency States by Duration Band
The single most common mistake: designing for the average response time. The average is fine by definition. The experience is set by the tail, and the tail is where people decide the product is bro...
The template
Latency States by Duration Band
Waiting used to be a spinner problem. It is a relationship problem now, because the user cannot tell whether anything is happening, whether it will finish, or whether they are still needed. Six bands, and each one requires a different answer. Pick the band by the realistic slow case, not the median.
Pick the band by the slow case
The single most common mistake: designing for the average response time. The average is fine by definition. The experience is set by the tail, and the tail is where people decide the product is broken.
Use your realistic slow case, roughly the slowest response a normal user hits in a normal week. If you do not have that number, ask engineering for it before you design the state. It is one query.
The six bands
Band 1: under 100ms
Feels instant. No state needed. Adding a loading indicator here makes the product feel slower, not more responsive.
Band 2: 100ms to 1 second
Perceptible but not worth explaining. Keep the interface still. Do not move layout, do not flash a spinner in and out, do not disable the control the user just used. The most common damage in this band is self-inflicted: a loading state that appears and vanishes reads as a flicker, and flicker reads as a bug.
Required: the control shows it was received. Nothing else.
Band 3: 1 to 10 seconds
The user is watching. This is where a generic spinner starts costing you, because it says "something is happening" and nothing else, and by second six they want to know what.
Required:
- An indicator that is clearly tied to the thing they asked for, in place, not in a corner.
- Text naming the work. "Reading your last three reports" beats "Loading."
- The interface stays usable elsewhere. Blocking the whole screen for eight seconds converts a wait into an outage.
Optional and usually worth it: streaming the output as it arrives. Streaming turns a ten-second wait into a two-second wait plus reading time, which is a different experience entirely.
Band 4: 10 seconds to 2 minutes
The user will look away. Design for the return, not just the wait.
Required:
- Progress with real substance: steps completed, or what is being worked on now. Never a percentage you are inventing.
- A way to cancel, and a clear statement of what cancelling loses.
- The result survives the user navigating away and coming back.
- If it finishes while they are elsewhere in the product, they are told.
Do not show an estimated time remaining unless it is honest. A countdown that resets or overruns does more damage than no estimate.
Band 5: 2 minutes to hours
This is no longer a wait, it is a job. Stop designing a loading state and start designing a task with a lifecycle.
Required:
- The user can close the product entirely and lose nothing.
- The job is listed somewhere with its status, findable without a link.
- Completion arrives through a channel the user actually watches.
- Failure arrives the same way, with the same prominence. Silent failure on a long job is the fastest way to lose a user's trust in the whole feature.
- Partial results are shown if partial results are useful.
Band 6: agent work, no bounded end
The system is working across sessions, possibly overnight, possibly indefinitely. The design problem is no longer latency, it is legibility.
Required:
- A place that answers "what is it doing right now" in one sentence.
- A running account of what it has already done, which is also the undo surface.
- A summary at the user's next session start, before anything else competes for attention.
- A stop control that is honest about what stopping leaves half-finished.
The table to fill in
| Surface | Median | Realistic slow case | Band | State designed? | Copy written? |
|---|---|---|---|---|---|
The last column is not a formality. Every band above needs words, and words are a design deliverable. If the copy is "Loading..." somebody has not made a decision yet.
Four rules that hold across all bands
Never lie about progress. A bar that moves smoothly and then sits at 90 percent teaches people the interface is decorative, and that lesson generalizes to everything else you show them.
Name the work, not the mechanism. "Checking the last thirty days of usage" is useful. "Querying warehouse" is engineering's mental model wearing a user's clothes.
A failed wait needs more design than a successful one. After twenty seconds of waiting, "something went wrong" is close to an insult. Say what failed, what survived, and what to do now.
Slow is survivable, unpredictable is not. People will happily wait for something that is consistently slow, and abandon something that is usually fast and occasionally not. Design for variance, not just for duration.
The one thing to do this week
Get the realistic slow case for your three most-used generated surfaces from engineering. Put each one in a band. If any of them lands two bands away from the state you actually designed, that gap is what people mean when they say the product feels unreliable.
From "Latency Is Interface", chapter 9 of The Design Operating Model. falkster.com/design/latency-is-interface