Empty states are the screens a product ships with least care and the ones a new user is most likely to meet first. A trial account starts with nothing in it. That is not an edge case. That is the product’s opening line.
There are four of them, and they are different problems with different fixes. Designing one and reusing it everywhere is the most common version of getting this wrong.
1. First run: nothing has been created yet
This is the screen a brand new account sees. No projects, no orders, no records, no history. The temptation is a centred illustration and the words “Nothing here yet”, which is accurate and useless.
A first-run screen has one job: get the person to the action that makes the screen fill up. That means it needs the name of the thing that is missing, one sentence about why it matters, and the same create button they would use later, in the same place they will later find it.
That last part gets skipped constantly. A centred call to action on the empty screen, which then moves to the top right corner once one record exists, teaches a location and then invalidates it. On the Abstractally order operations app, the create control is the only strongly coloured button on the page and it holds one position. An empty queue should show that same button in that same place, greyed context around it, not a different layout that disappears after the first order arrives.
Something worth borrowing from onboarding: if the product can show a realistic example rather than an outline, do it. A dashboard with one sample record, clearly marked as a sample and removable in one click, tells someone what the filled state looks like far better than a paragraph describing it.
2. No data yet: it was created, but nothing has happened
This is the state people forget exists, because in the designer’s mind creating a thing and the thing having data are the same moment. They are not. Someone connects a sales channel and no orders have come in. An account is opened and no trades have settled. A client is added and their first audit is next month.
The screen looks empty and the person did everything right. If it says “Get started by creating your first order” they will reasonably conclude the setup failed.
A no-data state has to say three things: this is working, here is what will appear here, and here is when. On a portfolio view like the investment dashboard we designed, the top row carries index level, amount invested, current value and return. Before the first holding settles, those cards should not read zero and stop. A zero with no explanation reads as loss. The card can hold the label, a dash rather than a zero, and a line saying what fills it.
Charts deserve the same care. A growth chart with one data point draws a flat line, and a flat line is a statement. Say “not enough history yet” instead of drawing a claim you cannot support.
3. Filtered to nothing: the user did this, and can undo it
This one is not really empty. The data exists. The person narrowed it out of view, usually by accident, usually with the combination of a search term and two filters they forgot were on.
So the message is completely different from the other two. Nothing needs creating. Something needs relaxing.
A filtered-to-nothing state should name the filters that are on, and let the person drop them from that screen without hunting for the panel. The tutor search screen we designed makes this concrete: hourly rate is a two-handle range slider, availability is a day-by-day checklist, and gender, verified status and student level collapse into the same column. Four controls, and any two of them can silently produce zero results. A parent who drags the rate slider down and ticks Sunday sees an empty list and has no reason to suspect the slider. The empty state has to tell them, in words, what is currently excluding everyone, with the most likely culprit first.
The same holds for search that returns nothing. On Abstractally the search field takes an order number directly, so a zero-result search usually means a typo or an order in another channel, not an absence. “No orders match 4471-B” plus a clear-search control is a fix. A generic “no results” is a dead end.
One thing not to do here: never clear the person’s filters for them automatically to avoid showing an empty screen. Silently widening a query means the rows on screen are not the rows that were asked for, and in an operations tool that is worse than showing nothing.
4. Error: it is not empty, it failed
An error state dressed as an empty state is the worst of the four, because it teaches people that missing data is normal. A table that renders “No records found” when the request actually timed out will have someone recreating records that already exist.
Errors need to be visibly a different species from emptiness. Different words, different colour, and a retry control. They also need to be scoped: if one panel on a dashboard fails, that panel says so, and the rest of the page keeps working. A whole screen replaced by one failure message throws away the four numbers that did load.
Say what failed in the user’s terms, not the system’s. “Could not load holdings” is usable. A status code is not.
Where these states get written
Empty states get skipped for a structural reason: they are not on anybody’s screen list. The brief says “orders table”, so the orders table gets designed, and the four states around it live in a comment on a Figma frame or nowhere at all.
The fix is to make them part of the component rather than part of the page. When we build a design system, loading, empty, error and success are states of the table, not separate screens someone remembers to draw. That way the tenth table in the product inherits four working states instead of one. This is the same reason our SaaS product and dashboard design work treats onboarding and empty states as a deliverable with the same weight as the main screens.
There is also a writing job here that no illustration can do. Empty states are almost entirely copy. Two sentences and a button label decide whether someone creates their first record or closes the tab, and those sentences are usually written last, by whoever is nearest the deadline.
The quick pass
Take your product’s three most important screens. For each one, open it in a fresh account, then with data but no activity, then with an impossible filter applied, then with the network turned off. That is twelve screens. Count how many were designed on purpose.
Empty states are one of the fifteen points in our free UX audit, and they are the point that most often comes back with a finding. If you would rather run the check yourself first, start with the filtered-to-nothing case: it is the one most products have never seen.