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
Learn the decision

Match the interaction to the person's task

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

Empty state

Use it when: A next setup, creation, import, sample, or access-request action is available or explainable.

Make this state clear: First-use empty state before any objects exist.

Observe the result: Users can create the first project, import existing work, or request access depending on the actual cause.

Study the full pattern →

No-results recovery

Use it when: Search, browse, or filter controls can produce an empty result set.

Make this state clear: Zero-result state that preserves the user's criteria.

Observe the result: Users can remove one filter, clear all, edit query, or try suggested alternatives.

Study the full pattern →

Error state

Use it when: A system or task failure blocks expected content or action.

Make this state clear: Normal expected state before failure.

Observe the result: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.

Study the full pattern →

Practice the judgment: Imagine this situation: Treating first-use emptiness as an error. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

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 Keep surrounding context such as table title, filters, or workspace name visible so users know exactly what is empty.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 Move users toward the first useful object or prerequisite, and replace unavailable actions with permission or configuration guidance.Help users recover when their own search or filters excluded all results.Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI.
Good UI Permission variant explains that projects exist only after an admin grants access and offers Request access instead of Create.Zero-result state shows query/filters, result count, and clear or broaden actions.A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation.
Bad UI Oversized decorative art and vague welcome copy that hides the task.Huge empty state that hides active filters.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 A primary Create button is shown to a read-only user and fails after activation.Telling users nothing exists when filters caused the state.Clearing work after save failure.
Best fit A next setup, creation, import, sample, or access-request action is available or explainable.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.The state is caused by an error rather than valid empty results.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 Using marketing copy instead of a task-specific next step.Resetting all criteria automatically.Using a transient toast for critical errors.

Empty state

UI or UX
UI + UX - Resolved no-data content surface
UI guidance
Keep surrounding context such as table title, filters, or workspace name visible so users know exactly what is empty.
UX guidance
Move users toward the first useful object or prerequisite, and replace unavailable actions with permission or configuration guidance.
Good UI
Permission variant explains that projects exist only after an admin grants access and offers Request access instead of Create.
Bad UI
Oversized decorative art and vague welcome copy that hides the task.
Good UX
Users can create the first project, import existing work, or request access depending on the actual cause.
Bad UX
A primary Create button is shown to a read-only user and fails after activation.
Best fit
A next setup, creation, import, sample, or access-request action is available or explainable.
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
Using marketing copy instead of a task-specific next step.

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
Huge empty state that hides active filters.
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
The state is caused by an error rather than valid empty results.
Required state
Zero-result state that preserves the user's criteria.
Accessibility burden
Announce result-count changes where search results update dynamically.
Common misuse
Resetting all criteria automatically.

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
Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI.
Good UI
A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation.
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.

Saved items