Use determinate progress when the total work is known
Aliases: determinate progress · progress bar · known total · task completion
What it is
A determinate progress indicator represents completed work as a proportion of a known total, such as “42 of 100 files” or a bar filled to 42%. It is appropriate when the system can estimate a meaningful denominator and completed units are stable. Unlike an indeterminate spinner, it answers not only “is work continuing?” but also “how far along am I, what remains, and is waiting worthwhile?”
Why it happens
Waiting is uncertain when people cannot tell whether work advances, whether the remainder is acceptable, or what cancellation costs. A reliable proportion externalizes the background process, allowing attention planning and decisions to wait or move on. When a total is unknown, the denominator changes dramatically, or displayed progress does not track real completion, manufactured certainty is worse than a wait: people treat bar length as a promise and lose trust when it stalls or jumps.
Studying it
Compare spinners, determinate progress, and determinate progress with remaining estimates across task lengths and cancellation conditions. Measure experienced waiting, cancellation decisions, abandonment before completion, and trust, while logging deviation among actual units, estimated total, and displayed value. Long tasks should also reveal whether people switch work or return based on the indicator; that practical planning role distinguishes determinate information from decorative animation.
Where it stops holding
Known total does not mean equal unit duration. File size, network conditions, queuing, compression, and server stages mean halfway through units is not necessarily halfway through time, so proportion must not masquerade as an exact remaining-time promise. Very short tasks need no forced progress bar. Work that continually discovers new tasks or changes scope should disclose changing scope or use indeterminate/staged expression rather than freeze a false total.
Applying it
- Use determinate progress only with a stable denominator, expressed in units users understand.
- Bind value to actual work state rather than a fixed animation; when estimates change, update the scope or stage explicitly.
- Put cancellation consequence near a cancellable task, and offer background continuation or completion notice for longer tasks.
- Log display-versus-completion deviation across networks, task sizes, and retries. Long unexplained stalls, jumps, or a bar remaining after completion fail acceptance.