Every product demo shows the dashboard full of data. Every new user sees it empty. That gap is where a surprising share of churn happens: someone signs up, lands on a screen with nothing in it, no explanation and no obvious first move, and closes the tab. Empty states are the cheapest fix in product design and the most consistently skipped.
There are three empty states, and they need different answers
Teams treat “empty” as one screen. It is three, and confusing them produces nonsense like a cheerful “Nothing here yet, add your first project!” shown to a user whose search simply returned no matches.
The first run state means the product is working correctly and the user has not done anything yet. It should teach and invite. The no results state means the user did something and the system found nothing. It should explain why and offer a way out. The error state means something is broken. It should say what happened, whether the data is safe, and what to do next. Same visual slot, three completely different jobs.
The first run screen is your real onboarding
The empty dashboard is the most valuable teaching surface you will ever get, because it is the only moment a user is definitely looking and definitely willing.
Waste it on a shrug illustration and you have spent your best opportunity on a decoration. Use it properly and it does three things at once: it names what will live here, it shows one primary action, and it lowers the cost of that action. “Your campaigns will show here. Create one in about two minutes, or start from a template” beats “No campaigns” by a distance you can measure in activation rate. Sample or demo data is even stronger where it fits, because it lets someone see the shape of the filled product before doing any work.
One action, not five. A first run screen offering import, create, invite, connect, and explore is a menu, and menus are how people stall in the first ten minutes.
The no results screen has one job: get the user unstuck
Nobody searching for something wants sympathy. They want the next attempt to succeed.
That means saying what was searched and where, so the mistake is visible (“No invoices match acme in the last 30 days”). It means offering the widest obvious relaxation of the query: clear one filter, extend the date range, search all statuses instead of open ones. And it means checking the filters are even visible from the empty screen, because the most common cause of “your product is broken” tickets is a filter set three days ago and forgotten.
The wording matters more than the illustration. Plain, specific, and never blaming the user: “No results for that filter combination” rather than “You have no data”.
Error states: say what is safe
An error screen is a trust event. The question every user is silently asking is not “what went wrong” but “did I just lose my work”.
Answer that first. Then say what happened in human words, whether it is temporary, and what they can do (retry, go back, contact support with a reference). Log the technical detail where support can find it, never in the user’s face. And design the partial failure too: one dead widget in a dashboard should not blank the entire page, especially in a product where numbers carry weight.
Design them at the same time as the full screen
The reason empty states get skipped is scheduling, not disagreement. They are drawn last, which means they are drawn during the build crunch, which means they are not drawn at all and a developer invents one at 6pm.
The fix is a rule: no screen is considered designed until its empty, loading, error, and overflow versions exist. It sounds heavy and costs very little, because after the first few screens they become patterns in the design system rather than one off drawings. The same applies to loading, which is a perception problem worth designing deliberately.
We build them into the dashboards and product work we ship, because the alternative shows up in the support inbox within a week.
Small screens, measurable effects
Empty states are not a polish item. They are the first impression of a working product, the recovery path when a search fails, and the trust test when something breaks, which makes them three of the highest leverage screens in any application, and the ones a good dashboard layout still needs.
Shipping an MVP and wondering what to cut? Cut a feature, not the empty states of the features you keep. A thin product that explains itself beats a broad one that does not.
Want a second pair of eyes on the screens your new users actually see first? hello@beconfidency.agency.
If you would rather hand the whole product surface to one accountable team, that is exactly what our product design service is for.