UX Patterns Guide
Back to compare picker

Empty state vs No-results recovery vs Error state

Prefer empty state when the content area is legitimately blank because nothing has been created, imported, configured, or made available yet.

Empty state live exampleNo-results recovery live exampleError state live example

Decision dimensions

Dimension Empty stateNo-results recoveryError state
UI or UX UI + UX - Resolved no-data content surfaceUI + UX - Search recovery stateUI + UX - Recoverable failure surface
UI guidance Render a resolved no-data region with a specific heading, cause text, one primary action when available, optional secondary path, and restrained illustration or icon support.Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions.Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance Help users distinguish legitimate absence from loading, no-results, error, permission, and setup conditions before offering a next step.Help users recover when their own search or filters excluded all results.Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI No projects yet heading, short explanation, Create project primary button, Import CSV secondary button, and visible workspace context.Zero-result state shows query/filters, result count, and clear or broaden actions.Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI A blank white table body with no text, object name, or action.No results text alone with no criteria shown.Tiny transient toast for a blocking failure.
Good UX Users can create the first project, import existing work, or request access depending on the actual cause.Users can remove one filter, clear all, edit query, or try suggested alternatives.User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX The same empty message appears for loading, search no-results, permission denial, and service failure.Telling users nothing exists when filters caused the state.Clearing work after save failure.
Best fit The product area can legitimately contain no user data.Search, browse, or filter controls can produce an empty result set.A system or task failure blocks expected content or action.
Avoid when The absence was caused by filters or search.There is genuinely no possible next action and the system should instead explain availability.Nothing exists yet and the state is expected.
Required state First-use empty state before any objects exist.Zero-result state that preserves the user's criteria.Normal expected state before failure.
Accessibility burden Keep the message in normal reading order near the empty region it explains.Announce result-count changes where search results update dynamically.Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse Showing a blank page with no explanation.Showing a blank list with no explanation.Using a transient toast for critical errors.

Empty state

UI or UX
UI + UX - Resolved no-data content surface
UI guidance
Render a resolved no-data region with a specific heading, cause text, one primary action when available, optional secondary path, and restrained illustration or icon support.
UX guidance
Help users distinguish legitimate absence from loading, no-results, error, permission, and setup conditions before offering a next step.
Good UI
No projects yet heading, short explanation, Create project primary button, Import CSV secondary button, and visible workspace context.
Bad UI
A blank white table body with no text, object name, or action.
Good UX
Users can create the first project, import existing work, or request access depending on the actual cause.
Bad UX
The same empty message appears for loading, search no-results, permission denial, and service failure.
Best fit
The product area can legitimately contain no user data.
Avoid when
The absence was caused by filters or search.
Required state
First-use empty state before any objects exist.
Accessibility burden
Keep the message in normal reading order near the empty region it explains.
Common misuse
Showing a blank page with no explanation.

No-results recovery

UI or UX
UI + UX - Search recovery state
UI guidance
Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions.
UX guidance
Help users recover when their own search or filters excluded all results.
Good UI
Zero-result state shows query/filters, result count, and clear or broaden actions.
Bad UI
No results text alone with no criteria shown.
Good UX
Users can remove one filter, clear all, edit query, or try suggested alternatives.
Bad UX
Telling users nothing exists when filters caused the state.
Best fit
Search, browse, or filter controls can produce an empty result set.
Avoid when
There is genuinely no possible next action and the system should instead explain availability.
Required state
Zero-result state that preserves the user's criteria.
Accessibility burden
Announce result-count changes where search results update dynamically.
Common misuse
Showing a blank list with no explanation.

Error state

UI or UX
UI + UX - Recoverable failure surface
UI guidance
Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance
Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI
Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI
Tiny transient toast for a blocking failure.
Good UX
User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX
Clearing work after save failure.
Best fit
A system or task failure blocks expected content or action.
Avoid when
Nothing exists yet and the state is expected.
Required state
Normal expected state before failure.
Accessibility burden
Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse
Using a transient toast for critical errors.
Decision rules
  • Prefer empty state when the content area is legitimately blank because nothing has been created, imported, configured, or made available yet.
  • Prefer no-results recovery when content exists in the system but the user's query, filters, or sort criteria excluded every item.
  • Prefer error state when expected content cannot be loaded, saved, or computed because a request, service, permission, or validation path failed.
  • Do not show an empty state while data is still unresolved; use loading skeleton or progress feedback until the system knows whether the area is empty.
  • For permission or setup gaps, keep the empty state only if the absence is expected and explain the prerequisite instead of offering an action the user cannot perform.
  • For destructive cleanup or deletion, confirm the area is intentionally empty and offer restoration, creation, or import only when those actions are available.
  • For search pages, keep the user's query and filters visible and offer recovery actions; do not replace no-results with first-use onboarding copy.
  • For load, save, sync, or permission failures, keep the affected content or draft context visible and offer retry, edit, fallback, or support escalation that matches the cause.
  • Do not use a transient toast for a blocking failure that changes whether the page can be trusted; keep the error visible until recovery, dismissal, or escalation is complete.
Inspect live examples
Empty stateNo-results recoveryError state
Failure modes
  • Showing a blank area with no cause or next step.
  • Telling users there are no results when the real cause is a system failure.
  • Treating first-use emptiness as an error.
  • Offering create or import actions to users without permission.
  • Showing the empty state before the first data request finishes.
  • Using cheerful onboarding copy after users intentionally deleted or filtered content.
  • Clearing user-entered work after a failed save.
  • Showing only Something went wrong with no affected object, retry, fallback, or support path.