Long tasks need progress rather than only a busy indicator

What it is

A busy indicator says only “the system is alive”; progress feedback says which stage is running, how much is complete, how much remains, and whether the user can cancel or do something else. Uploads, imports, rendering, batch jobs, and model tasks need stages, counts, or percentages once they outlast a brief wait, not only a spinner.

Why it happens

Progress maps invisible background work onto plannable time and action. Users use remaining quantity to decide whether to wait, switch tasks, return later, or cancel; named stages break a long task into comprehensible subgoals. A busy animation contains no time information, cannot distinguish a short stall from an endless wait after a few seconds, and invites suspicion that progress has regressed or the system has hung.

Where it stops holding

Not every task can be quantified accurately. A scan or model inference with unknown total should show stages, processed count, or activity, not a fabricated percentage. Progress is often nonlinear: a stage may slow abruptly, so remaining-time estimates should be cautious and updatable. Cancellation must clean up resources and explain what partial effects remain.

Applying it

• Divide long tasks into named stages such as upload, validate, convert, and write; show object counts or proportion per stage.
• When total work is known, show determinate progress and estimated remainder; when it is not, show processed/unknown total and last activity time.
• Provide minimize, continue in background, cancel, and failure recovery, plus a result entry after completion.
• Test with slow networks and large datasets to confirm updates, stable estimates, and whether cancellation truly stops processing.

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.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 · B3.01.7 Status should express progress and remaining work, not merely that the system is busy
• Nearby: B2.06 Feedback · I1 State, Time, and Response
• Search terms: progress indicator · long-running task · estimated time