Empty States & Zero-Data Screens

Interactive example · System statesEvery async view needs all four

LoadingEmptyErrorSuccess

Skeleton screens preserve layout and feel faster than a spinner for content-heavy views.

The full lesson

Every product has moments when there is nothing to display. A brand-new account with no activity. A search that returned no matches. An inbox finally cleared. A filtered list that excluded everything. These moments are called empty states, and they are some of the most under-designed screens in any product.

The instinct is to treat them as edge cases — slap on a “No results found” message and move on. But an empty state is often the very first thing a new user sees, or the last thing a frustrated user sees before they leave. They deserve the same care as any primary screen.

This lesson covers the types of empty states, what each one needs, how to write for them, how to design them accessibly, and the anti-patterns that still dominate production UIs in 2026.

The Four Types of Empty States

Treating all empty states the same is itself a design mistake. Each type carries different user context, a different emotional tone, and calls for a different response. Identifying the type before you write a single word of copy or draw an illustration is the most important first step.

First-Use / Blank Slate

The user has just arrived in a new context — a fresh workspace, a new project, an empty inbox. They have not done anything wrong. They simply have not started yet. The main job here is orientation and activation: tell the user what this space is for, and give them a clear, low-friction first action.

This is the type designers spend the most time on, and for good reason — it doubles as onboarding real estate. But the two goals (explain the space, activate the user) can conflict. A wall of explanatory text buries the action. A giant CTA button with no context leaves users unsure whether they want to click it. The solution is a tight hierarchy: a short headline (what this space is), one sentence of context (what it looks like when populated), and a primary action.

No-Results / Search Empty State

The user ran a deliberate action — a search, a filter, a query — and got nothing back. This is the most stressful empty state, because the user came with a specific intent and the product did not satisfy it. The emotional tone is not neutral. The design job is to reduce frustration and restore the user’s sense of control.

Answer three questions in this state:

1. Did I understand you correctly? (Restate the query or active filters.)
2. What might explain no results? (Filters too narrow, search too specific.)
3. What can you do next? (Clear filters, broaden the search, try a different term.)

All three can fit in two or three lines of copy. That short paragraph is the difference between a user who tries again and a user who leaves.

User-Cleared / Success Empty State

The user emptied the state themselves: the last task was completed, the last notification dismissed, the last item deleted. This is a positive moment. Responding to it with the same neutral empty state as the blank slate misses an opportunity to reinforce good behavior. Acknowledging the action — “All caught up”, “Inbox zero” — gives users a small but real sense of accomplishment.

Error / Permission Empty State

The data exists but cannot be shown: the network is offline, the user lacks permissions, or the data source returned an error. This type is the most technically complex because the root cause varies. Showing a generic “Something went wrong” for a permissions error wastes the user’s time.

A permission-gated empty state should explain what access is needed and who can grant it. A connectivity error should tell the user whether the problem is on their side or the server’s, and whether retrying makes sense.

Anatomy of an Effective Empty State

Every well-designed empty state has a small set of clearly defined layers. Not all layers are needed for every type.

Layer	Purpose	Required for
Illustration or icon	Set tone; confirm the user is in the right place	First-use, success
Headline	State the situation plainly	All types
Body copy	Explain the why and the what-next	No-results, error
Primary action	Give the user something to do	First-use, no-results
Secondary action	Offer an alternative path	No-results, error

The visual layer — illustration or icon — is where teams most often over- or under-invest. A generic document icon communicates nothing. An original spot illustration built from your brand’s visual language sets tone, confirms context, and differentiates the experience.

The counter-trap is over-illustrating. A full-bleed hero illustration can make a frequent empty state (like a no-results search) feel heavy and slow, especially on repeat views. Save high-fidelity illustrations for first-use states that users see rarely. Keep frequent empty states leaner.

Writing Empty State Copy

UX writing is the highest-leverage skill for empty states. Well-written copy can recover an experience that no illustration can fix. Three principles govern good empty state copy.

Be specific about what’s missing. “No items” is worse than “No projects yet.” “No results” is worse than “No results for ‘quarterly report’ — try a shorter search term.” The more the copy references the actual context, the more the user trusts that the product understood them.

Use active voice and present tense. “Your tasks will appear here” is passive and deferred. “Add your first task to get started” is direct and immediate. The second version treats the user as someone in control, not a passive recipient.

Write the call to action as a specific outcome, not a generic verb. “Get started” and “Add new” are filler. “Create your first project” and “Import contacts from CSV” tell the user exactly what clicking that button will do — and what they will have afterward.

Layout and Visual Design

Empty states occupy the full viewport or a large content area — by definition, they are not competing with other content for space. That creates both an opportunity and a risk. The opportunity is generous whitespace and a calm, focused layout. The risk is that a poorly composed empty state looks unfinished, like the designer forgot to add real content.

Several layout principles apply specifically to empty states.

Center but constrain. Centering an empty state vertically and horizontally works well. But the content container needs a max-width — typically 360–480px for the text block. Without it, headlines stretch to full viewport width on large screens and become uncomfortable to read.

