Visibility of System Status
The interface should always tell the user what is going on, through timely and appropriate feedback.
Definition
The first of Jakob Nielsen's ten usability heuristics. Users need a continuously accurate picture of the system's state so they can decide what to do next, and every action needs a visible consequence within a reasonable time.
Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.
On this plate
Reach for this when
- Any action that takes longer than a frame.
- Any state that persists across screens.
- Any background process the user initiated.
Common mistakes
- Silent failures.
- Indicators that do not reach assistive technology.
- Optimistic UI with no visible rollback path.
- Announcing status only visually, so a screen reader user learns nothing about what just happened.
Three questions status has to answer
Where am I, what is happening right now, and did my action work. Almost every status failure is one of those three going unanswered.
Status is not only loading indicators. A selected navigation item, a saved indicator, an unread count, a connection state and a validation result are all system status.
Matching the indicator to the wait
| Situation | Right response |
|---|---|
| Instant local change | Change the state. No indicator. |
| Under 1 second network call | Optimistic update, or a disabled control. Delay any spinner by 200 to 400ms. |
| 1 to 10 seconds | Skeleton shaped like the result, or a determinate progress bar. |
| Over 10 seconds | Progress with an estimate, and a way to leave and be notified. |
| Background job | Persistent status surface the user can return to. |
| Failure | Inline message next to the cause, stating what happened and what to do. |
Do
- Mark the current location in navigation, with more than colour alone.
- Confirm saves explicitly, including autosaves.
- Surface offline and degraded states rather than failing silently.
- Announce dynamic status changes to assistive technology with a live region.
Do not
- Show a spinner for something that finishes in 150ms.
- Use a toast for a message the user needs to act on. Toasts vanish.
- Report success before the write has actually landed, unless you can roll back visibly.
- Leave a disabled button with no explanation of what would enable it.
States that are routinely left silent
Each of these is a moment where the system knows something the reader does not.
- Work saved, or not saved, after the reader stopped typing.
- A background sync that failed while the tab was in another window.
- A filter still applied from the previous visit, quietly changing what is shown.
- An action that succeeded for eleven of twelve selected rows.
- A session about to expire while a long form is open.
- Offline, with edits queued and no sign of it.
In practice
- i.
Autosave indicators
Document editorsA quiet 'Saved' with a timestamp, replaced briefly by 'Saving' during the write, removes the anxiety that drives compulsive manual saving. Silence reads as risk.
- ii.
Selected state in navigation
Web applicationsMarking the current section with weight and a rule, not just colour, answers 'where am I' for every user including those who cannot distinguish the colour.
- iii.
The empty list that was a filter
Silent stateA results page showed nothing and said nothing. A filter from the previous session was still applied, and the reader concluded the data had been deleted. The state existed, and only the system could see it.
Commonly confused with
Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.
Discoverability
PrincipleWhether a reader can work out what actions are possible and how to perform them.
Key difference
Visibility of system status is about what the product is doing right now. Discoverability is about what the reader could do next. One reports state, the other advertises possibility, and a perfectly honest status message does nothing for a feature nobody can find.
Use Visibility of System Status when
- Something happened, is happening, or failed, and nothing said so.
- The fix is feedback: a state, a message, a progress signal.
Use Discoverability when
- The capability exists and nobody uses it.
- The action is hidden behind hover, a gesture or an unlabelled icon.
- The fix is a signifier, a label or a better place to put it.
Local chart
HEUR·001 · Region I · Grid A2
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
10 Usability Heuristics for User Interface Design
J. Nielsen, Nielsen Norman Group, 1994, revised 2020
- [2]
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applied through
Where this shows up as a concrete interface decision.
- BreadcrumbCMP·020 · Component
- Progress IndicatorCMP·026 · Component
- ToastCMP·014 · Component
- CollaborationPAT·026 · Pattern
- Loading StatesPAT·011 · Pattern
- NotificationsPAT·015 · Pattern
- Optimistic UIPAT·013 · Pattern
- Skeleton ScreensPAT·012 · Pattern
- Heuristic EvaluationRES·002 · Research method
- MotionFND·052 · UI foundation
- Error MessagesWRT·002 · UX writing
Check your work
Review passes that test whether this was done properly.
- Dashboard UX ChecklistCHK·004 · Checklist
Related concept
Connected closely enough to change how you apply this.
- Status Messages and Live RegionsA11Y·009 · Accessibility
- Doherty ThresholdLAW·006 · Law
- FeedbackPRIN·004 · Principle
- Gulfs of Execution and EvaluationPRIN·010 · Principle