Designpixil

Designpixil · SaaS Design

SaaS Empty State Design: Why It Matters

Why empty states are activation moments, not afterthoughts. Five patterns for effective empty state design across new user, no results, and error scenarios.

Anant JainCreative Director, Designpixil·Last updated: March 2026

Empty states are the screens most SaaS products ship last and think about least. They're the blank tables with no rows, the dashboards with no data, the search results with no matches. Design teams build the populated screens — the ones with real data in them — and treat the empty version as a fallback they'll clean up later.

That's exactly backward. For a new user, every screen they visit starts empty. Every table, every dashboard, every list shows them nothing on day one. The empty state is not a rare edge case — it's the most common experience your newest, most important users have.

And your newest users are the ones you most need to retain.

What an Empty State Actually Is

"Empty state" is a catch-all term for several distinct situations, each with a different design requirement:

New user / first run: The user has just signed up and hasn't created any content or connected any data. This is the most high-stakes empty state — it's the first impression of the actual product experience, beyond the marketing and onboarding flow. It needs to explain the value of the screen and give a clear first action.

No results: The user searched for something that doesn't exist, or applied a filter that returns zero results. This is a different problem — the user had intent, took action, and found nothing. The design should acknowledge what they searched for, explain why it returned nothing, and help them adjust their search.

No data yet: The user has completed setup but the data hasn't come in yet. They've connected an integration, imported a file, or kicked off a process — but the results aren't ready. This empty state needs to communicate that something is happening and set a realistic expectation for when data will appear.

Error state: Something went wrong, and the screen can't show data as a result. This is technically an empty state, though it's usually treated as a distinct design problem. The design needs to explain what failed and what the user can do about it.

Each of these needs its own design treatment. A generic "No data here" message serves none of them well.

Why Empty States Are Activation Moments

The activation moment in most SaaS products requires users to take some action — import data, create a record, connect an integration. That action turns an empty state into a populated state. So by definition, the moment a new user sees an empty state is often the moment that's one step before activation.

If the empty state is a blank screen with no guidance, many users will stall. They don't know what to do, they're not confident they're in the right place, and the product feels broken or incomplete. They might click around for a minute, find nothing that helps, and leave. That session ends without activation. The retention curve for that user just started declining.

If the empty state is well designed — explaining what belongs here, showing a preview of what it will look like populated, and providing a single clear next step — users take the action, see the populated state, and experience the product's value for the first time. That's activation. That user's retention curve looks completely different.

The delta between these two outcomes is not a small number. A meaningful improvement to your new-user empty states typically improves activation rates by enough to notice in your monthly cohort data within 60 days.

5 Patterns for Effective Empty States

Pattern 1: The "Show What's Coming" Empty State

The most effective approach for new-user empty states: show a preview of what the populated state looks like, using illustrative placeholder data.

This does two things. First, it sets a concrete expectation — users can see exactly what they'll get when they complete the action. Second, it makes the screen feel like a product rather than an error. A table with greyed-out placeholder rows and a "Get started by importing your contacts" call to action feels intentional. A blank table with no explanation feels broken.

The visual treatment matters: placeholder data should be clearly recognizable as placeholder (greyed out, with a distinct visual treatment), not mistakable for real data. Users who mistake example data for their actual data are confused and annoyed when they realize it isn't theirs.

Pattern 2: The "Single Next Step" Empty State

Every empty state should have exactly one primary call to action. Not two. Not a list of three ways to get started. One.

Decision paralysis is real. When users are presented with multiple paths forward in an unfamiliar product, they often take none. A single, clearly labeled action — "Import your first contacts," "Create your first project," "Connect your data source" — tells the user unambiguously what to do next.

The secondary information (the explanation of what this screen does, the benefits of filling it up, the link to documentation) should be visually subordinate to the primary action. If a user's eye goes to the help text before the action button, the hierarchy is wrong.

Pattern 3: The "Progress Acknowledgment" Empty State

For screens where data is loading, processing, or being synced rather than waiting to be created, the empty state design needs to communicate that something is happening.

This is distinct from the new-user empty state. The user has already taken the required action — they've connected the integration, triggered the import, submitted the form. Now they're waiting. An empty screen with no indication that anything is happening creates anxiety. Users start wondering if something went wrong, or if they did the right thing.

A progress acknowledgment empty state includes: confirmation that the action was received ("Your CRM sync is in progress"), a realistic time expectation ("Data usually appears within 15 minutes"), and an optional next step to take while waiting ("In the meantime, set up your workspace preferences").

If you have a way to notify users when the data is ready — via email or an in-app notification — mention it in this empty state. It's useful and it's a chance to set up a re-engagement touchpoint.

Pattern 4: The "Helpful No Results" Empty State

When a user searches or filters and gets zero results, the worst response is a generic "No results found." The best response is specific to what they searched for.

"No contacts found for 'acme corp'" is more useful than "No contacts found." It confirms what the search term was (preventing confusion about whether the search actually executed) and anchors the problem clearly.

