Usability Heuristics
Visibility of System Status
Always tell users what's happening, with clear feedback delivered in good time.
Where it comes from
It's the first of the ten usability heuristics Jakob Nielsen published in 1994, refined from a set he developed with Rolf Molich a few years earlier — a distillation of the patterns that recurred across hundreds of interface evaluations.
Why it matters for your website
Users need to know what's going on. Nielsen Norman Group's first usability heuristic says a system should always keep people informed about its status. Without feedback, users repeat actions, abandon flows, or lose confidence that anything worked.
The cost of poor status feedback is rarely dramatic; it's a steady drip of small confusions. A button that gives no sign it was pressed gets pressed again. A form that submits silently leaves people wondering if it worked. An upload with no progress bar feels broken the moment it takes longer than expected — even when nothing is wrong.
Good status feedback is mostly about timing and proportion. A response should be immediate, and its prominence should match the importance of the event: a subtle change for a routine action, an unmissable one for something that matters, like a payment going through or a file being deleted. Get the proportion wrong and you either nag people over trivia or let critical changes slip by unseen.
Wrong vs right
A 'Save' button that does nothing visible when clicked — no spinner, no confirmation — so the user can't tell whether the save happened and clicks again.
The button shows a brief loading state, then a clear 'Saved' confirmation. The user knows the action completed and moves on.
A multi-step checkout that gives no indication of how many steps remain, so each click is a step into the unknown.
A progress indicator showing 'Step 2 of 3', so the user always knows where they are and how much is left.
A file upload with no progress feedback — the screen sits still, and the user assumes it has frozen and abandons it.
A progress bar or percentage that moves, signalling the system is working and roughly how long is left.
Understanding Visibility of System Status
Visibility of system status is the principle that an interface should always tell the user what is going on. Every action a person takes is an implicit question — did that work? — and the system's job is to answer it, clearly and quickly. When it doesn't, people fill the silence with their own assumptions, and those assumptions are usually pessimistic: it's broken, I did it wrong, nothing happened.
Feedback operates across timescales. Instant responses (a button depressing, a field highlighting) confirm an input registered. Short waits need a busy indicator so the pause reads as 'working', not 'frozen'. Longer processes need progress — a bar, a percentage, an estimate — because an unknown wait is far more stressful than a known one. And state changes the user didn't initiate, like a dropped connection or an expiring session, need surfacing too, or people act on a picture of the system that's no longer true.
The discipline is in matching the feedback to the event without overdoing it. An interface that shouts about everything is as unusable as one that says nothing, because it trains people to ignore the noise — and then they miss the message that mattered. The principle pairs naturally with Norman's idea of feedback and with designing for closure: every action should have a visible, satisfying end.
How Kweri checks it
Kweri can detect some status-feedback issues from the page itself — for example, actions and forms that appear to give no visible response, or long-running interactions without an obvious loading or progress indicator. But much of this heuristic only reveals itself in motion, over time, and in edge cases a static review can't fully exercise: what happens during a slow network, after a timeout, or when a background process changes state. So Kweri points out where feedback looks absent or weak, and is honest that fully verifying system status means testing the live, interactive flows under real conditions.
FAQ
What is visibility of system status?
It's the usability principle — the first of Jakob Nielsen's ten heuristics — that a system should always keep users informed about what's happening through clear, timely feedback, so they're never left guessing whether an action worked.
Why is system status feedback important?
Because without it, people can't tell if their actions succeeded. That uncertainty leads to repeated clicks, abandoned forms, and lost trust. Clear feedback lets users move forward with confidence instead of second-guessing the interface.
What are examples of system status feedback?
Loading spinners, progress bars, 'Saved' confirmations, step indicators in a checkout, unread counts, and error or success messages. Anything that tells the user what the system is doing or has just done.
How quickly should an interface respond?
Acknowledgement should feel immediate — ideally within about a tenth of a second for direct actions. Longer operations should show a busy or progress indicator within roughly a second, so a wait never reads as a freeze.
Can you give too much feedback?
Yes. An interface that announces every trivial change trains people to tune it out, so they then miss the important alerts. Feedback should be proportional — subtle for routine actions, prominent for consequential ones.
How does this relate to Nielsen's other heuristics?
It's the first of the ten and underpins several others. It connects closely to error recovery (telling users when something went wrong), user control (showing the current state so people can act on it), and designing for closure (giving every action a clear end).
Related principles
Every action should produce an immediate, clear response confirming it registered.
Every sequence of actions must have a clearly defined end state that tells users the task is complete — open-ended sequences create anxiety and uncertainty.
Every interaction has two potential failure points: the gulf of execution (user can't figure out how to do what they want) and the gulf of evaluation (user can't tell whether what happened was what they intended).
People miss changes that happen outside their current focus of attention.
Attribution & sources
Identified by Jakob Nielsen (1994). Catalogued from Nielsen Norman Group — Visibility of System Status.
The first of Nielsen's 10 Usability Heuristics, originally developed with Rolf Molich and refined in 1994.
See Visibility of System Status on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →