top of page

Progress Indicators Ease the Wait

  • Writer: Jakob Nielsen
    Jakob Nielsen
  • 7 minutes ago
  • 13 min read
Summary: Show a progress indicator when response time exceeds 10 seconds, preferably as a percent-done bar. It tells users two things: the system heard you, and here’s how long the ordeal will last. But never let the bar stall, lie, or reset. AI agents that work for hours have raised the stakes: progress indicators must now serve users who walked away. Follow the 12 design guidelines in this article.

 

A percent-done indicator, rendered literally: Brad Myers built his 1985 prototype as exactly this, a capsule filling from left to right. The bird at the finish line stands in for every user who ever waited at 99%. (All images in this article made with GPT Image 2, except when noted)

 

Definition: A progress indicator is an interface element showing that a slow operation is underway and, ideally, how much of it remains. The canonical form is the percent-done progress bar: a horizontal track that fills from left to right in proportion to completed work. Its indeterminate cousins (spinners, throbbers, skeleton screens) confirm activity but stay mum on how much is left.

 

Users hate waiting, but they despise waiting of unknown length. A determinate bar converts open-ended anxiety into a bounded, plannable delay: the user can decide whether to watch, switch tasks, or fetch coffee.

 

Progress indicators are one of the oldest usability ideas. They still work.

 

This article climbs the full ladder of waiting: from the 0.3-second flash where any indicator does harm, through the 5-second spinner zone, up to AI agent jobs that outlast a feature film. The design rules change at every rung. Human psychology doesn’t.

 

From Charity Thermometers to CHI’85

The pattern predates computers. Karol Adamiecki charted production progress as horizontal bars in 1896; Henry Gantt popularized the technique (and collected the naming rights) around 1910–1915. Fundraising drives painted giant thermometers that filled toward a goal. So the name is plainspoken labeling for once: it’s a bar, and it shows progress. Would that all UI terminology were so easy to understand.

 

A giant thermometer that gradually fills up has a long history as a way of showing progress. Turn it 90 degrees, and you have a progress bar.

 

The decisive moment came in 1985, when then-graduate student Brad Myers presented percent-done progress indicators at the CHI conference. (Myers is now the Charles M. Geschke Director & Professor at Carnegie Mellon University. He has deservedly come up in the world after his pioneering student research.) Myers himself likened them to charity thermometers tipped on their side. His experiment asked 48 students to run computer searches with and without a bar: 86% preferred having the bar, even though it shortened nothing. People simply want to know.

 

Myers also touted a benefit that reads as prophecy 41 years later: a user who knows how long a job will take can decide to do something else in the meantime. In 1985, “something else” meant fetching coffee. Now, it means supervising 3 other AI agents. We’ll get there.

 

Why Feedback Beats Fretting

Visibility of system status ranks #1 among my 10 usability heuristics for good reason: a silent interface forces users to guess whether it’s working, crashed, or ignoring them. Progress indicators apply that heuristic to time.

 

The 3 response-time limits from my 1993 book Usability Engineering still govern. At 0.1 second, response feels instantaneous. At 1 second, users notice the delay but keep their flow. Past 10 seconds, attention wanders; show percent-done feedback or users assume death. (Robert B. Miller identified much the same breakpoints in 1968, in computing’s mainframe adolescence, so the advice is even older than my book.) These thresholds derive from human perception, not hardware. Thus, my 33-year-old advice hasn’t aged.

 

Hardware, meanwhile, has run the race in both directions. When I measured AI chat services in mid-2023, ChatGPT-4 averaged 41 seconds per answer: 4 times over the attention limit. Plain AI answers have since dropped to a few seconds, but reasoning models and agents push the other way, into minutes and hours. The wait that interactive computing spent 60 years shrinking is growing again. Hence this article.

 

Keeping users informed is a basic usability principle that also applies to response time delays.

 

The Psychology of the Queue: 4 Laws That Govern Waiting

1985 was a vintage year for waiting. The same year Myers showed his bars at CHI, David Maister published The Psychology of Waiting Lines (PDF), distilling queue research from banks and airports into principles that translate 1:1 to pixels. Of his principles, 4 do the most work for interface designers:

 

  • Occupied time feels shorter than unoccupied time. The classic story, retold by Maister: an office tower fielded endless complaints about slow elevators until management installed mirrors in the lobby. Complaints stopped. The elevators never sped up; people just liked looking at themselves.


Research found that a mirror by the elevator makes the wait less annoying.

 

  • Uncertain waits feel longer than known, finite waits. This single law explains most of the progress bar’s power: it converts an open-ended wait into a countdown.

  • Unexplained waits feel longer than explained waits. “Still working: your file has 48,000 rows” buys more patience than any animation.

  • Anxious waits feel longer than calm waits. A user wondering whether his or her credit card got charged twice experiences every second at double length. Say the money is safe.     


