Empty States Are Where Products Win or Lose
Open the design file for almost any product and look for the screen with nothing in it. It is usually not there.
There will be a dashboard with twelve projects, a beautiful inbox with realistic messages, an analytics view with a curve going up. Every one of those was designed for a user who has been there for six months.
The screen a real person sees on day one has nothing in it, and that screen decides whether there is a day two.
Empty is the default state, not the edge case
Every single user passes through the empty state. Only some of them reach the full one. We design for the version almost nobody starts at and treat the universal experience as an afterthought, usually a grey icon and the words "No items yet".
The reason is simple and a little embarrassing. Full screens look good in a portfolio and in a review. Empty screens look like unfinished work, so we skip past them to get to the part that shows well.
What the empty screen is actually doing
It has three jobs and most of them get one.
Explain what goes here. Not what the feature is called. What the user's version of it looks like. "Your saved articles will appear here" is better than "No content".
Show the value before the work. The user is being asked to invest effort with no evidence yet. This is where a preview, an example, or a demo item earns its place. Some of the best onboarding I have seen puts one fake item in the list, clearly labelled as an example, that the user can open and poke at.
Give exactly one way forward. Not four buttons. One. An empty state with a row of equally weighted options is a decision handed to someone with no basis for making it.
The four empties
They are not all the same screen and treating them as one is where most of the damage happens.
- First use. Nothing here yet because you are new. Optimistic, instructional, one clear action.
- Cleared. Nothing here because you finished everything. This should feel like a reward. Inbox zero exists as a cultural idea because someone designed that screen properly.
- No results. You searched and found nothing. This one must say what was searched, and offer a way to loosen it. A blank result page with no echo of the query is disorienting.
- Error or offline. Nothing here because something broke. This must never look like the first use state, and it constantly does. Telling a user with a network problem that they should "get started by creating your first project" when they have forty projects is a small betrayal of trust.
That last confusion is the most common bug I find in products I audit. Same component, four meanings, one message.
Design it with real constraints
A trick that costs nothing. When you build the screen, build it with zero, one, and one thousand items, and look at all three before you call it done.
Zero shows you the arrival. One shows you whether the layout collapses. A thousand shows you whether your beautiful card grid becomes a scrolling nightmare. Most design files contain exactly one of those three, the flattering middle.
Why it matters more than it sounds
An empty state is the only moment where the product is speaking without the user having done anything. It is pure product voice. It tells the person what kind of software this is and whether anyone was paying attention when they built it.
Get it right and a new user feels oriented in five seconds. Get it wrong and they feel like they have arrived somewhere unfinished, which is exactly the feeling you cannot afford on the first visit.