composite pattern · Structural containers and states
Empty State
A purposeful, instructional view shown when a list, search, or content area contains no data, guiding the user toward a first action.
Decisive boundary
An empty state should guide the user, not punish them. Offer one clear next step without burying it in explanation.
Definition and intent
What is a Empty State UI pattern?
Use the behavior, not the silhouette
A purposeful, instructional view shown when a list, search, or content area contains no data, guiding the user toward a first action. The term is used here as a composite pattern made from multiple controls or regions that must work together. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Turn a void into an opportunity by telling users what this view does when populated and what to do next. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Empty State, the boundary is: An empty state should guide the user, not punish them. Offer one clear next step without burying it in explanation.
Do not implement it as Error page for expected empty conditions, and Card for populated content that happens to have little data. If those requirements describe the real task better, use the related pattern page or the full Structural containers and states comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Turn a void into an opportunity by telling users what this view does when populated and what to do next.
Define opening and closing
A content area with no items to render — an empty list, search with no matches, or an onboarding state. Resolved when content is added, a filter is cleared, or a search returns results.
Specify access behavior
Any call-to-action button should be reachable in normal tab order; the view itself does not move focus. Standard keyboard access to any button or link within the empty view.
Reject the near miss
Error page for expected empty conditions, and Card for populated content that happens to have little data.
Behavior contract
What must survive the build
- trigger
- A content area with no items to render — an empty list, search with no matches, or an onboarding state.
- dismissal
- Resolved when content is added, a filter is cleared, or a search returns results.
- modality
- Non-modal inline view.
- focus
- Any call-to-action button should be reachable in normal tab order; the view itself does not move focus.
- keyboard
- Standard keyboard access to any button or link within the empty view.
- interactive
- Contains at most one or two clear actions — typically create, import, or adjust filters.
- persistence
- Remains until data or user action fills the area.
- placement
- Centered within the content area it represents, often with generous whitespace.
- mobile
- Actions should be comfortably tap-sized; avoid crowding the empty view with secondary information.
Failure modes
Common wrong builds
- Showing only 'no results' without a next action.
- Using the same empty state for every context.
- Making the call-to-action ambiguous or hidden.
- Forgetting to update the empty copy when the product changes.
Observable checks
Verify the result
- One clear instruction or primary action is visible.
- The action is keyboard reachable.
- The view disappears when content populates.
- Copy is contextual to the current view.
- The area remains announced to assistive technology.
Coding-agent handoff
Implementation brief template
Pattern: Empty State Purpose: Turn a void into an opportunity by telling users what this view does when populated and what to do next. Trigger: A content area with no items to render — an empty list, search with no matches, or an onboarding state. Dismissal behavior: Resolved when content is added, a filter is cleared, or a search returns results. Modality: Non-modal inline view. Focus behavior: Any call-to-action button should be reachable in normal tab order; the view itself does not move focus. Keyboard behavior: Standard keyboard access to any button or link within the empty view. Interactive content: Contains at most one or two clear actions — typically create, import, or adjust filters. Placement: Centered within the content area it represents, often with generous whitespace. Mobile behavior: Actions should be comfortably tap-sized; avoid crowding the empty view with secondary information. Do not implement as: Error page for expected empty conditions, and Card for populated content that happens to have little data. Acceptance checks: - One clear instruction or primary action is visible. - The action is keyboard reachable. - The view disappears when content populates. - Copy is contextual to the current view. - The area remains announced to assistive technology.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Empty State UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Empty State in web UI?
A purposeful, instructional view shown when a list, search, or content area contains no data, guiding the user toward a first action. In this reference set it is a composite pattern made from multiple controls or regions that must work together.
When should I use a Empty State?
Turn a void into an opportunity by telling users what this view does when populated and what to do next. The decisive boundary to confirm is this: An empty state should guide the user, not punish them. Offer one clear next step without burying it in explanation.
What keyboard and focus behavior does a Empty State need?
Standard keyboard access to any button or link within the empty view. Any call-to-action button should be reachable in normal tab order; the view itself does not move focus. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Empty State behave on mobile?
Actions should be comfortably tap-sized; avoid crowding the empty view with secondary information. Its modality is a separate requirement: Non-modal inline view.
How do I verify a Empty State implementation?
Start with observable checks: One clear instruction or primary action is visible. The action is keyboard reachable. The view disappears when content populates. Then verify the remaining checks and compare the result with the linked source guidance.