When users worry about what’s happening, the wait feels much worse. (Muse Image)

 

Behavioral scientists later added a twist worth stealing: the labor illusion. Ryan Buell and Michael Norton of Harvard Business School ran experiments with simulated travel-search sites (Management Science, 2011) and found that users rated a site that displayed its ongoing work (“now searching American Airlines… now Delta…”) as more valuable, and even preferred a slower site that showed its work over a faster one that hid it. Visible effort reads as value. Domino’s built its Pizza Tracker on this insight in 2008, and every ride-hailing app that shows your driver creeping across the map runs the same play. Honest transparency turns dead time into a small show.



The labor illusion: when you can see that a lot of effort goes into something, you mind the wait less.

 

The Feedback Ladder: Match the Indicator to the Delay

I think of the designer’s options as the feedback ladder: each rung of waiting demands one more rung of honesty about what’s happening.

 

The Feedback Ladder Delay User’s Mental State Correct Feedback Under 0.1 seconds Feels like direct manipulation None: the result is the feedback 0.1–1 second Notices the lag, keeps flow None, or a subtle transition 1–10 seconds Attention strains at the leash Spinner or skeleton screen, after about 1 second of grace 10 seconds–1 minute Attention lost; task-switching begins Percent-done bar, plus an honest time estimate 1–10 minutes User leaves the screen Persistent status that survives leave-and-return, plus interim results Over 10 minutes User is gone; supervision is episodic Step list, activity narration, interim artifacts, completion notification

 

The rest of this article climbs this feedback ladder, rung by rung.

 

The Zero-Indicator Zone: Below 1 Second, Show Nothing

 

The fastest progress indicator is the result. A spinner that flashes for 0.3 seconds informs nobody of anything; it adds visual noise, and the flicker makes the interface feel slower and twitchier than plain silence would. Two engineering defaults follow. First, show no indicator until roughly 1 second has passed: most operations will finish before earning one. Second, once an indicator appears, leave it up for at least half a second, so it reads as a state rather than a glitch.

 

The masters of the sub-second zone cheat, benevolently. Instagram’s early app started uploading a photo while the user was still fiddling with filters and captions; by the time he or she tapped Share, the upload was usually done, and the app felt supernaturally fast. (Cofounder Mike Krieger explains the trick in his 2011 talk Secrets to Lightning Fast Mobile Design, a slide deck.) The general pattern is optimistic UI: confirm the action instantly, do the work in the background, and quietly reconcile on the rare failure. The pattern is legitimate exactly when failures are rare and reversible, which is why a “like” never shows a spinner. Move the work into the user’s decision time, and the wait disappears without anybody lying.

 

1–10 Seconds: Spinners and Skeletons Show a Pulse, Not a Promise

An indeterminate indicator makes exactly one claim: the patient is alive. No amount, no rate, no arrival time. That claim suffices for waits of 2–10 seconds, where users mostly need reassurance that the click registered. But past 10 seconds, a spinner rots. Maister’s second law explains the decay: the wait is now both long and unbounded, the worst quadrant, and the spinning animation cheerfully confirms that nobody will tell you anything further.

 

Spinners also carry brand liability. Facebook’s designers reportedly found that when their iOS app showed a custom spinner, users blamed Facebook for the delay, but when the app showed the standard iOS spinner, users blamed the phone instead (the tale and its sourcing). A caveat: this finding reached the design community as a designer’s remark relayed in a 2013 tweet, not as a published study. I repeat it anyway because it matches attribution theory: the indicator’s styling tells users whom to blame.

 

Skeleton screens (gray placeholder blocks sketching the incoming layout) promised to do better, and the evidence on them is a lovely mess. Bill Chung intercepted passersby on Vancouver streets (80 participants completed his tests) and found skeletons produced the shortest perceived load times, with a slow left-to-right shimmer winning its head-to-head animation comparisons by 60–68%. Viget’s Kathryn Faulkner and Katherine Olvera ran a similar comparison with 136 mobile users and got the opposite: skeletons were perceived as slowest (2.82 seconds, vs. 2.41 for a spinner and 2.29 for a blank screen), and only 59% of skeleton viewers agreed the content loaded quickly, against 74% for the spinner crowd.

 

Both samples are small for a quant study, so don’t take the specific numbers too seriously. My reading of the conflict: a skeleton works when it honestly previews a familiar layout and resolves within about 3 seconds, because it then functions as Maister’s explained wait in graphical form. It backfires when the skeleton is novel enough to be studied as content in its own right, or when the placeholder shapes fail to match what finally arrives. A skeleton is a promise of specific content. Break the promise, and you’ve produced progress theater in bone form.

 

