Empty State & Zero-Data Messaging
Blank screens are a design decision — master the copy, structure, and recovery patterns that turn zero-data moments into confident next steps.
10 min read
The full lesson
When a user lands on a page with nothing in it — no items, no history, no results — the product is at its most vulnerable. A blank screen either says “you are in the right place, here is what to do” or “something went wrong and we have no idea what.” The difference comes entirely from the words, structure, and intention behind the empty state. Getting this right is not a polish pass. It is a core usability concern that affects first impressions, activation rates, and user confidence throughout the product.
What Empty States Actually Are
An empty state is any UI state where the main content area has nothing to show. There are four meaningfully different types. Mixing them up is the most common empty-state mistake:
- First-use empty state: the user has never done the thing yet. An inbox with zero messages. A project list with no projects. A reading list just created.
- User-cleared empty state: the user did the thing and then undid it. They deleted all their tasks, archived every notification, or paid off every invoice.
- No-results empty state: a search or filter returned nothing. The user asked a question the system cannot answer.
- Error-adjacent empty state: data should be here but failed to load. This could be a network error, a permissions issue, or a sync delay.
Each type has a different emotional context and different user intent. Each one needs different copy and different affordances. Using one generic “Nothing here yet” template is a category error as often as it is a reasonable default.
Why Empty States Are a High-Stakes Moment
Empty states are not neutral. Research consistently shows that the first-use empty state is one of the strongest predictors of whether a user activates — that is, reaches the moment of value that turns them into a retained user rather than a churn statistic. A user who sees a blank screen with no path forward will leave. A user who sees a blank screen with a clear invitation and a concrete first action has a much higher chance of completing it.
The outdated approach treats empty states as a missing-data problem. Add an illustration and a button, done. The modern approach treats them as onboarding moments that carry the weight of the entire first experience. The copy in an empty state must do three things at once: orient the user (“you are in the right place”), explain why it is empty, and direct them toward what to do next.
The Anatomy of an Effective Empty State
Every empty state has four potential layers. You do not always need all four, but each one has a specific job:
| Layer | Job | Example |
|---|---|---|
| Headline | Name the state honestly | ”No projects yet” or “Your inbox is empty” |
| Explanation | Clarify why and set expectations | ”Projects you create will appear here” |
| Primary action | Give a specific, verb-led next step | ”Create your first project” |
| Secondary context | Reduce anxiety or offer an alternative path | ”Need help getting started? See the quick-start guide” |
The headline is the most commonly miswritten layer. Avoid clever phrasing that obscures the state — “Crickets!” is not helpful in a developer tool. Avoid over-apologetic phrasing like “We’re sorry, there’s nothing here,” which implies fault. The right tone is direct and forward-looking: name what is absent, then invite what comes next.
The primary action label should be specific enough to complete the sentence “I want to ___.” A button that says “Get started” tells the user nothing about what they are starting. Labels like “Create your first project,” “Add your first contact,” or “Upload a file” are concrete and feel achievable.
Do
Write an empty-state headline that names the specific absent thing: “No invoices yet.” Follow with one sentence that explains what will appear here and why. Then give a primary CTA whose label names the exact action: “Create invoice.” Match the tone to the product context — warm and encouraging for consumer apps, clear and direct for professional tools.
Don't
Use generic filler headlines like “Nothing to see here” or “It’s quiet in here” when a user needs clarity, not wit. Avoid vague CTA labels like “Get started” or “Let’s go” that do not name the action. Do not leave the empty state without any action path — a blank page with no affordance is a dead end.
Differentiating the Three Core Scenarios
First-Use: Earn the First Action
The first-use empty state is an onboarding moment dressed up as a content problem. The copy has one job: make the first action feel small, safe, and obviously correct.
Effective patterns:
- Benefit-led explanation: instead of “No tasks yet,” try “Tasks help you track what needs doing across all your projects.” The second version explains the value before asking for effort.
- Show what full looks like: a subtle ghost or shadow of what filled content looks like (with a clear “sample” label) reduces the blank-canvas anxiety that stops new users cold.
- Reduce commitment language: “Start” implies a long journey. “Add your first task” implies one small action. Single atomic actions convert better.
What to avoid: enthusiasm that outpaces trust. “You’re going to love this!” assumes a relationship the product has not yet earned. Keep it confident and useful, not effusive.
User-Cleared: Acknowledge and Celebrate
The user-cleared state is often overlooked entirely. When a user empties their inbox, completes all their tasks, or pays off every invoice, the empty state is a success state — and it deserves to be recognized as one. Copy that treats this the same as a first-use state (“Nothing here yet”) is tone-deaf.
Well-known examples of this pattern done right:
- Inbox Zero: “All clear. Enjoy the moment.”
- A task app with all items completed: “You’re all caught up. Nice work.”
- A notifications panel with nothing unread: “You’re up to date.”
These messages are brief, validating, and do not push an action. The user accomplished something; the interface should acknowledge it and step out of the way. A persistent call to action in this state (“Add more tasks!”) is unwelcome and slightly anxiety-inducing.
No-Results: Narrow the Gap
A search or filter that returns nothing is a frustration moment. The copy must work hard to close the gap between what the user asked for and what the system can offer.
Effective patterns for no-results states:
- Echo the query: “No results for ‘invoic’ — did you mean ‘invoice’?” Spelling suggestions reduce dead ends significantly.
- Offer a widening path: “No projects match ‘archived client’. Try removing the status filter.”
- Explain the search scope: “We searched project names and descriptions. To search inside files, use Document Search.”
- Offer a creation escape hatch: “No contact named ‘Alice Huang’. Add Alice as a new contact.”
The worst no-results state is a blank area with no explanation of what was searched or what to try differently. The second worst is a long list of generic suggestions that have nothing to do with what the user actually searched for.
Error-Adjacent States: Loading vs. Truly Empty
A common source of user confusion is the gap between “there is nothing here” and “we failed to load what is here.” Modern practice requires distinguishing these states explicitly and handling the transition gracefully:
- Loading state: use a skeleton screen while content fetches. A skeleton (a gray placeholder that mimics the shape of real content) communicates “content is coming” without triggering a false empty-state message. This is the modern pattern; a generic spinner for all loading states is outdated.
- Failed load: show a specific, human-readable explanation and a retry affordance. “Couldn’t load your projects — check your connection and try again” is far more helpful than a blank area or a raw HTTP status code.
- Truly empty: only show the empty-state message after the load has completed successfully and confirmed there is nothing to show.
Getting this sequencing wrong creates a jarring experience: the user sees “No projects yet,” then their ten projects appear a second later. The explicit state machine — loading, error, empty, populated — is not just good engineering practice. It is a prerequisite for writing copy that is never misleading.
Copy Patterns by Product Context
Tone calibration matters. The same empty-state principle (“orient, explain, direct”) applies everywhere, but the register must match the product and the stakes:
| Product context | Empty-state register | Sample headline | Sample CTA |
|---|---|---|---|
| Professional tool (project mgmt) | Direct, functional | ”No tasks assigned to you" | "Create a task” |
| Consumer lifestyle app | Warm, encouraging | ”Your saved places are waiting" | "Explore and save a place” |
| Healthcare / finance | Calm, reassuring | ”No upcoming appointments" | "Schedule an appointment” |
| Developer tool | Precise, unsentimental | ”No API keys created" | "Generate an API key” |
| Social / community | Friendly, social proof | ”No posts yet — be the first to share" | "Write a post” |
The outdated tendency is to default to a quirky, illustrated empty state regardless of context. Playful mascots and witty copy in a legal contract tool erode trust rather than building it. Let the product’s core purpose determine the emotional register.
Accessibility and Technical Considerations
Empty states are often afterthoughts in accessibility audits, but they carry several requirements under WCAG 2.2:
- Focus management: if a user reaches an empty state via navigation (for example, clicking an empty inbox), focus should land on the empty-state region or its primary heading — not stay on the navigation element just activated.
- Announcements for dynamic states: if content is filtered down to zero results while the user is on the page, an
aria-liveregion should announce “0 results” so screen reader users are not left in silence waiting for content that will not come. - Contrast: empty-state illustrations and placeholder content must still meet WCAG 2.2 AA contrast ratios (4.5:1 for body text, 3:1 for large text and UI components). “De-emphasized” ghost content that falls below this threshold is a WCAG 2.2 violation regardless of design intent.
- CTA target size: the primary action button in an empty state should meet the WCAG 2.2 SC 2.5.8 target size minimum of 24x24 CSS pixels. A comfortable touch target on mobile is 44x44 CSS pixels.
On the technical side: avoid embedding empty-state copy inside JavaScript that only renders after a significant delay. Users on slow connections or assistive technology with slower rendering may see nothing at all — which is worse than a loading state.
Measuring Empty State Effectiveness
Empty states can and should be measured. Treating them as unmeasurable is a missed opportunity. Key metrics to track:
- Activation rate from empty state: what percentage of users who land on a first-use empty state take the primary action within the session? This is the headline metric.
- Time-to-first-action: if users take longer after a copy change, the new copy may be less clear even if the activation rate holds steady.
- Search refinement rate on no-results: do users refine their query after seeing the no-results message, or do they leave? A high refinement rate suggests the message is effectively guiding them.
- Support ticket correlation: a spike in tickets mentioning specific empty-state language is a direct signal that users are confused by that copy.
Behavioral data tells you whether the empty state is working. Qualitative sessions — even five think-aloud sessions — tell you why it is or is not. The combination of quantitative signal and qualitative explanation is the right evidence base for copy decisions. Self-report surveys asking “Did you find this empty state helpful?” are notoriously unreliable predictors of actual behavior.