Vertical rhythm matters more here. Because there is no competing content, every spacing decision is visible. Use consistent spacing tokens. Resist pushing elements apart with arbitrary margins to “fill the space.” The emptiness is the point.

Maintain the surrounding chrome. Empty states should still show the navigation, sidebar, and page header. A user who clears all their notifications should still be able to navigate elsewhere. An empty state that hides the navigation implies the user is stuck — which is the opposite of empowering.

Adapt to container context. An empty state inside a widget on a dashboard needs to behave differently from a full-page empty state. Container queries (available in all evergreen browsers since 2023) are the right tool for component-scoped empty state layouts. The component responds to its own container width, not the viewport, so it works correctly whether it appears in a sidebar, a main panel, or a modal.

Accessibility Requirements

Empty states are subject to the same accessibility standards as any other screen. But a few specific requirements are easy to miss.

Heading structure. The empty state headline should use the correct heading level for its context. If the page already has an h1, the empty state headline is typically an h2. An empty state inside a card where the card title is the heading should use h3. Getting this wrong breaks the document outline that screen reader users rely on to navigate the page.

Illustration alt text. Decorative illustrations that reinforce tone without conveying unique information should have alt="" so screen readers skip them. If the illustration conveys specific meaning — such as a diagram of the product feature that would appear here — it needs descriptive alt text. The distinction matters: an ornamental rocket on a “No launches yet” screen is decorative; a workflow diagram is informative.

Action button labeling. Buttons in empty states are often labeled with icons only, or with generic text like ”+” that makes sense visually but has no accessible name. Every action button needs a visible text label or an aria-label that describes the specific outcome: “Create new project”, not “Add”.

Focus management. If an empty state loads dynamically — after a search returns nothing, or after the last item is deleted — focus must be managed deliberately. The browser’s default behavior is to return focus to the body, which leaves keyboard users stranded. Move focus to the empty state headline or the first actionable element within it.

Skeletons vs. Empty States: Knowing the Difference

A common mistake is showing an empty state during loading — before the data has arrived. A user who sees “No projects yet” while the network request is still in flight will be confused or misled if projects then appear a moment later.

The modern approach uses a state machine with at least four distinct states for any data-bearing view:

1. Loading — the data request is in flight; show skeleton screens (for content-heavy layouts) or a spinner (for short, blocking operations under roughly 300ms)
2. Error — the request failed; show the error empty state with a retry action
3. Empty — the request succeeded and the result is genuinely empty; show the right empty state type
4. Populated — data is present; show the real content

The loading and empty states must be mutually exclusive. Conflating them — by showing “nothing” during loading, or keeping the skeleton up after a truly empty response — destroys user trust and generates support tickets. The explicit state machine is not optional complexity; it is the minimum needed to handle the real world.

Skeleton screens work because they give users a preview of the layout they are about to receive, reducing perceived wait time. An empty state serves the opposite purpose: it tells the user that the layout they will receive is nothing. Using a skeleton to stall before an empty state — a pattern sometimes used to make a product feel “busier” — is a dark pattern. It creates false expectation.

Common Anti-Patterns to Retire

Several empty state patterns remain common in 2026 despite being consistently harmful.

“No results found” with no recovery path. This pattern appears across enterprise software, e-commerce search, and CMS tools. The copy technically communicates the state, but offers no next action. Even if the correct action is just “clear filters”, the UI must make that action explicit and immediately available.

Empty states that expose internal system state. Error messages like “Query returned 0 rows” or “null” mean developer output was never translated into user language. These are a product quality problem, not just a cosmetic issue.

Hiding functionality in the empty state. Some products put the “create” action only in the empty state, removing it from the primary navigation. When the list has items, users can no longer find how to create a new one. The empty state CTA should supplement navigation, not replace it.

Animating the empty state on every render. An entrance animation on a no-results state that the user sees ten times per session becomes noise, then annoyance. Use motion in empty states for first-use blank slates only, or suppress it via prefers-reduced-motion. Never loop an illustration on a state the user will stare at while reading copy.

Measuring Empty State Effectiveness

Empty states are part of the conversion funnel, and they should be treated that way. Key behaviors to track:

• Click-through rate on the primary CTA. A blank-slate empty state CTA with a low click rate signals friction — the ask is unclear, too large, or poorly timed.
• Search refinement rate. On no-results states, does the user modify their search or navigate away? A high abandonment rate signals that the recovery copy is not working.
• Return rate. Users who hit an empty state and come back have been retained despite the friction. Users who never return may have interpreted the empty state as a product failure.
• Task Success Rate (TSR) and the Single Ease Question (SEQ) applied to flows that commonly hit empty states give validated, benchmarkable signal — more reliable than self-reported satisfaction on post-task surveys.

The goal is not to eliminate empty states — they are structurally unavoidable in any data-driven product. The goal is to make them a neutral or positive moment in the experience, not a stopping point.