Interface Lab
Login
Back to knowledge
Interaction Responsive Motion

Empty State Recovery Contract

Empty states should explain system status and cause before offering an action that resolves that cause, instead of filling silence with illustration.

empty-staterecoverysystem-statusfrontend-state

Design Principle

An empty state is completed system feedback: users need to know why content is absent, whether the request has finished, what they can do, and whether access, configuration, retry, or waiting is required.

Large Theory

An empty state is not one visual component; it is a family of causes: first-use no data, user-cleared completion, no search results, filters excluding everything, missing permission, missing configuration, unavailable source, backend failure, offline mode, or an index that is not ready. Each cause needs different copy, actions, and rendering conditions. Calling all of them No data prevents users from knowing whether the system is still loading, failed, blocked by permissions, or ready for their next action.

Small Points

  1. Separate loading, empty, and error first: do not show no-results before the request completes, and do not classify hidden-but-existing data as no-data.
  1. Search empty reflects the query and suggests changing terms, clearing search, or viewing neighboring categories; filtered empty exposes active filters and reset path.
  1. Permission empty states name the access needed, who can grant it, and whether the user can safely leave; do not only say Access denied.
  1. Configuration required states name the missing connection, setting, or prerequisite and provide the first setup action.
  1. Backend or source failures use plain language and provide safe retry, status, log, or support paths.
  1. Completed or cleared empty states are success feedback; confirm completion and suggest the next useful place to continue.

Design Judgment

An empty state works when users can answer four questions: what normally appears here, why it is absent now, whether the current request has finished, and which next step is most useful. A blank panel, generic illustration, or vague No data message is not a recoverable state.

Implementation Notes

Create an EmptyReason enum such as no-data, search-empty, filtered-empty, permission, configuration, source-unavailable, backend-error, offline, index-not-ready, and complete. Render empty only after completed fetch/search state, such as status === "success" && items.length === 0; keep error and retry in a separate branch. The model should include title, body, primaryAction, secondaryAction, and details(query/filters/source/timestamp/owner/retryAfter). Search and filter views keep result count, query, active chips, and reset action near the empty message. For empty tables, avoid leaving meaningless headers, pagination, and bulk controls that screen readers encounter before the useful message.

Counterexamples/Risks

No records appears while content is still loading; a no-access state still offers create buttons; filtered-empty has no reset; backend failure is disguised as no data; empty tables retain headers, pagination, and bulk actions; large artwork fills dense dashboard widgets; the mobile recovery action is hidden by sticky chrome or the keyboard.

Case Study

Carbon separates empty states into no data, user action, and error management, and names permission, system, and configuration cases as requiring more specific guidance. NN/g's complex-application analysis shows that blank states or inaccurate No records messages leave users unsure whether data is loading, missing, or failed, reducing confidence. PatternFly separates no results, required configuration, no access, back-end failure, success, and creation, each with different heading/body/action guidance. The reusable lesson is that empty states should be implemented as a state machine and recovery path, not as a swap-in illustration component.

Source Links

Carbon Empty States: https://carbondesignsystem.com/patterns/empty-states-pattern/

NN/g Empty States in Complex Applications: https://www.nngroup.com/articles/empty-state-interface-design/

PatternFly Empty State Guidelines: https://www.patternfly.org/components/empty-state/design-guidelines/

Atlassian Empty State: https://atlassian.design/components/empty-state

Material Design Empty States: https://m2.material.io/design/communication/empty-states.html

Agent Directive

When generating empty states, first output EmptyReason, completed-state render condition, cause copy, primary recovery action, secondary action, details fields, and accessible announcement strategy; branch by search-empty, filtered-empty, permission, configuration, backend-error, and related reasons instead of reusing one No data component.