Progress Indicator

Concept

A screen element showing how far a task has gotten, as a bar or a spinner, so the person waiting doesn't read the wait as a malfunction.

Why it exists

A wait with no visible sign reads as broken. Press save, watch the screen stay exactly as it was, and people press again within two or three seconds. It didn't look like it registered, so they repeat it — and the same document gets saved twice, or the same payment goes out twice. A second press isn't carelessness; it's the only feedback loop the screen left open.

The larger loss is the people who leave. With a file uploading and nothing on screen, someone hits refresh, and an upload that had reached 90 percent starts over. The support tickets are predictable too. They don't say it's slow; they say it doesn't work. It was working the whole time. There was simply no signal that it was.

The bands in which people experience waiting are usually treated as three. Respond within 0.1 seconds and it feels instantaneous; within a second and the person's train of thought holds; past ten seconds and they go do something else. The bands are about perception rather than engineering, which is why the same four-minute job can feel acceptable or feel broken depending on what's on screen. Each band needs a different treatment, which is why the thing that reports progress became a named part with rules of its own rather than a detail of each screen.

How it works

Two forms split on one question: whether the total is known.

  1. When the total is known, show a bar. Three megabytes of an eight-megabyte file uploaded means a bar filled to 37 percent. For work counted in items, like an export, "37 of 100" beats a percentage, because the person doesn't have to work out what's left. The unit matters as much as the shape: bytes for a file, items for a batch, and neither when nothing is countable.
  2. When the total isn't known, use a spinner with no end state. A request where the server might answer at any moment belongs here.

The choice isn't a matter of taste; it follows from whether you can count the total. Use a bar without knowing it and you produce a screen sitting at 90 percent for a long stretch, which is worse than showing nothing. Once someone learns that this product's percentages can't be trusted, the bar stops buying you any patience at all.

What you attach depends on how long the wait runs.

  1. Under 0.1 seconds, show nothing. A spinner that flashes for one frame and vanishes just makes the screen look like it jumped.
  2. Under a second, let the button carry it. Dimming the pressed button and changing its label to "Saving" is enough to stop the double press.
  3. Between one and ten seconds, show a spinner or a bar.
  4. Past ten seconds, give the remaining count and a cancel control. Let the work continue when the person navigates away, and notify them when it finishes. The notification also means they can start the export and close the tab, which is usually what they wanted in the first place. Holding someone on one screen for more than ten seconds is itself the problem.

Three rules come with it. Numbers never go backward — drop from 60 percent to 40 and nobody believes the estimate again. Motion never stops; a bar frozen in one place for 30 seconds reads as a crash. And on failure, don't simply delete the bar: leave where it stopped visible, which turns a retry into a decision rather than a guess. If you print a time remaining, err long. Say 20 seconds and take 35 and nobody reads that number next time.

Not signalling by color alone belongs here too. It's an accessibility requirement: the progress value has to be exposed so a screen reader can announce it, or the bar carries nothing for people who can't see it.

Where it shows up

Four places take this part.

  1. Uploading and downloading files. The total is knowable, which makes this the clearest case for a bar.
  2. Processing many items at once. Exporting 200 documents, inviting 50 accounts. Showing counts lets you put how many failed in the same place. A batch reporting 198 of 200 with two failures tells someone what to retry; a spinner that simply ends does not.
  3. Pressing a button and waiting on the result. Save, submit, pay — usually around a second, so the button handles it. Anything materially longer than that belongs outside the button.
  4. Loading a screen for the first time. Here a skeleton UI, which shows gray placeholders where content will land, is often the better choice, because it says what will appear where. Cover the whole screen with one spinner and people wait without knowing what they're waiting for.

How it sounds at work

"This takes four minutes and all we show is a spinner. Can we show the remaining count?"

The total is knowable here, so it should be a bar.

"Don't invent a percentage. Leave it as a spinner."

A number made up without knowing the total costs more trust than it buys.

"We've got a ticket saying save got pressed twice because nothing responded."

The sub-second band is missing its treatment.

Pagedeck got this distinction wrong on document export and then fixed it. The first version showed only a spinner, and a customer exporting 200 documents waited four minutes. Eleven tickets came in, all saying the same thing: it looks stuck.

Noa switched it to a bar with the remaining count. Theo spent two days having the server report progress, and the same four minutes produced one ticket that month. The duration hadn't changed at all.

What people get wrong

The common belief is that adding the indicator fixes the slowness. Tickets drop, so it looks repaired. What dropped was anxiety; the duration is untouched. Four minutes still being four minutes means that customer quietly changes habits and exports once a day instead. The indicator buys attention rather than speed, and the two get confused because both arrive as fewer complaints. It keeps people from leaving while they wait. Making the wait shorter is separate work that still has to happen.

The other frequent belief is that showing a percentage is always better. A number feels like more information. But a percentage produced without knowing the total is invented. Walk it up through 30, 60, and 90 while waiting on a server and it sits at 90 for a minute. Anyone who has seen that screen once closes the tab the next time, bar or no bar. When you don't know, it's better to look like you don't know.

Easily confused with

TermWhat it displaysHow it differs from a progress indicator
StepperWhich of several steps you are onIt tracks steps a person walks through. A progress indicator tracks a machine working, and sits in the stretch where the user has nothing to do

Where to go next

  • UI component

    see which group this part belongs to and what sits beside it

  • Badge

    see another part from the same display group

Last updated 2026-09-16