011 min
Visibility of System Status and the silent button
Picture a shopper on a phone who has filled a cart and taps Pay. This is an illustrative case. The button looks the same as before, and nothing else on the screen changes. The shopper cannot tell whether the tap counted, whether the payment is running, or whether it failed. After a moment, the shopper taps Pay a second time, and then a third time. If the payment service is slow, the order may be sent twice.
The Nielsen Norman Group, a UX research firm, recorded the same doubt in a real session. In its mobile eyetracking study, a user pressed a button and could not tell whether a page was loading, because the screen gave no feedback. She glanced repeatedly from the button to the area where browsers usually show page-load progress, checking whether anything had started.
In both cases the system knew its own state and the screen did not show it. The first of the usability heuristics is about exactly this problem.
021 min
Where Visibility of System Status comes from
Jakob Nielsen and Rolf Molich published a first list of usability heuristics in 1990. A heuristic here is a rule of thumb that a reviewer uses to inspect an interface, and heuristic evaluation is the method built on such lists.
The 1994 revision
Four years later, Nielsen revised the list using a factor analysis of 249 usability problems. The method shows which rules explain the most problems, and Nielsen used the result to build the set of ten heuristics that is still in use.
Visibility of system status is the first of the ten. The current Nielsen Norman Group text says the design should "always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time."
This makes it a practitioner's rule of thumb, not a measured law. Nielsen built it from observed problems, not from a lab experiment on one quantity. The numbers behind it, such as how long a wait can last before people need a sign of progress, come from separate research. The next section explains what the heuristic asks for, and those numbers follow.
032 min
How Visibility of System Status works
Visibility of system status asks one thing of an interface: let people know what it is doing right now. The Nielsen Norman Group's Aurora Harley explains why, using Donald Norman's term gulf of evaluation. That is the distance between what a system shows and what a person must know to decide the next step. Harley's example is a driver whose speedometer is broken. The driver cannot tell whether to speed up or slow down, and has to trust that the other cars are going at a sensible speed. Her summary is that a lack of information often means a lack of control.
A person who acts on a system wants four answers, usually in this order:
- Did the system register my action?
- Is it working on it?
- How long will it take?
- Did it succeed, and what happened?
The heuristic covers all four. Feedback is appropriate when it answers the question the person has at that moment, in a place they look, in words or signs they understand. Feedback is on time when it arrives within the delay people will accept. The next part puts numbers on that delay.
How long is a reasonable time
Nielsen's article on response times lists three limits. He takes them from Robert Miller's 1968 paper and from work by Card and colleagues in 1991.
| Delay | What the person experiences | What the system owes |
|---|---|---|
| About 0.1 second | The system seems to react instantly. | Only the result itself. |
| About 1 second | The person keeps thinking about the task without a break, but notices the wait. | Usually nothing extra, though the sense of working directly on the data is lost. |
| About 10 seconds | This is the limit for keeping attention on the task. | A sign of when the work will end, as the next paragraph explains. |
Past about 10 seconds, people start other tasks, so the system should tell them when it expects to finish.
Engineers measure these delays as latency. The Doherty Threshold is a related finding about how response speed affects the amount of work people finish. Status adds a design question to the engineering one: while the system is slower than the person wants, what does the screen say?
042 min
Visibility of System Status in real products
Good status design shows up in small places. Amazon's Echo speaker has no screen, so it lights a ring on the device while it listens or works on a command. The Nielsen Norman Group notes that an on-off light is weaker than a running timer, but it still tells the person that the command was heard.
A screen can also make the system's state visible by letting people act on it directly. In the Amazon Music app on iOS, a person drags songs to reorder a playlist and sees the new order at once, so a slip is easy to notice and correct. Command-line interfaces do the opposite. They show no current state and give no immediate feedback, so programmers use tools such as breakpoints to find which command caused an error. Harley argues that the real difference between those old interfaces and modern ones is not colorful icons but this heuristic.
Not every internal state belongs on screen. The same article says that downloaded script files are of no interest to shoppers, and that stock levels are usually irrelevant too. It names two exceptions, where the state changes a decision. When stock is low, shoppers are likelier to act at once. When an item is out of stock, they are spared the effort of trying to add it. In 2018 the article showed J.Crew's product page labelling low-stock sizes "Only a Few Left!" and crossing out sold-out sizes. Distance from a reward is another useful state: NatureBox showed a banner at the top of the page with the amount a shopper still needed to spend to qualify for free shipping.
Those cases show a status that is present and true. The case in the next section shows what happens when a status is present and wrong.
051 min
Visibility of System Status at Three Mile Island
The most serious known case of a misleading status is not a website. On March 28, 1979, a valve in the primary system of the Three Mile Island Unit 2 nuclear plant in Pennsylvania opened to lower the pressure in the reactor's coolant circuit. The valve should have closed once pressure fell, but it stuck open. According to the U.S. Nuclear Regulatory Commission, control-room instruments showed the valve as closed while it was stuck open. The staff therefore did not know that cooling water, as steam, was pouring out of the open valve. Alarms rang and warning lights flashed, yet the operators had not understood that coolant was being lost.
This was not a missing display. The control room had instruments, and the staff read them as true. Their mental model of the plant came from those instruments, so a false reading produced a false picture. Visibility of system status therefore asks for two things: show the state, and show the state that is real. People who see a confident display of the wrong state have no reason to look for another source.
062 min
How Visibility of System Status changes a wait
Seeing the status changes more than what people know. It changes how long a wait feels, and three pieces of research show how.
A wait with no known end
David Maister, a writer on service businesses, set out rules for how people experience waiting lines. Two bear on screens. Waits with no known end feel longer than waits with one, and waits with no explanation feel longer than explained waits. Maister describes a client who waits calmly for an appointment until the scheduled time passes, then grows annoyed within minutes. For the second rule he describes airline announcements that name the cause of a delay, such as fog or a safety check.
What a progress bar does to patience
A progress indicator gives a wait both an end and a reason. In a 2004 study by Nah, web users who saw a moving progress bar were willing to wait about three times longer on average than users who saw no indicator. The Nielsen Norman Group, which reports the study, adds that those users also reported higher satisfaction. The test took place at the University of Nebraska-Lincoln.
The look of the bar
The design of the indicator matters as well. In 2010 Chris Harrison, Zhiquan Yeo and Scott Hudson of Carnegie Mellon University tested progress bars with ribbed stripes that moved backwards and slowed down. Participants judged a wait shown with a backward-moving, slowing ribbed bar to be 11% shorter than the same wait shown with a standard solid bar. The real duration was the same. Treat this as evidence about perception, not as a way to hide a slow system.
072 min
Applying Visibility of System Status
Those findings turn into a short set of habits.
Acknowledge each action at once.
Change the control's look the moment it is pressed, for example with a new color and a checkmark. The person then knows the system registered the choice, and does not tap the same button again out of doubt.
Pick the indicator by the length of the wait.
Nielsen Norman Group advises a looped animation for waits of 2 to 9 seconds, and a percent-done bar once the wait reaches 10 seconds. Above 10 seconds, add an estimate of when the work will finish.
Show background state only when it changes a decision,
as with low stock or the distance to free shipping.
Name failures.
When something goes wrong, say what failed and what the person can do next. A failure is a status like any other.
Make the message reach screen readers.
The next section explains how.
Skeleton screens: when they fit
A skeleton screen is a gray outline of the page layout, shown while the content loads. The Nielsen Norman Group says it suits full-page loads of up to about 10 seconds, because it makes the page seem to be arriving and tells users the site is working. For a page that loads in under 1 second, a skeleton screen or spinner is unnecessary, and its quick flash can annoy users. It is also a poor fit for work that is not a page, such as downloads, uploads and file conversions. For waits beyond 10 seconds, the same source recommends a progress bar with an explicit estimate.
081 min
Visibility of System Status for screen readers
A change that sighted users see, such as a count of search results or a saved message, is invisible to someone using a screen reader unless the page announces it. WCAG 2.2 Success Criterion 4.1.3, Status Messages (Level AA), requires that the code mark up each status message with a role or property, so a screen reader can read it aloud without moving the user’s focus.
The W3C's guidance defines a status message as information about the success or results of an action, the waiting state of an application, the progress of a process, or the existence of errors. The message must also arrive without a change of context, which would take focus and interrupt the person. Its examples include a screen reader announcing five results returned, a shopping cart updating to five items, an invalid entry in a form field, and an application that is busy. The criterion mainly helps blind and low-vision users who rely on screen readers.
091 min
When Visibility of System Status backfires
More status is not always better. These are the common ways the heuristic is misapplied.
Showing everything
The heuristic asks for appropriate feedback, not all feedback. Most backstage steps, such as which script files are downloading, are of no interest to users, and showing them makes the screen harder to read.
A bar that stalls
A percent-done bar costs trust when it misreports. The Nielsen Norman Group warns that if a bar moves quickly and then hangs on the last percent, users become frustrated and the benefit of showing progress is lost. The same article advises against trying to be exact, since an exact figure will eventually be wrong and the site's credibility suffers.
Indicators that say too little
Static indicators, with no motion or change, give too little information about what is happening, and the Nielsen Norman Group advises replacing them. It also advises against warnings that tell users not to click again, because users do not read long warnings before they click.
101 min
Visibility of System Status vs. nearby concepts
Three neighbours are easy to mix up with visibility of system status. The one axis that separates them is what each answers and when.
| Concept | Question it answers | Moment |
|---|---|---|
| Not in the library yetVisibility of system status | ||
| DesignSignifiers | ||
| DesignDoherty Threshold | ||
| DesignHeuristic evaluation |
A signifier tells a person that a control can be pressed. Status tells them that the press was received. A fast system can still fail this heuristic if it responds without any visible sign, and a slow system can pass it if the screen says what is happening.
111 min
How to spot missing Visibility of System Status
An audit can find missing status without a lab. Look for these signs:
- The same order, message or form arriving twice a few seconds apart in the logs.
- Support tickets that ask whether a payment, upload or save worked.
- Session recordings that show repeated taps on one control, followed by a pause.
- A user who looks back and forth between a control and the place where progress would appear, as in the eyetracking session above.
- An action that takes longer than a second with no visible change on the screen. Time it from the press.
- A drop-off at a step that is also the slowest step.
In a heuristic evaluation, press every control once and write down each one where nothing visible changes within a second. Those are the places to fix first.
?5 questions
Questions people ask
Is visibility of system status only about loading screens?
What should an error message say under this heuristic?
How do I show the status of background work such as syncing?
Does the heuristic apply to chat or voice products?
Can it apply to physical products?
§9 sources
Sources for Visibility of System Status
Harley, A. (2018). Visibility of System Status (Usability Heuristic #1). Nielsen Norman Group.
Nielsen, J. (1994, updated 2020; reviewed 2024). 10 Usability Heuristics for User Interface Design. Nielsen Norman Group.
Nielsen, J. Response Times: The 3 Important Limits. Nielsen Norman Group, drawing on Miller (1968) and Card et al. (1991).
Nielsen Norman Group. Progress Indicators Make a Slow System Less Insufferable, which reports Nah (2004).
Show all 9 sourcesShow fewer sources
Nielsen Norman Group. Skeleton Screens 101, which cites Mejtoft, Långström and Söderström (2018).
Harrison, C., Yeo, Z., and Hudson, S. E. (2010). Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations. CHI 2010.
Maister, D. The Psychology of Waiting Lines.
U.S. Nuclear Regulatory Commission. Backgrounder on the Three Mile Island Accident.
W3C. Understanding Success Criterion 4.1.3: Status Messages (WCAG 2.2).