The Empty State Is the First Thing Your User Sees. Most Apps Waste It.

Part eight of a series on building software people don’t quietly hate. We’ve covered what your app says while it’s thinking, when it’s wrong, and where it says it. Now: what it says when there’s nothing there yet, the screen most builders forget, and the one new users see first.

Empty doesn’t have to mean broken. Done right, a blank screen is an invitation, not a void.

Here’s a strange truth about building software: the screen you spend the least time thinking about is often the first one your user ever sees.

We’ve spent this whole series on the dramatic moments, the loading states, the errors, the failed forms. The screens where something is happening, or something has gone wrong. But there’s a quieter screen that almost every app gets wrong, and it’s the one a brand-new user lands on the very first time they open your app:

The empty state.

The blank dashboard. The list with nothing in it. The “no results found.” As builders, we don’t think about these much, because we’re busy thinking about features, the exciting stuff, the thing the app does once it’s full of data. The empty state feels like a placeholder, a void where the real content will eventually go. So we leave it blank.

And blank is exactly the problem. Because, as I’ve said since part one, you know your app from the inside, you’ve never actually seen it empty, because your version is full of test data. Your brand-new user sees it with nothing in it, on day one, before they’ve done anything. That blank screen is their first impression. Let’s not waste it.

The blank dashboard the most common own-goal in software

Picture the most common version of this. A user signs up, they are interested enough to create an account, which is a small miracle in itself, and they land on the dashboard.

It’s blank.

“You have no projects.” Nothing else. No button, no guidance, no next step. Just an empty container and a user standing in it, wondering what they’re supposed to do. They came in with momentum, and you’ve handed them a dead end on the first screen. This is the moment a lot of sign-ups quietly become non-users, not because the product is bad, but because the first thing it did was nothing.

The fix is almost insultingly simple. Give them an action. “Create your first project,” with a button right there. Now the blank screen isn’t a void, it’s a starting line. The user knows exactly what to do because you told them.

You can go further, and the good apps do. Turn that first action into a little guided sequence, a step-by-step, lightly gamified onboarding that walks the user through setting up the thing they came to set up. A checklist they can tick off, a sense of progress on a screen that, thirty seconds ago, was empty. You’ve converted the worst moment in the app, I don’t know what to do — into the best one. Oh, this is easy, look at me go.

And the rule generalizes to every empty corner of your app: for any section that doesn’t have content yet, never just leave it blank. Tell the user what the section is for and how to start using it. An empty “Messages” tab should say what messages are and how to get one, not just sit there void. Every blank space is a chance to orient the user instead of stranding them.

A blank dashboard is a dead end. The same screen with one clear action becomes a starting line.

Empty search results keep the user moving

There’s a subtler empty state that almost everyone ships badly: the empty search result.

The user searches for something, and there’s nothing. The lazy version just says “No results.” And look — “No results” isn’t a disaster. It’s honest. But it’s a dead stop. The user hit a wall, and you’ve given them nothing but the wall.

The better version keeps them moving. “No results for ‘purple shoes.’” echo back what they actually searched, so they know the search worked and just came up empty, rather than wondering if something broke. Then hand them a way forward: a link to search that term in a broader category, a suggestion to check the spelling, a nudge toward related results, something that turns the dead end into a fork in the road. A great empty search result doesn’t just report the absence of results, it gives the user their next move.

The principle here is the same one that’s run under this whole series: don’t strand the user. A blank “No results” strands them. A “No results for X, try this instead” keeps them in motion.

When the goal is empty, make it feel like a win

Here’s the plot twist that makes empty states genuinely fun to design: sometimes the empty state is the thing the user is trying to achieve.

The cleared inbox. Inbox zero. The user has spent twenty minutes triaging email, and they finally hit the bottom, with zero unread, nothing left. That empty state isn’t a failure. It’s a victory. And most apps render that hard-won moment as the same depressing blank space they’d show an error.

Don’t waste it. When someone clears everything and hits zero, make it feel like an achievement. A nice animation. A satisfying little illustration. A background they actually look forward to seeing. Some of the best-loved apps in the world built genuine affection out of exactly this — a reward screen for reaching empty, so that “empty” becomes something the user wants to get back to.

Same screen state — nothing to show — but a completely different emotional job. An empty dashboard on day one needs to say, “here’s how to start.” An empty inbox after a cleanup needs to say, “Well done, go enjoy your day.” The data is identical. The message is opposite. Knowing which one you’re building is the whole skill.

Sometimes empty is the win. Inbox zero should feel like an achievement, not the same blank space you’d show an error.

The empty-state cheat sheet

Three jobs every empty state has to do, no matter which kind it is:

• Tell the user why it’s empty — “no projects yet,” “no results for X,” “you’re all caught up.” Name the emptiness so it reads as intentional, not broken.
• Show them what to do next — a button, a link, a suggestion. Never a dead end. Even “inbox zero” can say “here’s what’s next.”
• Never let it feel broken — a blank screen with no text reads as a bug. An empty state with a message reads as a designed moment. The difference is whether you bothered to fill the void with words.

And the quick taxonomy of which empty state you’re building:

• First-run blank (dashboard, new account)? → Orient and onboard. “Create your first project.” This is your first impression — spend on it.
• Empty search results? → Echo the query, keep them moving. “No results for X, try this.”
• Empty as the goal (inbox zero, all tasks done)? → Celebrate it. Make reaching empty feel earned.

The mistake is treating all three as the same blank screen, when they’re three completely different emotional moments that happen to share zero rows of data.

And the refrain you’ve heard every part of this series: if you’re vibecoding this, the empty state is one of the very first things the AI skips. It builds the dashboard full of sample data, the happy path, always the happy path, and never shows you the screen a real new user sees on day one, because in the demo, there’s always data. So you ship a beautiful app with a blank, broken-feeling front door, and you never even notice, because you’ve never logged in with an empty account. You have to go looking for the empty state yourself. The AI will not hand it to you.

Every new user starts here on an empty screen, deciding in a few seconds whether your app makes sense. Spend on this moment.

Where we’re going next

We’ve now walked through the big screen states: loading, error, and empty. The clean categories. The screens where the situation is definite: it’s loading, it failed, it’s empty.

But real apps live in the messy in-between, and that’s where we’re going next.

In part nine, we’re talking about partial states, the awkward, under-designed moments where some of the data is loaded, but not all of it, where one part of the screen succeeds, and another quietly fails, where the app is neither fully working nor fully broken. These are the states nobody plans for and everybody ships, and they’re where a surprising amount of “this app feels janky” actually comes from. Definite states are easy to design. It’s the half-states that separate software that feels solid from software that feels held together with tape.

The loading state is what your app says while it’s thinking. The error state is what it says when it’s wrong. The empty state is what it says when there’s nothing there yet. And the partial state is what it says when the truth is complicated, which, in real software, is most of the time.

Come back for part nine. We’ll design for the mess.