Empty States Are a Conversion Surface, Not a Decoration

Most product teams treat empty states like a polite shrug — a little illustration, a friendly sentence, maybe a button. That's a waste. The empty state is often the first real screen a new user sees inside your product, and one of the highest-intent screens an existing user lands on when they click into a new feature. Treat it like a landing page, not a decoration.

Why empty states matter more than the dashboard

Think about who actually sees an empty state. New users on day one. Existing users exploring a feature they've never opened. Power users who just deleted everything in a list. In every case, the person is at a decision point: do I invest more time here, or do I bounce?

A full dashboard has gravity — there's data to look at, things to click. An empty state has none of that. Whatever signal you give the user in that moment is the entire experience. Get it wrong and you've spent acquisition budget to ship someone into a dead end.

In our experience auditing onboarding flows, the screens with the worst activation-to-action ratios are almost always empty states that were designed last, by whoever had a spare afternoon. That includes products from teams who otherwise care a lot about design.

The four jobs an empty state has to do

Before you open Figma, write down what this specific screen needs to accomplish. There are usually four jobs, and you should rank them.

1. Explain the feature — what is this list, board, inbox, or canvas for?
2. Reduce activation friction — how does the user get their first piece of content into it?
3. Set expectations — what will this screen look like once it's populated?
4. Offer a graceful exit — if this isn't relevant right now, where else can they go?

A pricing-page empty state ranks job 2 highest. A reporting dashboard empty state probably ranks job 3 highest, because users need to know what "good" looks like before they bother connecting data sources. A search results empty state ranks job 4 highest — the user already knows what the feature is, they just need to recover from a miss.

If you can't articulate the ranking, the screen will end up generic.

The "first content" question

For most product surfaces — projects, documents, contacts, campaigns — job 2 dominates. The single most important question is: how does the user get from zero to one item?

Your options, roughly in order of activation lift:

• Pre-populate a sample item the user can edit. Highest activation, but you need to mark it clearly as a sample and make it trivially deletable.
• One-click create from a template gallery. Works well when the feature has obvious archetypes (a CRM pipeline, a project board).
• Guided create flow with two or three fields. Better than a blank modal because the user sees progress.
• Single primary CTA to a blank create form. The default, and usually the worst-performing.
• Import from another tool. Powerful for migrations, useless for genuinely new users.

Picking the right option is a product decision, not a design decision. If your PM hasn't weighed in, the empty state isn't ready to build.

Copy is the actual design

The illustration is the cheapest part of the screen. The copy is the expensive part, and it's usually written in five minutes by someone trying to be charming.

A few rules we apply:

• Lead with the user's goal, not the feature name. "Track every deal in one pipeline" beats "Welcome to Deals."
• One sentence of explanation, maximum. If you need two, the feature is doing too much or your information architecture is wrong.
• The button label is a verb the user actually wants to do. "Create your first project" is fine. "Get started" is filler. "Add deal" is better than both if the user already knows what a deal is.
• No exclamation marks. Not one. They read as nervous.
• Don't apologize for the emptiness. "Nothing here yet!" puts the user in a deficit frame. "Your first campaign goes here" puts them in a forward frame.

Write the copy first, then design around it. If you design first, you'll end up writing copy to fit the layout, which is how you get "Oops, looks like there's nothing here!" plastered across every product on the internet.

A pattern that holds up in production

Here's a structure that works for most "list of things" empty states. It composes well, it's accessible by default, and it gives product the levers they need to A/B test without rebuilding the component.

type EmptyStateProps = {
  eyebrow?: string;          // optional category label
  headline: string;           // user-goal framing
  description?: string;       // one sentence, optional
  primaryAction: {
    label: string;
    onClick: () => void;
  };
  secondaryAction?: {
    label: string;
    href: string;             // usually docs or a template gallery
  };
  preview?: React.ReactNode;  // a faded sample of what 'full' looks like
};

export function EmptyState({
  eyebrow,
  headline,
  description,
  primaryAction,
  secondaryAction,
  preview,
}: EmptyStateProps) {
  return (
    <section
      role="region"
      aria-labelledby="empty-headline"
      className="mx-auto flex max-w-xl flex-col items-start gap-4 py-16"
    >
      {eyebrow && (
        <span className="text-xs font-medium uppercase tracking-wide text-muted-foreground">
          {eyebrow}
        </span>
      )}
      <h2 id="empty-headline" className="text-2xl font-semibold">
        {headline}
      </h2>
      {description && (
        <p className="text-base text-muted-foreground">{description}</p>
      )}
      <div className="mt-2 flex items-center gap-3">
        <button
          type="button"
          onClick={primaryAction.onClick}
          className="rounded-md bg-primary px-4 py-2 text-sm font-medium text-primary-foreground"
        >
          {primaryAction.label}
        </button>
        {secondaryAction && (
          <a
            href={secondaryAction.href}
            className="text-sm font-medium text-primary underline-offset-4 hover:underline"
          >
            {secondaryAction.label}
          </a>
        )}
      </div>
      {preview && (
        <div
          aria-hidden="true"
          className="mt-8 w-full opacity-40 pointer-events-none"
        >
          {preview}
        </div>
      )}
    </section>
  );
}

A few things worth calling out. The preview slot is where you render a faded version of the populated UI — a couple of fake rows, a sample chart, whatever. It does job 3 (set expectations) without a separate illustration. The aria-hidden matters: screen readers shouldn't announce sample content as if it were real. And the headline is the labelled region, not the button, so assistive tech gets a sensible landmark.

Accessibility traps that show up in empty states

Empty states tend to fail accessibility audits in predictable ways. Three to watch for:

• Decorative illustrations announced as images. If your empty state has an SVG, give it aria-hidden="true" unless the image is genuinely conveying information the text doesn't.
• Low-contrast "helpful" copy. Muted grey on white is a design cliché, and it routinely fails WCAG AA at body sizes. If your description text is below 4.5:1 contrast, it's not helpful, it's hidden.
• Buttons that look like links and links that look like buttons. When a user has to make a single decision, ambiguity is expensive. The primary action should be unmistakably a button, with a clear focus ring.

We wrote more about focus styling on the blog — the short version is that empty states are exactly where keyboard users land first, and exactly where teams forget to test with the mouse unplugged.

Measuring whether it worked

Empty states are testable. The metrics worth instrumenting:

• Activation rate from the screen — what percentage of users who land on this empty state create their first item within the session?
• Time to first item — median seconds from screen view to first successful create.
• Secondary action click-through — useful for understanding whether users are reading the screen at all.
• Bounce-from-empty — sessions where the user saw the empty state and then left the product entirely.

That last one is the metric most teams don't track and should. If 30% of new users hit an empty state and immediately close the tab, no amount of cleverness inside the rest of the product will save your retention curve.

When we redesign onboarding flows for clients — usually as part of a broader product engineering engagement — the empty state is often where we find the biggest single-screen lift available. Not because empty states are magic, but because nobody else has looked at them in two years.

Where we'd start

Pick the three highest-traffic empty states in your product. For each, write down the ranked list of jobs it needs to do, rewrite the headline and button label as if you were paying per word, and add a faded preview of the populated state. Ship it behind a flag, measure activation rate against the old version for two weeks, and keep whichever wins. That's a week of work, and it's almost always worth more than the next feature on the roadmap.