Progress must be monotonic and must not run backwards

What it is

Monotonic progress means completed work only grows: the bar only advances, the percent does not jump back, step 4 of 5 does not become 2 of 5. Progress is external memory for “work is accumulating”. Running backwards tells people that the accumulation they just banked has been voided, and the wait model has to be rebuilt. The first condition of predictability is not a good estimate. It is that the road already walked is not taken back.

Why it happens

People treat a progress bar as an irreversible path. At 60% they write 60% into their forecast for this job: at least that much is done. Pulling the bar back falsifies the forecast in a special way — not “slower than I thought”, but “the stretch I thought was finished was not”. That kind of falsification hurts more, because it breaks the direction of the work, not only the speed. Speed can be updated; a reversed direction makes people doubt the unit, doubt whether the job was restarted, doubt whether the UI is performing.

The usual engineering source is a changing denominator: more files found inside an archive, the server appending a batch, a retry zeroing the counter, a parallel failure causing total progress to be recomputed on the failed branch. The numerator did not shrink; the denominator grew; the ratio still drops. To the user a drop is a reversal — they will not separate “total corrected” from “work erased”. The other source is driving the percent from instantaneous rate; when rate jitters the bar wobbles, and any wobble past a previous high is a small reversal.

Where it stops holding

If the user cancels and starts again, a zero is not a reversal — it is a new job — but the old job must be visibly finished. A step that must be redone after a validation failure (upload finished, format rejected, pick a file again) should be a new progress instance, not a hollowed-out segment on the same bar. When the total is discovered late and the denominator must change, it is more predictable to freeze the bar and change the copy to “more items found” than to jump back with no note — a freeze is a stall, which needs a stage; a jump-back is a broken promise. Game loads and video buffers may reset when the user seeks; that is the person changing the job’s scope, not the system taking back road already walked.

Applying it

• Represent progress as “completed / current total”, and allow the total only to grow or hold. The ratio then cannot fall below a previous high just because more work was discovered.
• Retries, file replacements and cancel-and-restart open a new bar. Mark the old one finished; do not pour progress backwards on the same bar.
• Do not drive the percent from instantaneous rate. Drive it from real completed units (bytes, records, steps).
• How to check: mid-upload, append files, or have the server double the total at 40%. The bar must not run backwards. If the total must change, freeze on the current numerator and show a sentence — do not jump from 40% to 20%.

Related

• Same group: I2.02.2 A long stall needs a stage explanation · I2.02.3 Inaccurate remaining-time estimates damage trust
• Nearby: E6.09 Determinate and indeterminate progress · I2.10 Remaining-time estimates · I2.01 Choosing skeleton versus spinner
• Search terms: monotonic progress · progress bar regression · percent-done