Above 10 Seconds: Percent-Done Is the Gold Standard, With Footnotes

Everything over 10 seconds demands determinate feedback, and here the research is unusually kind to designers: users prefer it, trust it, and plan around it. But “percent-done” hides three design decisions that separate good bars from stage props.

 

Footnote 1: percent of what? Count progress in user units. “Uploading photo 7 of 200” beats a bare 3.5% because the user can convert it into action (that’s dinner; I’ll come back). And when the total is unknowable, show the running count anyway: “Scanned 3,142 files so far” is a numerator without a denominator, yet it still beats a naked spinner, because it proves motion and hints at scale.

 

Explain the wait by updating a count of how much has been done, even if you can’t say how much more remains and thus can’t use a percent-done indicator.

 

Footnote 2: the time estimate. Estimates are the most user-friendly garnish and the most perishable. Windows file copies became folklore by seesawing between 2 minutes and 4 hours. So round aggressively (“about 2 minutes,” never “1:47”), and pad like an airline that wants repeat customers: finishing early delights, finishing late betrays. Revise the estimate downward as often as the data warrants, and upward as rarely as honesty allows, in one visible correction rather than a nervous flutter.

 

Footnote 3: the motion itself. Good bars even bend time. Chris Harrison and colleagues at Carnegie Mellon found that a bar with decelerating, backward-moving ribbing was perceived as 11% faster than a plain bar of identical duration. The same group’s earlier 2007 study found that users prefer bars that accelerate toward the end, and that they react most negatively of all to pauses and stalls. Perceived speed is a design variable, and cheaper than the real kind.

 

Is it ethical to make a wait merely feel shorter? My answer is yes, provided the data stays honest: easing real pain helps users; faking percentages abuses them. Which brings us to the frauds.

 

When the Bar Lies, Trust Dies

Every good pattern spawns counterfeits. Call it progress theater: animation that mimics measurement while measuring nothing. The bar that sprints to 99% and then squats there for 3 minutes, a purgatory with its own folklore. The bar that resets to zero, unexplained: Penelope’s shroud from The Odyssey, woven by day and unraveled by night, except Penelope had a reason. The installer whose “1 second remaining” lasts 5 minutes. And the eternal spinner, which reveals only that a GPU somewhere is heating the room.

 

In The Odyssey, Penelope was besieged by suitors while her husband, Odysseus, was lost at sea. To keep them at bay, she said that she needed to finish weaving a shroud before she could remarry. The deceit: every night, she unraveled the day’s work, meaning that the shroud was never finished. Don’t have your progress bar function this way.

 

Such designs are worse than no indicator: each broken promise teaches users to distrust the next. And remember that Harrison’s participants rated stalls the worst sin a bar can commit. (Fairness requires noting that Microsoft, whose copy dialogs I’ve mocked for 2 paragraphs now, shipped a genuine improvement in Windows 8: an optional live graph of actual transfer speed, honest wobble replacing confident fiction.)

 

It’s adding insult to injury to keep a progress indicator stuck at “1 second left” for more than that one second.

 

AI Agents Bring Back the Batch Job

Computing began with batch processing: submit your punched cards, come back tomorrow for the printout, and pray you didn’t drop a comma. Time-sharing, arriving around 1964, shrank the wait to seconds; the GUI era shrank it to milliseconds. The entire history of interactive computing is a war on waiting, and by the mid-2000s we had roughly won.

 

Then AI reintroduced the wait, at scale. A reasoning model chews for 30 seconds. Deep-research features run 5–30 minutes. Agentic coding tools toil for hours: METR’s task-horizon benchmark estimated that Claude Mythos 5 completed tasks that take human professionals a whopping 16 hours at a 50% success rate, with that horizon lately doubling every 3–4 months. We’ve reinvented the overnight batch job. Fortunately, this time the mainframe can send a push notification.

 

To soothe the wait while an AI agent goes to town, have it show its progress.

 

Agentic waits break the classic progress bar at its foundation: the denominator problem. Percent-done requires a known total, and open-ended knowledge work has none. An agent doesn’t know it’s 40% done with debugging any more than you do. Faking a percentage would be progress theater with extra steps, so don’t. Show these 5 things instead:

 

  1. The plan, as a live step list. “Step 3 of 7: cross-checking sources” is the agentic percent-done: bounded, honest, and revisable. But revise it visibly. A step list that silently grows from 7 steps to 11 is the new backward-moving bar.

  2. Activity narration in user units. “Reading quarterly-report.xlsx,” not “Executing tool call 47.” This deploys the labor illusion honestly: the work is real, so showing it builds both patience and trust.

  3. Interim artifacts. A partial draft, a preliminary table, the first 3 findings. Deliverables beat descriptions of deliverables, and anything inspectable early lets the user abort a doomed run after 4 minutes instead of 4 hours.

  4. Elapsed time, always; remaining time, only when honest. Wall-clock time is the one denominator-free number every agent can display without lying.

  5. A completion call. My working assumption: past 1 minute of waiting, the user is gone, and should be, because hovering over an agent wastes a human. The indicator must follow users out of the room (push notification, email, or badge), and the status display must survive leave-and-return without resetting.      


