UX Patterns Guide
UX Feedback, Status, And System State anti-pattern

Dead-end empty state

Treat the blank surface as an anti-pattern: determine the actual cause, then replace it with a legitimate empty state, no-results recovery, error state, permission explanation, setup step, or navigation escape.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Auditing generated UIs, dashboards, tables, lists, or panels for blank states that strand users.
  • A surface has no visible content but the current UI does not prove why or what can happen next.
  • An existing empty-state treatment is decorative, permission-blind, or not connected to recovery.

Avoid when

  • The surface already explains the cause and offers a valid next step.
  • The product intentionally hides the existence of data for privacy or safety and provides safe navigation or explanation.
  • The state is transient loading with clear progress, timeout, or cancellation behavior.
  • A regulatory or security flow must deny access without disclosing object existence, while still giving a safe next step.

Problem it prevents

Users reach a blank or nearly blank area and cannot tell what is missing, why it is missing, or what they can do next.

Pattern anatomy

What a strong implementation has to make clear

User need

A list, table, dashboard, workspace, inbox, or panel can render with no visible items.

Pattern promise

Treat the blank surface as an anti-pattern: determine the actual cause, then replace it with a legitimate empty state, no-results recovery, error state, permission explanation, setup step, or navigation escape.

Required state

Unexplained blank state that is being audited as the anti-pattern.

Recovery path

No object name.

Access contract

Do not use an unlabeled blank region as the only state announcement.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A replacement state names No projects yet, explains the workspace has no projects, and offers Create project or Import CSV only when permitted.
  • A filtered blank state keeps filter chips visible and offers Remove archived filter and Clear all filters.
  • Users can classify the absence and take the correct path: create, import, clear filters, request access, retry, restore, or leave safely.
  • When an item is deleted and the list becomes empty, focus moves to a recovery state with undo or next navigation instead of an inert void.
Weak implementation

Vague, hidden, hard to recover from

  • An empty table body with pale placeholder lines and no label.
  • A decorative illustration with Nothing here and no action.
  • Users cannot tell whether content is still loading, filtered out, unavailable, failed, or nonexistent.
  • The only visible action fails because the current user lacks permission.
UI guidance
  • A dead-end empty state is visible as blank space, vague art, hidden filters, disabled mystery controls, or an empty table body with no object name, cause, or action.
  • 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.
  • Prevent users from getting stranded by ensuring every resolved empty state either changes the system, changes criteria, requests access, retries, restores, or explains why no action exists.
Implementation contract

What the implementation must handle

States

  • Unexplained blank state that is being audited as the anti-pattern.
  • Diagnosed first-use or legitimate absence state with object-specific copy and valid action.
  • Filtered or searched no-results state with visible criteria and recovery controls.
  • Permission or prerequisite state with explanation and request/setup path.

Interaction

  • A blank or actionless content region is not a valid terminal state.
  • The replacement state must name what is absent and why the system believes it is absent.
  • The next action must be available to the current user or replaced with a permission/prerequisite explanation.
  • If the cause is uncertain, the UI should show loading, retry, or diagnostic recovery instead of pretending the area is empty.

Accessibility

  • Do not use an unlabeled blank region as the only state announcement.
  • Keep the cause, affected object, and recovery controls in normal reading order.
  • Move focus to a useful heading, recovery action, or restored content when the state changes.
  • Do not strand keyboard focus on removed rows, disabled mystery controls, or inert illustrations.

Review

  • Can users name what is absent after reading this state?
  • Can users tell whether the cause is first-use, filters, permission, setup, deletion, loading, or failure?
  • Is the visible next action valid for this user and wired to a meaningful state change?
  • Would the same blank copy still appear if the cause changed to error or no-results?
Interactive lab

Inspect the states before you copy the pattern

Diagnose a blank dead end

Switch between empty causes and compare a recoverable state with an inert blank panel.

Dead-end empty state
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Unexplained blank state that is being audited as the anti-pattern.

Keyboard / Access

Tab order should reach the explanation and the valid recovery action without passing through inert filler.

Avoid Generating

Blank table body with no heading, count, cause, or action.
Evidence trail

Source-backed claims behind this guidance

Carbon Design System Empty States Pattern

IBM Carbon Design System - checked

Carbon distinguishes no-data, user-action no-results, and error-management empty states, which helps diagnose dead-end blanks.

Atlassian Design System Empty State

Atlassian Design System - checked

Atlassian documents empty states with explanation, action, and variants for permission, filtered, and error causes.

