Progress must not reverse or remain stalled for long
Aliases: progress stall · progress reversal · monotonic progress · progress trust
What it is
Progress monotonicity means user-facing progress continues toward completion. When re-estimation, retry, or a slow phase is unavoidable, it must not visibly reverse or remain still for a long time without explanation. A progress bar is a commitment users use to predict waiting, not a raw background counter. Moving backward suggests completed work was lost; a long stall leaves people unable to tell work from disconnection or a frozen interface.
Why it happens
People infer remaining time and system health from change rate, treating near-completion stalls as failure or deception. Technical work is nonlinear: newly discovered work, validation, retries, upload finalization, and server queuing alter estimates. Directly exposing internal percentages creates backward jumps and “99% forever.” Monotonic expression uses smoothing, stages, conservative estimation, or explanation to translate complexity into an intelligible wait rather than promising a linear path it cannot keep.
Studying it
Log real events and displayed trajectories under networks, retries, cache misses, large files, and long-tail server stages. Measure when people judge a task dead, repeat action, or cancel. Compare reversal, freezing, stage explanation, and slow continued advance for trust, waiting decisions, and recovery. Mean completion time hides the important tail: a few tasks stalled near the end can determine trust more than many smooth short ones.
Where it stops holding
Monotonic does not mean fake constant speed. Infinitely slowing a bar to avoid reversal, or hiding errors behind stillness, also misleads. If scope truly changes or completed work must be redone, explain the event, impact, and choices; if no progress remains, report failure or offer retry. A short action need not display a bar that cannot visibly advance.
Applying it
- Map internal states to intelligible stages and conservative progress; do not expose reversible temporary estimates as completed proportion.
- Explain retries, scope growth, and slow finalization, with diagnosis, cancellation, or retry after a reasonable wait threshold.
- Monitor near-completion long tails separately, validating consistency among bar, stage, and real events rather than relying on global averages.
- Ask testers “what is the system doing, and would you wait or retry?” Inability to answer or a belief that it froze calls for better state explanation, not just more animation.