Design slow AI to allow users to step away while the army of AI agents does the work. In fact, assume that users won’t waste their time staring at the screen for several minutes. (Muse Image)

 

For tasks estimated to take more than a minute, offer a notification to call the user back after the task is complete.

 

Put differently, an agent’s progress display is an attention contract: the agent agrees to work unsupervised, the user agrees to return when called, and the display spells out the terms.

 

Fresh research backs the glanceable version of this contract. Chang and colleagues’ Sidekick system equipped computer-use agents with ambient status cues, soft sounds for state changes, and a spatial history for inspection; users supervised successfully while doing other work, with no added attention cost. The lesson: don’t trap agent progress in a scrolling transcript. Transcripts are for audits. Ambient cues are for monitoring. Interruptions are for the rare decisions that actually require a human.

 

Of course, progress theater has already mutated for the agentic age: fake “thinking” animations, padded reasoning streams, chirpy status lines (“Polishing pixels…”) that map to no actual work. One whimsical status line is charm. Whimsy as a substitute for information is the eternal spinner with a vocabulary. The old rule carries over unamended: tie the display to real measurements, or don’t display it.

 

Show users the real plan for long agentic AI runs, not a fake plan.

 

The honest version pays double, though. After the run, the same step list and activity log become the audit trail for verifying the agent’s work. Reassurance during, accountability after: one display, two jobs.

 

12 Design Guidelines for Progress Indicators

  1. Show nothing for sub-second waits. A spinner flashing for 0.3 seconds is visual noise that makes the system feel slower. Better yet, start work during the user’s decision time (optimistic UI) so there’s nothing to wait for.

  2. Use a spinner only for waits of 2–10 seconds. An indeterminate indicator proves the system is alive: enough for a short delay. Delay its onset by about 1 second so fast operations never flash one.

  3. Reserve skeleton screens for familiar, content-shaped loads of about 3 seconds or less. The placeholder must match the layout that actually arrives; a skeleton that misleads is worse than a spinner.

  4. Any wait over 10 seconds demands percent-done feedback. Add a time estimate whenever you can compute one honestly: rounded, slightly padded, and finishing early.

  5. Never let the bar move backward. A bar retreating from 80% to 20% breaks the one promise the widget makes. The same rule covers agents: never let a step list silently grow.

  6. Keep the bar moving. Smooth motion beats bursts; if work stalls, say why in words rather than freezing silently at 99%.

  7. Count progress in user units. Report photos uploaded or records imported, not subroutine milestones nobody asked about. No known total? Show the running count anyway.

  8. Tie the display to real measurements. Ribbing and terminal acceleration are legitimate garnish on honest data, never a substitute. This guideline covers AI “thinking” animations, too.

  9. Show step counts in multi-step flows. “Step 2 of 4” is a progress indicator too, working for the same reason: bounded waits are bearable.

  10. Explain long or unusual waits in one plain sentence. Unexplained waits feel longer, so “Comparing 48,000 rows” calms users more than the fanciest animation.

  11. For agent jobs, narrate the work and deliver interim artifacts. A live step list plus early partial results lets the user steer or abort a long run before the cost lands.

  12. When the wait outlasts attention, notify on completion. Past roughly 1 minute, assume the user has left, and rightly so. Push, email, or badge when the job finishes, and let the status page resume where he or she left off.


Conclusion: Free the Bird at the Finish Line

Waits won’t disappear: AI has made the 30-second operation common again and the 5-hour operation thinkable, so progress indicators matter more than ever. But the widget has acquired a second job. For 41 years, the progress bar kept a watching user calm. It must now let an absent user stay away with confidence, and know exactly when to call him or her back.

 

The charity thermometer worked because donors could watch the goal approach. Give users the same courtesy at every time scale, from the 2-second lookup to the overnight agent run, and they’ll grant you patience in return. An honest slow bar beats a lying fast one. And the best progress indicator of the agentic age is the one that taps you on the shoulder: all done, come see.

 

The bird at the top of this article has waited at the 99% mark since 1985. Design the wait honestly, and it finally crosses the line. (What’s your personal record for staring at 99%? Share it in the comments.)

 

For an entertaining spin on this topic, watch my music video about progress indicators on YouTube (2 min.).

 

How to deal with different response time delays.

 

 

Top Past Articles
bottom of page