Nothing To See Here Yet

I've been building software and websites for twenty years and I'm pretty sure every single one shipped with a bad empty state.

Not some of them, all of them. The dashboard that greeted its first user with a blank table and a gray line of text, or the list view that said "No items found" when the honest message was "you haven't made one yet."

I know why it kept happening now, though it took me far too long to work it out.

You Never See Your Own Empty States

Every product gets designed in its most populated state.

You build the dashboard with test data in it, and the feed with twenty seeded posts, and the table already full of rows, because a table with rows is the interesting design problem and a table without them is just a box.

Then it ships, and the first person who arrives sees none of that.

The state you spent the least time on is the exact state that decides whether anyone comes back. And you never notice, because by the time you're looking at your own product you've had data in it for months.

The indie makers who do catch it tend to catch it late. There's a good short writeup from Colorffy that walks through their own product's blank screens, which reads exactly like the realization arriving after launch rather than before it.

This is the cold-start version of the audience-of-one problem.

Every shortcut you take is a small bet that nobody else will ever need to understand this, and the empty state is where that bet gets settled.

It Matters More Than It Looks Like It Should

Nielsen Norman Group have a whole piece on this, and the framing that stuck with me is that a blank container never reads as neutral.

It reduces confidence and hurts discoverability and slows people down.

And in the exact moment where someone is deciding whether your thing is worth their afternoon, it tells them nothing at all.

Timing makes it worse.

People form an impression of an interface in well under a second, long before any conscious evaluation kicks in.

If the first thing they land on is a blank screen with a shrug on it, that judgment is already made and you're spending the rest of the session digging out of it.

Empty states also show up far more often than "new user, first login."

Someone filters a list into nothing, or searches for a term with no matches, or clears out every task they had, or switches to an account they haven't used yet.

All of those drop a person to zero, and most products treat every one of them as the same screen.

Four Kinds Of Empty

This is the taxonomy I wish someone had handed me fifteen years ago.

IBM's Carbon design system documents a version of it if you want the more formal treatment.

Ship one generic screen for all four and you get the classic failure, which is congratulating nobody. Someone clears their entire task list, feels great about it for half a second, and the app says "No items found."

That's cold as hell.

That last one is the one that has the potential of doing some real damage though.

A failed request that renders as an empty list is indistinguishable from having no data, so the user assumes your product is broken or useless and you never hear from them again.

I've shipped that bug more than once.

What Actually Works Then?

Here is the craft advice that has held up for me, roughly in order of how much it matters (imo).

• Show the shape of what goes here, and I mean the actual thing rather than an illustration of it. Like a greyed-out example row, or a preview of what the filled state looks like. People understand a container by seeing what it holds.
• Give it one unmissable action. An empty screen has exactly one job, and that job is getting someone to the next step. If there are three buttons on it, there are two too many.
• Say why it's empty. "No results for 'widget'" beats "No results" every time, because naming the query or the active filter turns a dead end into a diagnosis someone can act on.
• Write it the way a person would say it. "You haven't added any projects yet" is a sentence someone might speak out loud. "No records" is a log line that escaped into the UI.
• Skip the illustration when it's decorative. A friendly drawing that replaces guidance does more harm than no drawing at all. Tamara Olson's rule, via UserOnboard, is two parts instruction to one part delight, and I've never found a reason to argue with that ratio.

Eleken have a decent rundown of the common failures if you want more examples, and the one they lead with is the same one I keep committing, which is treating the screen as an afterthought and shipping it essentially blank.

An Hour Of Work, Skipped For Years

The strange thing about all of this is how cheap the damn fix is.

An empty state is a bit of copy and a button, maybe a faded example row. No architecture involved, no migration to plan. Most of them are under an hour of work.

They still don't get built, and I think it's because of where they land in the process.

The feature works when the populated view works. That's the moment it gets demoed, marked done, and moved to the next column.

Nobody sits in the "what if there's nothing here" question because the feature already feels finished by then.

So it survives to launch, and then it's competing against roadmap items instead of against nothing. Two hours of polish on a screen you never look at loses that fight every single time.

That's how you end up with good products, built by people who obviously care, still greeting a first-time user with the word "None."

The Demo Data Trap

One tempting shortcut is to seed every new account with sample data so the empty state never happens at all.

Pencil & Paper note that plenty of companies do exactly this, and it does solve the blank screen. It also creates two problems people rarely design for.

The first is that the user now has to work out which rows are theirs and which ones you put there. That's cognitive work you added on their very first visit, which is the worst possible time to add any.

The second is that deleting the samples is itself a moment. Nobody designs it. You get an eight-item checklist of fake tasks and no bulk delete, so the new user's first real interaction with your product is cleanup.

Seeded content works when it's clearly labeled as an example and disappears in one click. It fails when it's pretending to be real.

The Same Problem, Much Bigger

None of this stops at the screen.

A community with no posts, a newsletter with no archive, a marketplace with nothing listed, a forum where the only thread is your own welcome message.

Same problem exactly, just at a scale where the fix takes days or weeks instead of an afternoon.

And the solutions rhyme, too. Show the shape of what belongs here, seed it honestly rather than faking activity, and make the one thing you want someone to do completely obvious.

The community version has its own kind of trap as well, which is that fake activity gets detected almost instantly. Sock puppet accounts and planted questions that lead nowhere.

People can smell it, and an empty forum that's honest about being new does way better than a busy-looking one that's clearly staged.

The Only Screen Everyone Sees

You can ship a product where half the features never get touched. Most do. But there is no version of your product where a new user skips the empty state.

It's the one screen with guaranteed one hundred percent reach.

It's also, in almost every codebase I've worked in, the last thing anyone builds and the first thing that gets cut when the deadline moves.

I don't think that ordering is going to change. Building the populated version is more fun, and it's what everyone means when they say the feature is done.

The most I've managed is a habit. Before I call something finished now, I clear the database and open it like I've never seen it before.

It's uncomfortable every single time, which is very much the point.