SAP Fiori Illustrated Message

SAP Fiori - checked

SAP Fiori documents contextual illustrated messages with title, description, optional action, and situation-matched content.

Shopify Polaris Empty State

Shopify Polaris - checked

Polaris documents empty states with focused explanation, illustration, primary action, and optional secondary action.

GOV.UK Design System Patterns

Government Digital Service - checked

GOV.UK service patterns emphasize task progress, recovery, and clear next steps rather than blank terminal states.

Full agent/debug reference

Problem Context

  • A list, table, dashboard, workspace, inbox, or panel can render with no visible items.
  • The product may not yet know whether the cause is first use, filters, permissions, loading failure, deletion, unavailable data, or a hidden prerequisite.
  • Users need enough context to decide whether to create, import, clear criteria, request access, retry, restore, or leave.

Selection Rules

  • Flag dead-end empty state when a blank area lacks a specific object name, cause, and reachable next action.
  • Flag decorative-only empty states when illustration or friendly copy replaces actionable explanation.
  • Flag states that show a primary action the current user cannot perform, because a failed action is still a dead end.
  • Replace with empty state when the absence is legitimate and the user has a setup, create, import, sample, or request-access path.
  • Replace with no-results recovery when visible search, filter, or sort criteria produced zero matches.
  • Replace with error state when expected content failed to load, save, sync, authorize, or compute.
  • Do not mark the state resolved until keyboard, focus, screen-reader reading order, and post-action transition all give users a real path out.

Required States

  • Unexplained blank state that is being audited as the anti-pattern.
  • Diagnosed first-use or legitimate absence state with object-specific copy and valid action.
  • Filtered or searched no-results state with visible criteria and recovery controls.
  • Permission or prerequisite state with explanation and request/setup path.
  • Failure state with retry, fallback, or support path.
  • Escaped or recovered state after the user takes a valid next action.

Interaction Contract

  • A blank or actionless content region is not a valid terminal state.
  • The replacement state must name what is absent and why the system believes it is absent.
  • The next action must be available to the current user or replaced with a permission/prerequisite explanation.
  • If the cause is uncertain, the UI should show loading, retry, or diagnostic recovery instead of pretending the area is empty.
  • Focus should not remain on removed content or an inert blank panel after data changes.
  • The state must update when content appears, criteria are cleared, access changes, or retry succeeds.

Implementation Checklist

  • Track data status separately from rendered item count: loading, empty, no-results, permission, error, and ready.
  • Render the surrounding context such as table title, filter chips, workspace, owner, or object type.
  • Write a cause-specific heading and short explanation before adding illustration.
  • Show one valid primary action or a clear reason no action is available.
  • Do not offer create/import/reset/retry controls unless they are permitted and wired to a state change.
  • Keep keyboard focus in a useful place after the blank region resolves or changes cause.
  • Instrument blank states so repeated dead ends can be found and replaced.

Common Generated-UI Mistakes

  • Blank table body with no heading, count, cause, or action.
  • Friendly illustration plus vague text such as Nothing here yet with no task path.
  • Create button shown to a read-only user and failing after activation.
  • No-results caused by filters but active criteria are hidden above the fold.
  • Failed load rendered as empty content to avoid showing an error.
  • A removed item leaves keyboard focus on a now-empty region with nowhere to go.

Critique Questions

  • Can users name what is absent after reading this state?
  • Can users tell whether the cause is first-use, filters, permission, setup, deletion, loading, or failure?
  • Is the visible next action valid for this user and wired to a meaningful state change?
  • Would the same blank copy still appear if the cause changed to error or no-results?
Accessibility
  • Do not use an unlabeled blank region as the only state announcement.
  • Keep the cause, affected object, and recovery controls in normal reading order.
  • Move focus to a useful heading, recovery action, or restored content when the state changes.
  • Do not strand keyboard focus on removed rows, disabled mystery controls, or inert illustrations.
Keyboard Behavior
  • Tab order should reach the explanation and the valid recovery action without passing through inert filler.
  • After clearing criteria, retrying, creating, or requesting access, focus should move to the updated result, confirmation, or still-recoverable state.
  • If no action is available, provide a reachable navigation or explanation instead of a keyboard trap.
  • Avoid disabled controls without an adjacent explanation of the missing prerequisite.
Variants
  • Blank dashboard dead end
  • Empty table with no action
  • Permission dead end
  • Filtered dead end
  • Failed-load-as-empty
  • Decorative-only empty state
  • Focus orphan after deletion

Verification

Last verified: