UX Patterns Guide
Back to compare picker

Dead-end empty state vs Empty state vs No-results recovery vs Error state

Use error state when expected content failed to load, save, sync, authorize, or compute; preserve context and offer retry, fallback, correction, or support escalation.

Dead-end empty state live exampleEmpty state live exampleNo-results recovery live exampleError state live example
Learn the decision

Match the interaction to the person's task

Use error state when expected content failed to load, save, sync, authorize, or compute; preserve context and offer retry, fallback, correction, or support escalation.

Dead-end empty state

Use it when: Auditing generated UIs, dashboards, tables, lists, or panels for blank states that strand users.

Make this state clear: Unexplained blank state that is being audited as the anti-pattern.

Observe the result: Users can classify the absence and take the correct path: create, import, clear filters, request access, retry, restore, or leave safely.

Study the full pattern →

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: Empty-state copy shown for a failed API request. 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 Dead-end empty stateEmpty stateNo-results recoveryError state
UI or UX UX - Actionless blank-state anti-patternUI + UX - Resolved no-data content surfaceUI + UX - Search recovery stateUI + UX - Recoverable failure surface
UI guidance Replace it with a cause-specific state that keeps surrounding context visible and presents a valid action, recovery path, permission explanation, or safe escape.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 Diagnose why the surface is empty before choosing copy or controls: first-use, configured-empty, filtered, permission-limited, failed, loading, deleted, or unavailable.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 A filtered blank state keeps filter chips visible and offers Remove archived filter and Clear all filters.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 Wrong replacement pattern for the cause.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 classify the absence and take the correct path: create, import, clear filters, request access, retry, restore, or leave safely.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 only visible action fails because the current user lacks permission.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 Auditing generated UIs, dashboards, tables, lists, or panels for blank states that strand users.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 surface already explains the cause and offers a valid next step.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 Unexplained blank state that is being audited as the anti-pattern.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 cause, affected object, and recovery controls in normal reading order.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 Create button shown to a read-only user and failing after activation.Using marketing copy instead of a task-specific next step.Resetting all criteria automatically.Using a transient toast for critical errors.

Dead-end empty state

UI or UX
UX - Actionless blank-state anti-pattern
UI guidance
Replace it with a cause-specific state that keeps surrounding context visible and presents a valid action, recovery path, permission explanation, or safe escape.
UX guidance
Diagnose why the surface is empty before choosing copy or controls: first-use, configured-empty, filtered, permission-limited, failed, loading, deleted, or unavailable.
Good UI
A filtered blank state keeps filter chips visible and offers Remove archived filter and Clear all filters.
Bad UI
Wrong replacement pattern for the cause.
Good UX
Users can classify the absence and take the correct path: create, import, clear filters, request access, retry, restore, or leave safely.
Bad UX
The only visible action fails because the current user lacks permission.
Best fit
Auditing generated UIs, dashboards, tables, lists, or panels for blank states that strand users.
Avoid when
The surface already explains the cause and offers a valid next step.
Required state
Unexplained blank state that is being audited as the anti-pattern.
Accessibility burden
Keep the cause, affected object, and recovery controls in normal reading order.
Common misuse
Create button shown to a read-only user and failing after activation.

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
  • Flag dead-end empty state when the page, table, list, dashboard, or panel has no object name, no cause, no valid next action, or no safe escape.
  • Use empty state when the absence is legitimate: first use, no created objects, no imported data, setup not complete, or permission-limited access with an explainable request path.
  • Use no-results recovery when user-controlled query, filters, sort, or browse criteria produced zero visible items; keep the criteria visible and offer remove-one, clear-all, broaden, or suggested-query actions.
  • Use error state when expected content failed to load, save, sync, authorize, or compute; preserve context and offer retry, fallback, correction, or support escalation.
  • Do not treat decorative art plus vague copy as a complete empty state unless the object, cause, and action are still clear without the illustration.
  • Do not show create, import, retry, restore, or clear controls unless the current user can use them and the action changes state predictably.
  • When the cause is not known yet, show loading, timeout, retry, or diagnostic feedback instead of rendering a blank resolved state.
  • After deletion or cleanup, choose restore, create/import, or navigation based on whether the empty result is intentional and recoverable.
  • If privacy or security prevents disclosing object existence, avoid a dead end by giving a safe generic explanation and navigation or request-access path.
Inspect live examples
Dead-end empty stateEmpty stateNo-results recoveryError state
Failure modes
  • Blank surface with no text, no count, no action, and no status.
  • Empty-state copy shown for a failed API request.
  • No-results shown without visible filters or query.
  • Create action shown to a read-only user.
  • Disabled button presented as the only next step.
  • Focus remains on a removed row or inert blank panel after the list becomes empty.
  • Same generic empty copy used for first-use, filtered, permission, loading, and error causes.

Saved items