By Mehdi HassanWhat is an empty state in a SaaS app?
An empty state is any screen or component that has nothing to show yet: a project list with no projects, a search with no matches, an inbox the user just cleared. It's also called a zero state or blank state. In a SaaS product it's often the very first screen a new account sees, which makes it one of the most viewed and least designed parts of the app.
Most teams design the full state first, with realistic data, and leave the empty version to engineering. The result is a centered gray line that reads "No items found." That line is accurate and useless. In our wider guide to web app UI design we treat empty, loading and error states as one family, because users meet all three before they ever see your polished dashboard.
Why does empty state UX matter for activation?
Empty state UX matters because the first-use empty state sits exactly where a new user decides whether your product is worth the effort. They signed up with intent, landed on a blank screen, and now need a reason and a route to do the first meaningful thing. If the screen gives neither, the product tour you bolted on won't save it.
Onboarding vendors tend to push tours, checklists and tooltips. We think the stronger position is quieter: define one value event (the first report created, the first teammate invited, the first integration connected) and make every first-use empty state point at it. Linear-style restraint works here. One headline, one sentence, one button, and maybe a sample to try.
What are the three types of empty states?
Empty states fall into three types with different causes, so they need different copy. Treating them all as "no data" is the most common mistake we see in product audits.
Type | Why it's empty | User's mood | Main job of the screen |
|---|---|---|---|
First-use | The account is new and nothing exists yet | Curious, a little unsure | Explain the value and start the first action |
No-results | A search or filter matched nothing | Mildly frustrated | Help them change the query and recover |
Cleared (user-cleared) | The user finished or removed everything | Satisfied | Confirm success and suggest what's next |
Error-emptied | Data failed to load, so the list looks empty | Confused | Say it's an error, not empty, and offer a retry |
The fourth row is a trap rather than a type. When a request fails and the UI falls back to the empty list, users think their data is gone. A failed load should always render as an error, with the patterns from our guide to error state UX, never as a friendly blank screen.
How do you write a first-use empty state?
A first-use empty state should sell the outcome, then hand the user the shortest path to it. Use this template and fill every slot with words specific to your product.
Headline: the outcome
Say what this screen will do for them, not that it's empty. "Track every invoice in one place" beats "No invoices yet."
One sentence: how it fills
Explain what creates content here. "Invoices appear when you create one or connect your accounting tool."
Primary action: the value event
One button with a verb and an object: "Create your first invoice." A second, quieter link can offer the import or integration route.
Optional: a sample or template
Offer a prefilled example the user can open and delete. It shows the full state without a fake dashboard full of lorem ipsum.
Optional: one line of help
Link a short doc or a 60-second explainer for people who want more before they commit.
Keep it to that. If the empty state needs a paragraph of explanation, the feature probably needs a clearer name. And when the primary action opens a form, the form is now part of the empty state, so apply the same care from our web form design best practices: few fields, smart defaults and inline validation.
How should a no-results state work?
A no-results state should show the user exactly what they searched for and give them a way to widen it. It isn't an apology screen. It's a recovery screen.
- Echo the query and active filters: "No projects match 'Q3 rollout' in Archived." Users often forget a filter is still on.
- Offer one-click recovery: "Clear filters", "Search all workspaces" or "Show archived too."
- Suggest near matches when you have them: spelling corrections or the closest results by a looser rule.
- Offer creation when it makes sense: if someone searches for a contact that doesn't exist, "Create 'Dana Smith'" saves a trip.
- Keep the layout stable: leave the table headers and filter bar in place so the user can adjust without losing context.
Template: "No [items] match [query] [in scope]. Try [recovery action] or [create action]." Filters cause most no-results states in SaaS, so the design of the filter bar and the empty result are the same problem. Our guide to filter UX design covers how to show active filters so this state happens less often.
What should a cleared empty state say?
A cleared empty state should confirm that the user succeeded and point to the next useful thing. The user emptied this screen on purpose: they triaged the inbox, resolved every ticket or finished the checklist. Treating that moment like a first-use screen ("Create your first task") feels tone-deaf.
Template: "[Success statement]. [What happens next or what to do now]." For example: "You're all caught up. New requests will show up here as they arrive." A small, earned moment of delight is fine on this state, because the user is in a good mood. Don't make it so playful that a power user who clears the queue ten times a day gets tired of it.
For example, suppose a hypothetical support tool has all three states on one screen
Hypothetical example: a support inbox for a small SaaS team.
First-use: "Answer every customer from one inbox. Tickets appear when you connect your support email." Button: "Connect email." Secondary link: "Open a sample ticket."
No-results: "No tickets match 'refund' with status Closed. Clear the status filter or search all tickets."
Cleared: "Inbox zero. New tickets will land here, and we'll notify you on Slack."
Error-emptied: "We couldn't load your tickets. Your data is safe. Retry, or check our status page." Same screen, four different jobs, and each needs its own words.
What are the most common empty state design mistakes?
The most common empty state design mistakes are copy problems that a bigger illustration won't fix. These are the ones we see most often when we review products.
- One generic message for every state. "Nothing here yet" on a search result tells the user nothing.
- Illustration first, words later. A large drawing pushes the action below the fold on smaller laptops.
- Multiple competing buttons. Import, create, invite and watch video side by side means none of them gets clicked.
- Showing the empty state while data is loading. A flash of "No projects" before the real list appears erodes trust. Use the patterns in our guide to loading state design instead.
- Fake data that looks real. Demo rows mixed into a real account confuse people about what's theirs.
- Ignoring permissions. A viewer who can't create anything shouldn't see a "Create" button. Say who can add content instead.
How do empty states change in AI products?
In AI products the first-use empty state is often a blank prompt box, which is the hardest empty state of all: the user has to invent the task. The fix is the same principle with different parts. Show three or four suggested starting prompts tied to real jobs, let the user try one against sample data, and say plainly what the assistant can and can't do.
We cover the trust side of this in our guide to AI product UX. For visual reference, study how the products in our roundup of SaaS UI design examples handle a brand-new workspace. The strongest ones use a short headline, one clear action, and a template gallery instead of an empty canvas.
