Design system states by distinguishing why content is absent or delayed, what the system knows, and what the person can do next. First-use, no-result, cleared, permission, loading, offline, partial, and failed states need different messages and actions. Preserve context and valid work, expose status accessibly, and test recovery rather than treating these states as leftover copy.
Who this is for: Product designers specifying workflows that must remain understandable before content arrives, during delay, and after failure.
- Model each state from its cause, available knowledge, customer consequence, and feasible next action.
- Communicate progress and status without inventing certainty, blocking unrelated work, or moving focus unexpectedly.
- Preserve input and context through partial failure, retry, offline return, and support escalation.
Name distinct conditions
An empty collection may mean first use, no search results, a cleared history, missing permission, unavailable data, or a genuine zero. Each condition answers a different question. Specify detection logic and content separately so the interface does not invite creation when the person actually lacks access.
Map states for every important data dependency and action: initial, loading, success, stale, partial, offline, recoverable error, terminal error, and return after interruption. Include what remains usable. A failed sidebar request should not necessarily replace a valid main workspace with a full-page failure.
Communicate waiting honestly
Show immediate acknowledgement after an action and describe progress only when the system has meaningful progress information. A determinate indicator needs a defensible measure; otherwise use an indeterminate treatment and useful status language. Avoid fake percentages or countdowns that teach people not to trust system feedback.
Preserve layout where practical so late content does not cause disruptive movement, and allow cancellation when the operation can stop safely. For longer work, explain whether it continues after navigation and how completion will be communicated. Do not trap focus inside a loading surface unless the whole interaction truly cannot proceed.
Design recovery and partial success
Explain what failed, what succeeded, whether data was saved, and what action is available. Keep valid input and selected context. For batch operations, identify affected items instead of reporting one vague failure. Retry must be safe against duplicate actions, and destructive rollback needs clear ownership and confirmation.
Offer support when self-recovery is not feasible, carrying an appropriate reference without exposing sensitive internals. If the cause is unknown, avoid blaming connectivity or the person. State the observable condition and next safe choice. Log technical detail separately for diagnosis rather than placing it in customer-facing copy.
Make status perceivable
Use text and structure in addition to color or animation. Apply WCAG 2.2 criterion 4.1.3 when a status message should be programmatically determined without receiving focus, and manage focus when the next task genuinely requires movement. Avoid repeatedly announcing animated loading text to screen-reader users.
Test slow, failed, empty, stale, offline, partial, canceled, and recovered paths with realistic content. Verify keyboard, screen reader, zoom, reduced motion, refresh, back navigation, and duplicate submission. Monitor failure and retry evidence after release, then investigate whether repeated recovery indicates a deeper workflow problem.
Handle a hypothetical batch upload
Hypothetical scenario: a user uploads ten sample records and three fail server validation.
- Acknowledge the hypothetical batch, preserve the page, and show indeterminate progress because reliable completion percentage is unavailable.
- Report that seven hypothetical records succeeded and identify the three failed sample rows with specific reasons.
- Offer correction and safe retry for failed rows only, while preventing duplicate creation of successful rows.
- Expose the completion status programmatically and verify recovery with keyboard and screen-reader testing.
System-state matrix
Specify state logic, presentation, action, and access behavior together.
- Condition, trigger, data known, content available, customer consequence, and detection ownership.
- First use, zero, no result, permission, loading, stale, partial, offline, canceled, and failure variants.
- Message, visual treatment, progress basis, primary action, alternative, preserved context, and support path.
- Focus behavior, status announcement, color-independent cue, motion, keyboard, zoom, and screen-reader check.
- Retry safety, duplicate prevention, rollback, logging, monitoring, owner, and post-release evidence.
Common mistakes
- Using one generic empty state for first use, no results, missing permission, and service failure.
- Displaying invented progress percentages when the system cannot measure completed work reliably.
- Clearing valid input after a recoverable failure and making the person reconstruct the entire task.
Try one
A search returns no results because filters exclude every item. What should the state communicate?
A strong design says that no items match the current query and filters, keeps both visible, and offers a clear way to revise or clear them. It should not present first-use onboarding or imply the collection is empty. Focus and result status should be handled intentionally, and the team should test keyboard and screen-reader access to the active filters and recovery action.
Sources
- Nielsen Norman Group system status guidanceGuidance on communicating what a system is doing and what has changed.
- Nielsen Norman Group empty-state guidanceGuidance on distinguishing first-use, no-result, cleared, and unavailable empty states.
- W3C WCAG 2.2 status messages criterionCriterion 4.1.3 guidance for exposing status messages without moving focus unnecessarily.