# 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_