The most neglected screen in most applications is the one users see first. Before any data has been entered, before any content has been created, before any connections have been made – there is the empty state. A blank table. An inbox with zero messages. A dashboard with no metrics. A project board with no tasks.
Most applications handle this moment poorly: a bare container with no data rows, or worse, a technical error message like “No records found.” This is the moment the user is most uncertain, most likely to abandon, and most in need of guidance. A well-designed empty state transforms that moment of blankness into a moment of clarity, motivation, and direction.
Why Empty States Matter More Than You Think
Empty states are not edge cases. They are guaranteed touchpoints. Every new user encounters them. Every user who creates a new project, a new workspace, or a new category encounters them. Users who archive or delete content encounter them. Users who apply filters that return no results encounter them.
The numbers make the case. Appcues found that 40-60% of users who sign up for a SaaS product never return after their first session. A significant portion of that drop-off happens because the first session ends in an empty state that provides no direction. The user signed up because a marketing page promised them value. They logged in and found a blank screen. The gap between the promise and the experience was too large, and they left.
Empty states are also disproportionately visible during product demos. When a sales representative shows the application to a prospect, they often create a new workspace to demonstrate the setup flow. If that workspace opens to a barren dashboard with placeholder text, the demo starts on the wrong foot. The prospect’s first impression is emptiness, not capability.
Investing in empty state design has an outsized return because it directly affects activation rates, first-session retention, and the overall perception of product quality.
The First-Use Empty State: Onboarding in Disguise
The most important empty state is the one a new user encounters immediately after signing up. This is not just a blank screen – it is an onboarding surface. The empty state should accomplish three things:
Orient the user. Tell them where they are and what this area of the application is for. “This is your project dashboard. It will show all your active projects, their status, and upcoming deadlines.” This single sentence eliminates the ambiguity of a blank screen.
Show what success looks like. Display a preview or illustration of what the screen will look like once it has data. A lightly styled mockup of a populated dashboard – with sample project cards, a timeline, and a status summary – gives the user a mental model of the end state. This is not real data. It is an aspirational image that answers the question “What will this look like when I am using it?”
Provide a single, clear next action. One button. Not three. Not a list of options. One: “Create your first project.” The cognitive load of choosing between multiple actions paralyzes new users. Give them one clear path forward, and make the button visually prominent – large, high-contrast, impossible to miss.
Basecamp’s empty project screen is a good reference. It shows a friendly message (“No projects yet”), a brief description of what projects are for, and a single “Create a new project” button. There is no ambiguity about what to do next.
For applications where the first action is complex (setting up an integration, importing data, configuring preferences), break it into a numbered checklist. “Step 1: Connect your Salesforce account. Step 2: Choose which objects to sync. Step 3: Review your first data import.” Show progress as each step completes. Checklists with visible progress have a 45% higher completion rate than unstructured onboarding, because people are motivated by incomplete progress bars – the Zeigarnik effect in action.
The No-Results Empty State: Preventing Dead Ends
When a user searches for something and gets no results, or applies filters that exclude all records, the default behavior in most applications is to show an empty table with the text “No results.” This is a dead end. The user does not know why there are no results or what to do about it.
A well-designed no-results state addresses four things:
Acknowledge what the user did. “No projects match ‘acme renewal’.” Repeat the search query or active filters so the user can verify they searched for the right thing.
Suggest corrections. If the search term is close to a known term, suggest it: “Did you mean ‘Acme Renewal Project’?” If there are active filters that might be too restrictive, point it out: “Try removing the ‘Completed’ status filter to see all projects.”
Offer alternative paths. “Search all workspaces instead of just this one” or “Browse projects by category” or “Create a new project called ‘acme renewal’.” The user came to this screen with intent. Help them fulfill that intent through a different path rather than leaving them at a blank wall.
Avoid blame language. “No results found” is neutral. “Your search did not match any records” subtly implies the user did something wrong. “We could not find anything matching ‘acme renewal’” acknowledges the gap without attributing blame.
Shopify’s admin search handles this well. A search that returns no results shows the query, suggests checking for typos, offers to search in different sections (products, orders, customers), and provides a link to create a new item matching the search term.
See also: How to Run a Design Sprint for Product Development
The Cleared Empty State: Celebrating Completion
Some empty states are achievements. An inbox with zero messages, a task list with no remaining items, a bug tracker with no open issues – these are moments of completion that deserve recognition, not a blank screen.
The cleared empty state should celebrate the accomplishment. A simple illustration (a completed checkbox, a tidy desk, a sunrise) paired with a congratulatory message (“You’re all caught up” or “All tasks complete”) transforms the empty state from a void into a reward. This positive reinforcement encourages the behavior that led to the cleared state.
Pair the celebration with a gentle suggestion for what to do next. “All tasks complete. Review tomorrow’s schedule?” or “Inbox zero! Here are three projects that could use your input.” The user has momentum from clearing their queue. Channel that momentum toward the next productive action rather than letting them drift.
The tone should match your product’s personality. A project management tool might use a clean, professional illustration. A consumer app might use a playful animation. A financial application might skip the illustration entirely and use a simple checkmark with clean typography. The emotional register should be consistent with the rest of the experience.
Empty States in Data-Heavy Applications
Dashboards, analytics pages, and reporting interfaces have a particular empty state challenge: they depend on data that may take time to accumulate. A new user’s analytics dashboard will be meaningless for the first few days or weeks because there is insufficient data to show trends, averages, or comparisons.
Instead of showing blank charts with zero values (which looks broken) or hiding the charts entirely (which hides the product’s value proposition), show the chart structure with an explanatory overlay: “Revenue trends will appear here after your first week of data.” This teaches the user what the dashboard will show, sets an expectation for when it will become useful, and demonstrates the product’s analytical capabilities even before there is data to analyze.
For metrics that require a minimum data threshold, be explicit: “Customer retention analysis requires at least 30 days of data. Check back after December 15.” Specificity builds trust. “Not enough data” feels like a bug. “Requires 30 days of data – available December 15” feels like a feature that is loading.
Where appropriate, populate charts with sample data and label it clearly: “Sample data shown. Your data will replace this once available.” This approach lets the user interact with the dashboard immediately – clicking through charts, exploring filters, understanding the layout – so that when real data arrives, they already know how to use the interface.
Designing Empty States Systematically
Most applications have 15-30 distinct empty states: one for each major data type, each list view, each dashboard widget, and each search context. Designing them ad hoc leads to inconsistency. Design them systematically.
Create an empty state component library with three variants:
- First-use (illustration + description + primary CTA)
- No-results (search context + suggestions + alternative paths)
- Completion (celebration + next action)
Each variant should have consistent spacing, typography, and illustration style. The illustration set does not need to be large – six to eight custom illustrations (one per major product area) are sufficient for most applications. Avoid generic stock illustrations of people sitting at computers. Invest in illustrations that are specific to your product and your brand.
Audit every screen in your application for empty states. For each one, determine which variant applies, write the copy, and assign the illustration. Build the empty states into your component library so that new features automatically inherit the pattern. Add empty state screenshots to your design review checklist so they receive the same scrutiny as populated screens.
Test empty states with new users. Run a five-second test: show the empty state for five seconds, then ask the user what the screen is for and what they would do next. If they cannot answer both questions confidently, the empty state needs work.
If your application’s first impression is a blank screen, there is a significant opportunity to improve activation and retention. Get in touch and let’s design empty states that guide your users from sign-up to success.