For a progress indicator in a design system, what decides determinate versus indeterminate, and what goes wrong when a team fakes determinate progress?
answer
- what can you actually measure
- known total versus unknown total
- stalling at ninety-nine percent
- switch modes between phases
- count steps instead of inventing percent
basics
~20 sAn indicator is determinate only when the product can measure completed work against a known total; otherwise it is indeterminate. Faked percentages stall, jump or run backwards, and teach users to distrust every progress bar.
solid answer
~40 sA **determinate** indicator shows how much of the work is complete, so it needs a real numerator and denominator — bytes transferred, workouts synced, steps finished. An **indeterminate** indicator only shows that work is happening, and is the honest choice when the total or the rate is unknown. Faking determinate progress with a timer produces the familiar bar that races to 90% and then sits there, or jumps from 40% to done; users read the stall as a hang and cancel. The better pattern is to measure what can be measured and label the rest: in a fitness-tracker firmware update, show a determinate bar for the download, then switch to an indeterminate 'Installing on your watch' stage. When only a step count is known, say '3 of 5 steps' rather than inventing a percentage.
go deeper
Recall the definitions: determinate shows how much is done against a known total; indeterminate shows only that something is happening.
Explain the decision as what can be measured, and walk through the stall, jump and reset failures that come from driving a bar with a timer.
Design multi-phase progress honestly: measured phases, labelled unmeasurable stages, counts instead of invented percentages, and a clear failure state when work stops halfway.
Treat progress honesty as product-wide trust: one lying bar devalues every honest one, so the system's guidance should forbid percentages without a real measure behind them.
## Determinate and indeterminate, defined - A **determinate** progress indicator shows a **known fraction** of work complete. It needs two honest numbers: how much is done and how much there is in total. - An **indeterminate** progress indicator shows **activity without quantity**. It loops, pulses or sweeps, and says only that the request was received and is being worked on. The choice is not about how the indicator looks. A bar can be indeterminate (a sweeping band with no fill level) and a ring can be determinate (a circle that fills). The choice is about **what the product can measure**. The WAI-ARIA 1.2 specification draws the same line for assistive technologies: a progress bar role must have an accessible name, and when its current value is unknown — an indeterminate bar — the author omits the current value rather than reporting zero or a guess. ## What can honestly be measured | Situation | Measure available | Honest indicator | |---|---|---| | Uploading a workout file of known size | Bytes sent of total bytes | Determinate bar | | Syncing 40 sessions from a watch | Items done of total items | Determinate bar with a count | | Waiting for a server to compute weekly training load | Nothing until it answers | Indeterminate | | Installing firmware on the watch | Often only 'started' and 'finished' | Indeterminate stage with a label | | A known sequence of five stages of unequal length | Stage number, not time | Stepped indicator: '3 of 5' | ## Why faked progress backfires Teams fake determinate progress because a moving bar feels reassuring. The usual fake is a timer that advances the bar along a curve regardless of real work. The failure modes are predictable: 1. **The stall.** The timer reaches its ceiling — often 90 or 99% — before the work finishes, and the bar freezes. Users read a frozen bar as a hang and cancel or force-quit, which can interrupt a real transfer. 2. **The jump.** The work finishes early and the bar leaps from 40% to complete, which is harmless once but tells users the numbers mean nothing. 3. **Going backwards.** A retry or a phase change resets the bar, which reads as failure. 4. **Lost trust across the product.** Once users learn one bar lies, they discount every bar, including the honest ones. 5. **Misleading assistive technology.** A screen reader that announces '90 percent' for two minutes is announcing a false fact. Some teams deliberately **smooth** real progress — easing the animation between real updates, or weighting phases by their typical duration. That is a legitimate trade-off as long as the bar is still driven by real events and never claims more than is known; the defect is a percentage with nothing behind it. ## Honest patterns when progress is only partly known - **Switch modes between phases.** Measure the download determinately, then show an indeterminate, labelled installation stage. - **Count, do not estimate.** '12 of 40 workouts synced' is honest even when workouts vary in size; a percentage computed from it may not be. - **Label the stage.** 'Preparing', 'Uploading', 'Processing' tells the user what is happening even when no fraction is available. - **Offer a time estimate only when it is stable.** Estimates that swing wildly are worse than none. - **Never move backwards** within one operation; if a phase restarts, label it as a retry. - **Let long work run in the background** so the user is not held hostage by a bar they cannot influence. ## Worked example: firmware update on a fitness tracker The companion app downloads a firmware file of known size, transfers it to the watch, and then the watch installs it and restarts. The download and transfer are measurable in bytes; the installation is not observable from the phone at all. A good spec shows 'Downloading update — 45%', then 'Sending to your watch — 70%', then an indeterminate 'Installing on your watch, this can take a few minutes' with guidance not to move the watch away from the phone. A fake single bar stretched across all three phases would either stall during installation or jump at the end, and users would be tempted to interrupt exactly the step that must not be interrupted.
- If the total is known but items vary widely in size, is a percentage by item count honest?It is honest as a count but misleading as a time proxy: the bar can race through small workouts and then sit on one large session with a long route. Showing the count itself ('12 of 40 workouts') sets the right expectation. If a percentage is wanted, weight it by bytes or typical duration, which measures work rather than items.
- How should a progress indicator behave when the operation fails halfway?It should stop moving and change to a clear failure state with what happened and what the user can do — retry, resume, or leave it for later — rather than disappearing silently or resetting to zero. If completed items were kept, say so: '28 of 40 workouts synced; 12 will retry when your watch reconnects.'
saying these in an interview costs you the question
- Any progress bar is better than a spinner, even with invented numbers
- A bar that reaches 99% and waits there is fine
- Determinate versus indeterminate is decided by bar versus ring shape
- An unknown current value should be reported to assistive technology as zero
- Restarting the bar from zero on retry needs no explanation