Beyond specificity, give users actionable options:

  • Suggest adjusting the search term or clearing specific filters
  • Offer to show them related items if similar results exist
  • If the thing they searched for genuinely doesn't exist yet, offer to create it

That last option — "No projects named 'Q4 Launch' found. Create it?" — is a powerful pattern for products where users frequently create new records. It converts a failed search into a creation action, which is exactly what many users intended when they searched.

Pattern 5: The "Error with Recovery" Empty State

Error states that leave users stranded are one of the most consistent sources of support tickets and quiet abandonment. A user who hits a data loading error and sees "Something went wrong" with no next step will either open a support ticket or leave. Both outcomes are expensive.

Error empty states should include:

  • What failed, specifically ("We couldn't load your account list")
  • Why, if you can say it ("Your authentication token has expired")
  • What to do ("Reconnect your account" with a link to do exactly that)
  • A way to reach support if none of the above resolves it

An error state that gives users the information and tools to self-resolve is dramatically more effective than one that hands the problem back to them without context.

What Not to Do

Blank screens. A screen with literally nothing on it — no illustration, no text, no call to action — is the worst empty state. Users don't know if the product is broken, if they're in the right place, or what to do. This should not exist in any shipping SaaS product, but it's surprisingly common in products that built features quickly without thinking about the zero state.

Generic messages that apply to every screen. "No data here. Get started by exploring the product." tells the user nothing about what this specific screen does or what specific action will fill it. Empty state copy should be specific to the screen it appears on.

No visual distinction between empty and populated states. If the empty table looks almost identical to a populated table (same columns, same chrome, just no rows), users may not immediately understand that the absence of rows is meaningful. Visual differentiation — a distinct empty state illustration, a different background treatment, a clear "this is empty" visual signal — helps users understand what they're looking at.

Multiple competing calls to action. As noted above: one primary action per empty state. Secondary options can exist, but they should be visually subordinate.

Hiding the empty state behind a loading spinner forever. If data is loading slowly, show a loading state for a defined period and then surface the empty state (or an error state) if data still hasn't appeared. Perpetual loading spinners create confusion about whether there's a problem.

Applying This to Your Product

Audit your product by logging out and creating a fresh account. Navigate to every major screen. Document what you see. The number of undesigned empty states in a shipping SaaS product is almost always higher than the team expects.

Then prioritize: which empty states are most frequently encountered by new users? Which screens are on the critical path between signup and activation? Those are the empty states to design first.

Good empty state design is not glamorous work. It doesn't make it into product demos or marketing screenshots. But it is consistently one of the highest-leverage design investments you can make in the first 90 days of a user's lifecycle.

For a deeper look at how empty states fit into the broader SaaS onboarding flow design, that post covers how each pattern connects to your overall activation strategy.


Frequently Asked Questions

Should empty states have illustrations?+

Illustrations help when they add information — showing what the populated state looks like, or representing the type of content that belongs in the screen. They add visual clutter when they're purely decorative. A small, purposeful illustration that previews the populated state is valuable. A large, cheerful illustration that doesn't communicate anything specific is noise. If you're resource-constrained, skip the illustration and focus on clear, specific copy and a strong call to action.

How do we handle empty states for users with different permission levels?+

If a user sees an empty screen because they don't have permission to view the content — not because there's no content — that's a different design problem. The message should acknowledge the permission gap, not pretend the content doesn't exist. "Your team has 12 projects, but you haven't been added to any yet. Ask your admin to assign you to a project" is much more useful than a generic empty state that implies no projects exist.

Should we use sample data to fill empty states?+

Sample data that users can interact with is valuable in specific contexts — particularly for complex products where seeing live data is the only way to understand the product's value. The critical requirement: make it completely unambiguous that the data is a sample. Prominent "Sample data — connect yours to get started" banners, visual differentiation, and clear calls to action to replace the sample data with real data are all necessary. Sample data that users mistake for their own data is a trust-destroying experience.

How do we measure whether our empty state improvements are working?+

Track the conversion rate from the empty state to the completion of the primary action (the call to action on the empty state). If you can't track this exactly, proxy it with the percentage of new users who complete the first key action within their first session. You can also compare activation rates (reaching your defined activation moment) between cohorts who encountered the old and new empty states. These metrics will show whether the redesigned empty state is doing its job.

We have dozens of empty states across our product. How do we prioritize which to design first?+

Map your empty states to the user journey and prioritize by frequency and criticality. The most important are empty states on screens that new users encounter in their first session, especially on the path between signup and activation. Secondary priority goes to empty states on high-traffic screens that existing users encounter regularly. Tertiary are states in settings, admin panels, or rarely-visited features. Fix the critical path first, then work outward.

Work with us

Senior product design for your SaaS or AI startup.

30-minute call. We look at your product and tell you exactly what needs fixing.

Related

← All articles