Status should express progress and remaining work, not merely that the system is busy

What it is

Useful status answers “how much is done and what remains”: 12 of 80 records validated, three files awaiting upload, stage 2 of 5, or two failures awaiting retry. “Busy” leaves all decisions to the user; progress and remaining work make waiting plannable.

Why it happens

Decisions depend on remaining cost, not the mere existence of activity. Counts, stages, failures, and next steps support time estimation, attention allocation, cancellation order, and parallel work. Decomposition also aids diagnosis: if “78 remaining” does not change, users can infer a stall; if failed items are visible, they can fix the problem and retry the remainder.

Where it stops holding

Remaining quantity is accurate only when a unit can be defined. Search with unknown totals, steps dependent on external services, and dynamically generated tasks should show processed count, current stage, or queue position rather than a fabricated percentage. Progress also cannot hide order constraints: some remaining items are blocked while others can run in parallel, and the interface should explain why.

Applying it

• Express completed and remaining work in one unit—records, files, steps, or amount—rather than only an uncalibrated animation.
• Separate success, failure, skipped, and pending items, and provide retry for failures.
• Keep the last update time when estimates change; say “remaining unknown” when estimation is impossible.
• During acceptance, interrupt a task and check whether status shows completed work, remaining work, and affected objects.

Related

• Same group: B3.01.1 Users should always know what the system is doing · B3.01.2 Status feedback must appear within a reasonable time · B3.01.3 Long tasks need progress rather than only a busy indicator · B3.01.4 The test is whether users can always answer what the system is doing and where they are · B3.01.5 After waiting long enough, feedback must upgrade from a momentary cue to a persistent status presentation · B3.01.6 Background tasks also need visibility; leaving the current screen does not make the task disappear
• Nearby: B2.06 Feedback · I1 State, Time, and Response
• Search terms: progress semantics · remaining work · task status