How to Design Empty States That Guide Users Instead of Confusing Them

The blank dashboard a new user sees the moment after signup is treated as an afterthought by most product teams, built last and reviewed least, even though it’s the exact moment when a user who just signed up decides whether the product is going to make sense to them or not. A generic “no data yet” message with nothing else is a design decision, whether or not anyone consciously made it — and it’s usually the wrong one.

Distinguish Between the Three Kinds of Empty States

Not every empty state is the same situation, and treating them identically is the first mistake. A first-run empty state (a brand-new user who’s never added anything) needs onboarding guidance — what to do first, why, and how. A cleared-out empty state (a user who deleted everything in a view, like an inbox at zero or a completed task list) needs a completion acknowledgment, not onboarding instructions the user already knows. A no-results empty state (a search or filter that returned nothing) needs help adjusting the query, not a call to action to add new data that has nothing to do with why the screen is empty.

Conflating these into one generic “nothing here” message misses the specific job each variant needs to do. A returning power user who filtered a report down to nothing doesn’t need to be told how to get started with the product — they need a suggestion to broaden their filter. Building each variant as a distinct state, not a single fallback message reused everywhere, is the foundational fix underneath everything else in this list.

There’s a fourth, less obvious variant worth designing for deliberately: the permission-restricted empty state, where a screen appears empty not because there’s no data, but because the logged-in user doesn’t have access to see it. This is common in team products where a new seat gets added to a workspace with existing data they can’t yet view due to permission settings. Treating this identically to a genuine first-run empty state is actively misleading — telling a permission-restricted user to “create your first project” when projects already exist but they can’t see them creates confusion and a support ticket, not progress. The correct message here explains the actual situation (“Ask an admin to grant you access to this workspace’s projects”) rather than defaulting to generic onboarding copy that doesn’t match what’s actually happening.

A Worked Example: Four Empty States for One Feature

Take a single reporting feature inside a marketing analytics tool and walk through what each of the four variants should say. First-run (a brand-new account, no campaigns connected yet): a single dominant button reading “Connect your first ad account” with a short line under it — “Takes about 90 seconds. We’ll pull in the last 30 days automatically” — setting both the action and the effort expectation in one glance. Cleared-out (a user who disconnected every ad account they’d previously connected): a distinct message acknowledging the deliberate action — “All accounts disconnected. Reconnect one to resume reporting” — rather than repeating the first-run onboarding copy verbatim, since this user already knows how the feature works and doesn’t need the 90-second framing again. No-results (a user filtered the report to a date range or campaign with no matching data): “No campaigns matched Jan 1–7 with spend over $500 — try widening the date range or lowering the spend filter,” naming the specific filters currently applied rather than a generic “no results found,” since the specific filter values are exactly what the user needs to know to fix the query. Permission-restricted (a newly added teammate without report access): “This workspace has 14 connected campaigns, but you’ll need report access from a workspace admin to view them” — explicitly confirming data exists, which prevents the new teammate from assuming the account itself is empty or broken.

The First-Run Empty State Is an Instruction, Not a Status Report

“You have no projects yet” is a status report — it tells the user what’s currently true, which they already knew, since they’re the one looking at their own empty account. It doesn’t tell them what to do about it. The first-run empty state needs to function as an instruction: a specific, single, prominent action (not three options, not a wall of text) that moves the user toward the product’s core value as directly as possible.

The bar for a good first-run empty state is whether a user who has never used the product before could look at just that screen, with no other context, and know exactly what to click next and roughly what will happen when they do. If the empty state requires the user to already understand the product’s mental model to know what action is appropriate, it’s failing its actual job, which is teaching that mental model to someone encountering it for the first time.

Show What “Full” Looks Like, Not Just What’s Missing

An empty state that only communicates absence — an icon, a sentence saying nothing exists yet, a button — misses the opportunity to show the user what success actually looks like once they’ve engaged with the feature. A sample or preview of populated state (a greyed-out example dashboard, a sample project with placeholder data clearly marked as an example) gives the user a concrete mental model of what they’re building toward, which is considerably more motivating and clarifying than an abstract instruction to “create your first project.”

This pattern works especially well for features whose value isn’t obvious from the name alone — a user might not intuitively know what a fully configured version of a specific dashboard or report actually looks like, and showing a realistic example removes the guesswork of imagining it from a text description alone. The key execution detail is making unmistakably clear that the example is a placeholder, not real data, since a sample that’s ambiguously real vs. fake creates its own confusion.

Reduce the Empty State to One Action, Even When Multiple Are Possible

A common overcorrection to a bare empty state is cramming it with every possible next action a user could take — import data, connect an integration, invite a teammate, create manually, watch a tutorial video — under the theory that more options serve more use cases. In practice, presenting five equally-weighted options to a user who doesn’t yet understand the product forces them to make a decision they’re not equipped to make, and decision paralysis at this exact moment is a common, avoidable cause of early drop-off.

The better approach is picking the single action most likely to lead to activation for the majority of new users, making that the dominant, unmissable call to action, and relegating the other legitimate paths (import, integrations, invite) to smaller, secondary links visible but clearly subordinate. This requires having enough usage data to know which path actually correlates with activation and retention — a decision informed by what happens after each starting path, not just a guess about which one sounds most appealing to present.

