Empty States Are the Most Neglected Screen in Your Product

Somebody signs up, finishes the form, lands in the product, and sees a grey folder icon with the words "No projects found" underneath it. That screen took an engineer four minutes to write and it is the first thing every single customer sees. The dashboard everyone argued about for three sprints is the second thing, and only if the first one worked.

Empty state design gets treated as a gap to fill later because it looks like an absence. It is not an absence. Empty is a state your product is in more often than any other, for every new account, on every screen, at once. It is also the one screen every single user sees, at the exact moment they have no idea how the product works and no reason yet to be patient with it.

Our position is straightforward. An empty state has four jobs, and most shipped examples do none of them, because they were written as a label rather than as an interface. The fix is cheap, it needs no new components, and it usually takes an afternoon. What it needs is somebody deciding it is a screen rather than a fallback.

Empty is the first screen, not the exception

Design reviews are held on filled screens. The mock-up has eight projects in it, each with a plausible name, a status chip and a face. The table has rows. The chart has a shape. Everyone in the room forms an impression of the product from a state that no user will experience for at least a week, and some will never experience at all.

Meanwhile the real sequence for a new account is empty, empty, empty, one item, empty, and then eventually something that resembles the mock-up. If the product is any good, users spend most of their time in the filled state. They spend all of their first time in the empty one, and first time is when they decide whether to come back. This is the same reasoning that makes a small screen a design constraint rather than a rendering problem, which we argue in mobile first is not a layout decision.

An empty screen is not a gap in the product. It is the product, talking to somebody who has not done anything yet.

The four jobs of an empty state

A working empty state does four things, in this order. Most shipped ones attempt the third and skip the rest, which is why they read as a shrug with a button attached.

1. Name what belongs here. Not the label of the panel. What the thing is, what it holds, and why somebody would want one. A new user does not yet know what your product means by a workspace, a board, a pipeline or a space.
2. Say why it is empty. Nothing has been created yet, a filter is hiding everything, the search returned nothing, or something failed. Those are four different sentences and the user cannot tell them apart from a blank panel.
3. Offer exactly one next action. One primary action, phrased as the outcome rather than the mechanism, with at most one named alternative beside it.
4. Show what filled looks like. A single realistic example, a ghost row, or one plain sentence describing the end state. People act faster when they can picture the result.

Why one action, and not three

Empty states attract options because they look roomy, so teams add import, template, invite a colleague, watch a video and read the docs. Every option added to a first screen transfers a decision to somebody with no basis for making it. Pick the action that leads to a real outcome fastest, make it primary, and demote the rest. If the fastest path genuinely is an import, then the import form is the first screen, and it should ask for the least it can get away with, which our parent company sets out in a form is a triage instrument.

Showing the filled state without faking it

The fourth job is the one teams skip, usually for a good reason: nobody wants a sample row that a user mistakes for their own data. The way through is to make the example obviously an example. Label it, style it differently, and never make it interactive. A greyed row reading "Q3 supplier review, 4 documents, shared with 2 people" teaches more about the product in one line than a paragraph of onboarding copy, and it costs one component.

Empty, cleared and failed are three different screens

This is the distinction that separates products that feel considered from products that feel unfinished, and it is almost free to implement. A panel with nothing in it can mean at least three unrelated things, and shipping one message for all three is how users learn to distrust the interface.

The dangerous confusion is the fourth row. When a failed request renders as an empty list, a user with data reasonably concludes their data is gone. Some of them will re-enter it, some will contact support, and a few will quietly stop trusting the product. Failure needs its own message, its own tone, and an explicit statement that nothing has been lost when nothing has.

The one that causes layout shift

The loading row deserves its own note because it is a performance defect as well as a copy defect. Rendering the empty state while a request is still in flight, then replacing it with a list, moves everything below it down the page and contributes to Cumulative Layout Shift. Reserve the space, render a placeholder whose height matches the eventual content, and only show the empty state once the response has actually arrived and confirmed there is nothing to show.

A rewrite, line by line

Abstract advice about empty states is easy to agree with and hard to apply, so here is one taken through the whole method. The screen is the projects list in a hypothetical tool, seen by somebody two minutes after signing up.

What is usually there

A centred grey folder icon, the line "No projects found", and a button labelled "Create". Four problems, none of them stylistic.

