Users should always know what the system is doing

What it is

Visibility of system status requires the interface to show the current object, stage, input acceptance, success or failure, and available next step. It is not merely an error message; it lets users maintain a continuous model of “what I did and what the system is doing with it.”

Why it happens

Actions create expectations, and feedback confirms or revises them. Without status, users cannot distinguish submitted, processing, failed, disconnected, or mis-tapped; they wait, repeat the action, or leave. Visible state turns internal events into interpretable evidence, reducing uncertainty and duplicate input while supporting recovery.

Studying it

Observe operation-feedback gaps on critical paths and record guesses, repeated input, abandonment, and help seeking during feedback gaps. Manipulate feedback presence, location, explicitness, and delay; measure confirmation time, duplicate operations, recovery time, trust, and situation-awareness ratings. The test is whether users can state the current status, not whether the interface technically changed.

Where it stops holding

Not every state must be visible at once. Persistent indicators compete for attention, and a brief action usually needs only lightweight confirmation. Status also cannot replace explanation and recovery; a “loading” state with no cancel, retry, or reason still fails the usability requirement.

Applying it

• Define three feedback phases for each input—received, processing, and completed or failed—and include a next step after failure.
• Keep the current object, mode, save state, and permission visible in the work area rather than relying on memory.
• Audit screen recordings of critical tasks; mark every segment where users cannot answer “what is the system doing?” after one second, and repair those gaps.

Related

• Same group: 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 · 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: system status · feedback · situation awareness