The Common Failure Mode: Designing the Empty State Before Knowing Which Path Actually Works

Teams frequently pick the dominant call-to-action for an empty state based on internal opinion — usually whichever path the product team is proudest of, or whichever feature a recent roadmap push emphasized — rather than based on which path new users who take it are statistically most likely to stick around and become active, retained customers. This produces a confident, well-designed empty state pointing users toward a path that looks impressive in a demo but doesn’t actually correlate with activation, while a less glamorous path (a plain CSV import, for instance) quietly outperforms it for the users who actually need to get moving quickly.

The fix requires a small amount of upfront analysis most teams skip: pull a cohort of users from the last few months and check, for those who took each of the available starting paths from the empty state, what percentage were still active 30 and 90 days later. It’s common to find the “impressive” path (a live integration, an AI-assisted setup) correlates worse with long-term activation than the “boring” path (manual entry, a simple template), often because the impressive path has more steps that can silently fail or more assumed technical context that a first-time user doesn’t yet have. Let this data, not internal preference, decide which action gets the dominant treatment.

Use the Empty State to Set Expectations About Time and Effort

A frequently overlooked function of a good empty state is expectation-setting about effort — a user staring at a blank screen with no sense of whether the next step takes 30 seconds or 30 minutes is more likely to abandon out of uncertainty than a user who’s told explicitly “this takes about 2 minutes” or “add your first three items to see this view populate.” Uncertainty about effort required is its own distinct source of drop-off, separate from confusion about what to do.

This is a small addition — often a single sentence — but it changes the psychological framing from an open-ended, potentially large task to a bounded, quick one, which measurably affects whether a user commits to starting versus closing the tab to “do it later,” which for most products means never.

Progressive Empty States Reduce Overwhelm in Multi-Step Features

For features that require several sequential steps before producing any value (connecting a data source, then mapping fields, then setting a schedule, for example), a single empty state trying to explain the entire multi-step process up front tends to overwhelm rather than guide. A progressive approach — showing only the next immediate step’s empty state, then revealing the next one only after the current step is complete — breaks a large task into a sequence of small, achievable ones, each with its own tightly scoped instruction.

This mirrors a broader principle in onboarding design: showing the entirety of what’s ahead rarely helps and often discourages, while showing exactly the next step, and only the next step, keeps a user’s cognitive load low enough that they actually complete each stage rather than assessing the whole multi-step process and deciding it looks like too much work to start.

Instrument Empty States Like Any Other Conversion Point

Empty states are frequently excluded from product analytics entirely, treated as a UI element rather than a funnel step worth measuring — yet the empty-state-to-first-action transition is exactly the kind of conversion point that would get rigorous instrumentation and testing if it happened later in a user’s journey. Tracking how many users who see a specific empty state actually take the suggested action, and how long they take to do it, turns empty state design from a one-time UI decision into something that can be measured and improved iteratively.

Teams that do instrument this often find surprising results — an empty state’s call-to-action copy or the specific example shown can move activation rate by a meaningful margin, on par with changes to much more heavily scrutinized parts of the funnel like the signup form itself. Treating the empty state with the same testing rigor applied to a landing page or signup flow, rather than as a static piece of UI that was designed once and never revisited, is usually the difference between an empty state that quietly leaks activation and one that actively drives it.

Sequencing an Empty-State Overhaul Across a Whole Product

A product with dozens of screens can’t rebuild every empty state at once, so prioritize by impact and traffic. Start with the single first-run empty state a new user encounters immediately after signup, since it affects 100% of new users and has the most leverage over whether they ever reach a second session at all — this is almost always worth fixing before any other empty state in the product, however unglamorous it feels relative to a more visible feature area. Second, address empty states inside whatever workflow your activation metric is actually defined around (the specific action that predicts long-term retention in your product), since these directly gate the metric the rest of the company is already tracking. Third, tackle no-results empty states in your highest-traffic search or filter interfaces, since these compound over a user’s entire lifetime with the product, not just their first session, and a confusing no-results state in a frequently used filter creates recurring friction long after onboarding is over. Lower-traffic, rarely-emptied screens (a settings page’s empty audit log, for instance) can reasonably wait, since the leverage of fixing them is small relative to the time spent.

What Good Actually Looks Like Once You’ve Fixed It

A well-designed set of empty states, measured against the instrumentation described above, typically shows three concrete signals: first-run activation rate (percentage of new signups completing the suggested first action) climbing into the 40-60% range for most B2B products with a reasonably intuitive core workflow, versus the 15-25% range common for a generic, unhelpful first-run state; time-to-first-action dropping to under two or three minutes for users who do convert, since a clear single instruction removes the deliberation time a cluttered multi-option state creates; and a measurable drop in support tickets referencing confusion about “why is this empty” or “how do I get started,” since a well-designed empty state answers these questions before a user feels the need to ask them. Tracking these three numbers before and after an empty-state redesign turns what’s often treated as a subjective design preference into a concrete, defensible improvement with numbers attached.