• "Not found" describes a failed search, so a brand new user is told something went missing that never existed.
• Nothing explains what a project is in this product, which is the only question the user actually has.
• "Create" names the mechanism rather than the outcome, and gives no sense of what happens next.
• There is no picture of the filled state, so the user has to build the mental model by trial.

What we would ship instead

Heading: "Your projects will appear here." Body: "A project holds the pages, files and permissions for one piece of work. Most teams start with one and split it later." Primary action: "Create your first project." Secondary, as a text link: "Start from a template." Below that, one greyed example row, clearly marked as an example, showing a project name, a document count and two collaborators.

Each line does one job. The heading says what belongs here and implies why it is empty without apologising. The body defines the object in the user’s language and answers the question behind the question, which is how many of these am I supposed to have. The primary action names the outcome. The example row shows the destination. Total cost: four sentences and one static row. This is the kind of work that pays back faster than a redesign, and we make the general case for it in microcopy, the cheapest conversion work available.

One thing an empty state should not try to do is teach the whole product. When the honest answer needs three paragraphs, put the three paragraphs somewhere a curious person can reach and keep the screen short. An assistant surface such as Flidu, which answers from the site’s own content and carries contact and conversion actions in one widget, is a reasonable home for the long version. The screen itself stays four sentences.

What a screen reader gets

Empty states are frequently built as a decorative image plus a caption, which produces nothing useful for anyone not looking at the screen. If the icon carries no meaning it should be hidden from assistive technology, and the heading should be a real heading rather than a styled paragraph so it appears in the document outline.

The harder part is the transition. When a list changes from loading to empty, or from empty to populated after an action, sighted users see it and everybody else gets silence unless the change is announced. A polite live region on the results container handles this, and the ARIA documentation is clear that the region has to exist in the document before the content changes, which is the detail most implementations miss. Announce the outcome, not the mechanics: "No results for that filter" rather than "Container updated".

Keep focus honest as well. If the empty state replaces a list the user was reading, focus should land somewhere sensible rather than jumping to the top of the document or vanishing entirely. Widgets that trap or steal focus cause the same class of problem, which we cover in where a floating chat widget fails a screen reader, and our own commitments are published on the accessibility page.

Who owns empty state design

Nobody, usually, and that is the whole problem. The empty state falls between design, which mocks up filled screens, engineering, which needs a string to render when the array has zero length, and content, which was never shown the screen. So it gets written by whoever is closest to the code at the moment the branch is needed, in about the time it takes to type a label.

The fix is procedural rather than creative. Make the empty, cleared, failed and loading states part of the definition of done for any component that renders a collection, and review them in the same session as the filled state. It is dull work, and it is exactly the kind described in research that could have changed the plan: watching one new person open a fresh account tells you more about these screens than any amount of internal debate, because your own account has data in it and you cannot see the product without it any more.

These screens also drift. They are written once, then missed by every subsequent redesign, which is why an interface can be two years into a new identity and still have one panel using the old voice and the old grey. That is the same decay pattern as why rebrands fail in the second year, playing out inside a product instead of across a marketing site.

When the empty state should say almost nothing

The concession, because this advice can be overdone. Not every empty container is a teaching moment. An experienced user who has cleared their inbox does not need an explanation of what an inbox is, and a settings panel with no custom rules does not need an onboarding paragraph every time it is opened.

The test we use is whether the user has ever seen this container full. First encounter earns the full treatment. A returning user who has emptied something deliberately earns a short confirmation and nothing else. If your product can tell those two people apart, and most can, then write two versions. If it cannot, write the short one and put the teaching into the first-run flow instead, because a permanent tutorial on a screen people see daily becomes noise within a week.

Where we would start on Monday

Open a genuinely new account, not your own, and screenshot every screen a new user reaches in the first five minutes. Do not fix anything yet. Put the screenshots in one document, in order, and read them as a sequence. The problem is rarely one bad screen. It is that the sequence never tells anybody what the product is.

Then rank by traffic rather than by ugliness. The list every user hits on day one outranks the reports page three clicks deep, however much worse the reports page looks. Rewrite the top three against the four jobs, ship them, and treat the rest as ordinary product improvement work rather than a project needing its own name and budget.

The rule to carry away: if a screen can be blank, somebody has already decided what it says, and the only question is whether that somebody was thinking about a user. Decide it on purpose. If the sequence needs more than copy, that is a product design conversation rather than a writing one, and you are welcome to send us the screenshots.