That blank screen is doing more work than most teams realise. Research from the Nielsen Norman Group found that blank interfaces create genuine confusion about whether content is loading, filtered, or simply broken — and users often refresh the page repeatedly before trusting what they're seeing.
An empty state isn't missing content. It's a product surface, one that confirms the system is working, teaches the interface, and points toward first value. This guide covers how to tell empty-state scenarios apart, write copy and CTAs around actual user intent, decide when starter content helps, and test the full experience before it ships.
Key Takeaways
- A blank screen without context reads as broken, not empty — explain the state explicitly
- Match copy structure to "what's happening → why it matters → what to do next"
- Use starter content only when the product is too complex to understand empty
- Build empty states into your design system, not as one-off mockups
- Measure each state against its own metric: activation, completion, or recovery
What Is an Empty State in UX?
An empty state is any screen, panel, list, table, or component with no content available to display. According to the Carbon Design System's pattern library, this commonly happens on first use or after data has been deleted or is temporarily unavailable.
"Empty" does not mean the UI should be visually or functionally blank. A first-time user staring at a bare dashboard needs answers to several questions at once:
- Where am I right now?
- What's supposed to live in this space?
- Is the product actually working?
- What single action makes this space useful?
A generic "No data" message answers none of these. It just confirms the obvious while leaving the user guessing about everything that matters.
The States You Need to Map Separately
Not every empty screen is the same problem, and treating them identically is where most teams go wrong. Before designing a single screen, map these five states:
- First-use state: The user hasn't created, connected, uploaded, or configured anything yet
- Loading or processing state: The system is still fetching or calculating — showing this as "empty" too early is a common, documented mistake
- No-results state: A search or filter returned nothing and needs recovery options
- Permission or access state: Content exists but the user can't see it due to role, workspace, or plan restrictions
- Completion state: The user cleared a queue or finished a workflow — this is a positive outcome, not a problem to fix
This article focuses mainly on first-use states, since that's where most activation is won or lost. But misclassifying any of these five leads to the same failure: confusing copy, a misplaced CTA, and system feedback that actively misleads the user.
Design Principles for a First-Time-User Empty State
Every first-use empty state should answer one unspoken question immediately: "What can I do here?" A clear headline, one short explanation, and a single obvious next step handle this better than any amount of polish.
Write Copy With a Clear Structure
Use this sequence: what's happening, why it matters, what to do next. Replace vague phrases like "Nothing here yet" with language that names the actual feature.
Compare:
- Weak: "No data yet"
- Better: "No carbon-removal batches logged. Connect your sensor feed to start tracking emissions in real time."
The second version names the feature, implies why it matters, and tells the user exactly what to do.
Match the CTA to the Fastest Path to Value
The primary CTA should lead to whatever gets the user to first value fastest. Common paths include:
- Creating a project
- Connecting a data source
- Inviting a teammate
- Importing existing work
- Exploring a guided example
If several next steps are plausible, pick the one most users will actually need and make everything else secondary.
Decide When Starter Content Earns Its Place
Sample data or templates help when a product is complex or data-heavy enough that an empty interface is genuinely hard to interpret. Use it when:
- The product involves dashboards, charts, or multi-step configurations
- Seeing a populated example clarifies what "done" looks like
- You clearly label it as sample content and offer an easy switch to real data
Skip starter content when the first action is simple or personal: something only the user can provide, like their own name, logo, or first dataset. In that case, a direct creation flow beats a demo every time.
Build It Into the Design System, Not a One-Off Screen
Empty states shouldn't live as isolated Figma frames designed once and forgotten. We've seen this firsthand building interfaces for climate tech products.
When empty, loading, and error variants are defined alongside populated components in libraries for energy charts and sustainability widgets, shared spacing, typography, and design tokens keep the whole interface consistent instead of patchy.
That consistency pays off directly. One carbon-footprint tracking platform cut average time on task from over 10 minutes to under 5 minutes after adding auto-fill, real-time data syncing, and streamlined navigation. Those gains only stick when every state of the interface, including the empty ones, is designed with the same rigor as the populated screens.
A Step-by-Step Workflow for Designing the Experience
Designing empty states well is less about individual screens and more about a repeatable process.
Inventory every first-use empty state. List every screen that can appear empty: dashboards, tables, search, integrations, notifications, reports, and settings. Document the user goal, trigger, eventual content, and best next action for each. Add loading, error, no-results, and permission variants so first-use messaging never lands in the wrong state.
Identify the user's starting context. A brand-new account is not the same as an experienced user hitting a newly enabled feature. Use onboarding answers or role data only when it genuinely sharpens the recommendation, not just because the data exists. Decide upfront whether the user should create, connect, invite, import, or explore a sample.
Build the content and interaction structure. Each empty state needs:
- A direct headline naming the feature
- Supporting text on what will appear and why setup is worth it
- A primary action into the shortest relevant workflow
- One lower-commitment path: template, sample dataset, or docs link
Design the transition into populated content. Specify the confirmation or progress feedback that appears after the CTA. If the action opens a separate flow, return users to the original screen with new content visible. Plan for incomplete setup, failed imports, delayed processing, and users who dismiss the suggestion.
Collaborate across design, product, content, and engineering. An empty state implemented as real state logic behaves very differently from one treated as a static mockup pasted into a ticket.
That last point is where a lot of teams underestimate the lift involved. When we worked on UX design and product strategy for Vested Futures, empty and loading states sat inside the same responsive Figma system as every other screen state.
That let engineering implement real state logic instead of guessing at intent. As our co-founder Tejas Mahajan puts it, every screen is a business decision, not just a design problem, and that's especially true for the states most teams skip over.
Common Empty-State Mistakes to Avoid
A handful of mistakes show up repeatedly across products, and most are avoidable with a quick audit:
- Leaving a screen blank with an unexplained icon. Confirm the product is working and say what belongs in the space.
- Showing "No data" while content is still loading. Users often read this as a finished empty state, so use a loading state with a progress signal instead.
- Reusing first-time copy across unrelated states. A no-results message needs different language than a permissions error or a completed workflow.
- Writing vague, apologetic, or overly technical copy. Keep brand personality only where it doesn't delay comprehension.
- Overwhelming new users with multiple CTAs or dense tutorials. One primary action beats three competing ones.
- Forcing every user through the same setup path. Some users want to import existing work or skip ahead; give them that option.
Testing, Accessibility, and Measurement
Test the Full Journey, Not Just the Screen
Watch first-time users (and colleagues unfamiliar with the product) interact with the empty state. Ask what they think it means, what they expect, and what they'd click first.
Then test the complete path: signup through first login through first successful action, including slow networks, delayed processing, and failed setups.
Meet Accessibility Requirements by Default
Empty states carry the same accessibility obligations as any other screen. Under WCAG 2.2, status messages that appear without a focus change or page reload, such as "No results found," must be programmatically announced so screen reader users aren't left uninformed. Beyond that:
- Meet standard contrast requirements for text and essential icons
- Give icons and buttons descriptive accessible names
- Preserve the headline, explanation, and primary CTA in responsive layouts, without burying them under decorative scrolling
Measure the Metric That Matches the State
A single conversion number won't tell you much. Match the metric to the state:
| State | What to track |
|---|---|
| First-use | Activation or first-value event |
| Setup | Completion rate, abandonment, time to complete |
| No-results | Recovery actions (cleared filters, new query) |
| Delayed/processing | Abandonment during wait, successful return after |
Matched metrics make the gap visible. Climeworks introduced a dashboard with real-time CO2-removal data alongside personalised onboarding and targeted communication, and reached a 35% adoption rate within the first month. That lift came from guiding first-time users toward a specific action rather than leaving them to figure things out.
Pair these numbers with qualitative feedback to understand why a CTA gets ignored: unclear copy, too much friction, unclear value, or a system that isn't giving feedback at all.
Wrap-Up: Treat Empty States as Guided Product Moments
A well-designed first-use empty state does two things at once: it removes uncertainty about whether the interface is working, and it turns an inactive screen into a clear path toward first value.
Before launch, run through this checklist:
- Identify the state correctly (first-use, loading, no-results, permission, or completion)
- Explain what the user is seeing, in plain language
- Provide one relevant action, with an optional lower-commitment alternative
- Support accessibility requirements by default, not as an afterthought
- Test the full transition from empty to populated
For climate tech and deep tech products especially, where the underlying science is already complex, the first blank dashboard either builds user confidence or erodes it. Audit every screen that can be empty, and design its full journey — not just its best-case appearance — before it ships.
Frequently Asked Questions
What is an empty state in UX design?
An empty state is a screen or component with no content currently available to display, such as a dashboard, table, or panel before any data exists. It still needs a clear explanation and a next step, not just a blank space.
How do you design an empty state for first-time users?
Give the user clear context about where they are, a specific explanation of what belongs there, and one primary next action. Offer an optional secondary route, like sample data or an import option, for users who aren't ready for the main flow.
What should an empty state include?
Include a descriptive headline, a short supporting explanation, a relevant visual cue, and one primary action. Where useful, add a secondary, lower-commitment path such as a template or documentation link.
What is the difference between an empty state and a loading state?
An empty state means no content is currently available to show. A loading state means the system is still fetching or processing data, and should never be mislabeled as empty before it's finished.
Should empty states use sample data?
Sample data helps when a product is complex enough that an empty screen is hard to interpret without context. Label it clearly as sample content and make switching to real data simple, so users never mistake it for their own.
How do you measure whether an empty state is effective?
Match the metric to the state: activation events for first-use screens, completion and abandonment rates for setup flows, and recovery actions for no-results screens. Combine these numbers with direct user feedback on what confused them.
