Visibility of System Status

No operable specimen yet; the illustration is editorial. A product must still verify that state changes are actually announced by assistive technology, that feedback latency in practice matches the interaction, and that any status wording shown corresponds to a result the system has genuinely verified.

{
  "evidenceType": "Usability heuristic and accessibility standard",
  "limit": "This entry constrains only whether and how status is communicated, not the pixels, duration, or actual performance of any concrete mechanism."
}

{
  "id": "visibility-of-system-status",
  "type": "principle",
  "name": {
    "zh": "系统状态可见性",
    "en": "Visibility of System Status"
  },
  "aliases": [
    "Nielsen Heuristic #1",
    "状态可见性",
    "可见性原则"
  ],
  "granularity": "experience",
  "intents": [
    "inform",
    "track-progress"
  ],
  "tags": [
    "feedback",
    "status",
    "usability heuristic",
    "accessibility",
    "response time"
  ],
  "definition": "A system should always keep users informed about what is going on, through appropriate feedback within a reasonable time; this is the first of Nielsen's ten usability heuristics.",
  "boundary": "This is a principle, not a concrete mechanism: the determinate progress bar, indeterminate progress, status message, and pressed-state feedback are all concrete realizations of it in different situations. It cares about whether state is communicated, not about how fast the system actually runs — being faster is a performance concern, outside this entry's scope.",
  "signature": [
    "Any operation with delay or an uncertain outcome has a corresponding status presentation",
    "Feedback arrives within a timeframe matched to that interaction, not after the person has already retried",
    "The status shown reflects a fact the system has verified, not an assumed outcome"
  ],
  "when": [
    "An action has delay, multiple steps, or an uncertain outcome, and people need to know whether the system received their input",
    "Choosing which concrete mechanism (progress bar, status message, pressed-state feedback, etc.) should represent the current status",
    "Evaluating whether an existing interface leaves people feeling disconnected or prompts repeated actions while waiting"
  ],
  "when_not": [
    "Treating this principle as a spec for one specific control's pixels or duration",
    "Using it to argue the system must be faster — it constrains whether communication happens, not performance metrics",
    "Stacking irrelevant status indicators just to satisfy visibility, creating visual and auditory noise"
  ],
  "tradeoff": "Continuously communicating status builds trust and reduces mistaken actions, but the status presentation itself takes up interface space and attention, and implementing and maintaining multiple kinds of status display adds cost.",
  "comparison": {
    "focus": "Whether people always know what the system is doing",
    "mechanism": "Communicating current status within a reasonable time through interface feedback, progress, messages, and similar means",
    "cost": "Requires designing and maintaining a presentation for each kind of status"
  },
  "sources": [
    {
      "id": "nng-ten-heuristics",
      "title": "NN/g · 10 Usability Heuristics for User Interface Design",
      "url": "https://www.nngroup.com/articles/ten-usability-heuristics/",
      "claim": "Lists \"visibility of system status\" as the first usability heuristic, stated as: the design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.nngroup.com/articles/ten-usability-heuristics/",
        "status": "available",
        "checkedAt": "2026-09-15T18:21:57.626Z",
        "jobId": "spn2-c214ca6ca65135f964d23731cb22d3701cb6d598",
        "url": "https://web.archive.org/web/20260915182252/https://www.nngroup.com/articles/ten-usability-heuristics/",
        "timestamp": "20260915182252"
      }
    },
    {
      "id": "nng-visibility-system-status",
      "title": "NN/g · Visibility of System Status (Usability Heuristic #1)",
      "url": "https://www.nngroup.com/articles/visibility-system-status/",
      "claim": "Elaborates on the heuristic: the better a system conveys its status, the better people understand the current situation, decide what to do next, and build trust in the system and the brand; the article emphasizes that immediate feedback helps people identify and correct errors quickly.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.nngroup.com/articles/visibility-system-status/",
        "status": "available",
        "checkedAt": "2026-09-16T03:50:48.236Z",
        "jobId": "spn2-2b8f64f0221fac8cb374582c6ce79b84f5e28f16",
        "url": "https://web.archive.org/web/20260916035119/https://www.nngroup.com/articles/visibility-system-status/",
        "timestamp": "20260916035119"
      }
    },
    {
      "id": "wcag22-status-messages",
      "title": "W3C · Understanding SC 4.1.3 Status Messages (WCAG 2.2)",
      "url": "https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html",
      "claim": "The Level AA criterion requires that status messages be programmatically determinable through role or properties so assistive technology can present them to users without receiving focus — a concrete accessibility requirement for status visibility.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html",
        "status": "pending",
        "checkedAt": "2026-09-15T18:35:44.910Z",
        "error": "status-request-failed",
        "jobId": "spn2-2f1c0e8f56c74acc0181032b2c86b53260ff4025"
      }
    }
  ],
  "relations": [
    {
      "target": "determinate-progress",
      "kind": "realized_by",
      "condition": "The system can provide a reliable completed amount and total",
      "reason": "The determinate progress bar is one concrete realization of this principle for quantifiable tasks.",
      "basis": "editorial"
    },
    {
      "target": "status-message",
      "kind": "realized_by",
      "condition": "An action's result or a non-blocking state change needs to be reported",
      "reason": "The status message is a concrete realization of this principle for outcome feedback.",
      "basis": "editorial"
    },
    {
      "target": "calm-technology",
      "kind": "related",
      "condition": "Deciding how prominent and how frequent status indicators should be",
      "reason": "Visibility requires that status be communicated; calm technology constrains how that communication should avoid seizing attention — together they shape the actual experience.",
      "basis": "editorial"
    },
    {
      "target": "error-prevention",
      "kind": "composes_with",
      "condition": "Before a person submits or performs an irreversible action",
      "reason": "Letting people see the current status is one precondition for preventing mistaken actions; the two often work together.",
      "basis": "editorial"
    }
  ],
  "rules": [
    {
      "when": "A state change is one people care about (such as a submission result, connection status, or processing progress)",
      "instruction": "Communicate the change in text that assistive technology can announce; do not rely on color or icons alone.",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "Designing when feedback arrives",
      "instruction": "Match the feedback's arrival time to the interaction itself; do not let people see it only after they have already retried or begun to suspect the system has failed.",
      "strength": "recommend",
      "basis": "editorial"
    },
    {
      "when": "Presenting wording such as \"saved\" or \"synced\"",
      "instruction": "Report only a state the system has actually verified; never show that wording before success is confirmed.",
      "strength": "must",
      "basis": "editorial"
    }
  ],
  "principle": {
    "evidenceType": "Usability heuristic and accessibility standard",
    "limit": "This entry constrains only whether and how status is communicated, not the pixels, duration, or actual performance of any concrete mechanism."
  },
  "demo": null,
  "version": "0.1.0",
  "editorialStatus": "drafted",
  "requirements": [],
  "demoCapabilities": [],
  "implementationNote": "No operable specimen yet; the illustration is editorial. A product must still verify that state changes are actually announced by assistive technology, that feedback latency in practice matches the interaction, and that any status wording shown corresponds to a result the system has genuinely verified.",
  "image": {
    "src": "/images/visibility-of-system-status.webp",
    "alt": "A fictional FIELDNOTES interface with a persistent small status strip at the top: a sync-state dot and a short text line on the left, a progress row below it, and the main content area intact and undisturbed."
  },
  "searchTerms": [
    "反馈",
    "状态",
    "可用性启发式",
    "无障碍",
    "响应时间"
  ]
}