Designing an empty state that isn't a dead end.

Every screen in your app exists in two versions: the one in your mockups, full of beautiful data, and the one a brand-new user actually sees — blank. You designed the first one for months. The second one usually gets an icon, a gray caption, and a shrug. That's backwards, because the empty version is the one every single user meets first.

One name, four different screens

"Empty state" covers at least four situations that have almost nothing in common, and treating them as one screen is where most of the damage starts.

There's the first-run empty state: a new user, zero data, no idea how your app works yet. There's the cleared state: an established user who archived their last task or deleted their last draft — a moment of completion, not confusion. There's the no-results state: a search or filter that matched nothing. And there's the error state wearing an empty costume: the data exists, but the request failed. Four situations, four different jobs. A screen that says "No items" handles none of them.

Why "No items yet" fails

The default empty state — small icon, muted caption — fails for a specific reason: it describes the screen instead of the next action. The user already knows the screen is empty; they're looking at it. What they don't know is what this screen becomes, whether they did something wrong, and what to do next. The icon-and-caption pattern answers none of that, and its visual language — gray, centered, small — is the same language apps use for errors. To a first-time user, "No projects yet" reads uncomfortably close to "something's broken," and the exit is one swipe away.

There's a second, quieter cost. The empty state is often the first designed surface a new user studies at length — they linger there precisely because they haven't started yet. A placeholder screen tells them the app runs out of polish exactly where they are. It's the hotel lobby with unpainted drywall.

The three-part anatomy

Every empty state that works has the same skeleton, whatever the visual style:

1. Show the future, not the absence. The screen's job is to answer "what does this look like when it's working?" A small illustration of the filled state, a ghosted preview of a populated list, even a faded example card — anything that depicts the destination. This is why illustration became the convention: not decoration, but a picture of what the user is about to build.

2. One sentence of orientation. Not a features tour. One line that frames what lives here and why it'll be worth returning to: "Designs you're still working on show up here." Write it in the app's voice — this is a talking moment, and it's one of the few places users actually read.

3. Exactly one action. The single biggest upgrade you can make: put the button that creates the first item inside the empty state, even if the same action exists in a toolbar or tab bar. One button, primary style, verb-first label — "Start your first design," not "Get started." Two buttons is a decision; a decision is friction; friction on an empty screen is an exit.

The first-run state is onboarding in disguise

Most onboarding effort goes into carousels and tooltips that users skip on reflex. The first-run empty state is the onboarding surface they can't skip — they're standing on it. If your activation moment is "user creates their first project," then the empty project list is your activation funnel, and it deserves the same scrutiny as a checkout flow. We made this argument the long way in the first-session retention post: users decide whether to come back before their first session ends, and the empty screens are where most of that first session happens.

This is also where sample data earns its keep — carefully. A templates gallery, a demo project marked as such, or a "try it with an example" path can carry a user over the cold-start hump in tools where the first real item is expensive to create. The rule: sample data must be obviously disposable and one tap from gone. In apps holding personal data — health, money, journals — skip it entirely; a screen pre-filled with someone else's life reads as creepy, not helpful.

No results is a different job

The no-results state has one rule: never a dead end, and never blame. The user did nothing wrong; your catalog just didn't match. So do the work for them — say what was searched, offer the out ("Clear filters"), and where you can, suggest the nearest thing that does exist. A no-results screen with a "clear filters" button is a bump in the road; one without it is a wall, and users don't climb walls, they leave.

And keep errors visually distinct from emptiness. "You have no exports" and "we couldn't load your exports" are opposite messages — one is an invitation, the other needs a retry button. If your loading failure renders the same screen as a fresh account, users with full libraries will believe their data is gone. That's not a hypothetical; it's one of the classic ways apps earn a one-star "lost all my work" review over a flaky connection.

Worth painting

When we rebuilt ShotCanvas's design system, the empty states got the same treatment as the paying screens: each one has painted artwork, a one-line subtitle in the app's voice, and a single button — the library's is "Start your first design." That last question in the checklist is the reason: your emptiest screen still gets screenshotted, still shows up in reviews, and for every new user it is the app. It should look like you meant it.