Empty states are the screens nobody designs until the last sprint. You know the ones: the blank table with no rows, the notification panel with nothing in it, the inbox on day one. Most UK SaaS products treat these moments as edge cases. I’d argue they’re some of the most consequential screens in your entire product, and getting them wrong is quietly killing your activation rates.
The idea behind empty state UI design is simple enough. When a user has no data, no content, and no history in a given context, what do they see? If the answer is a white box and a sad little grey sentence reading “No items found”, you’ve essentially handed a new customer a locked room and no key.
Why empty states matter more than your onboarding flow
There’s a tendency in UK SaaS product teams to spend weeks on the formal onboarding wizard, complete with progress bars and illustrated walkthroughs, and then dump the user into an empty dashboard with zero guidance. The problem is that onboarding ends. Empty states don’t. A user who creates a new project, a new workspace, a new report, or a new team will hit an empty state every single time they do something new. That’s not an edge case; it’s a recurring event across the entire user lifecycle.
Slack does this brilliantly. Every new channel you create opens with a short message explaining the channel’s purpose and what a first message might look like. It costs almost nothing to implement and transforms what would be a void into a prompt. Notion does something similar with placeholder text in empty databases. These aren’t accidents; they’re the result of product teams treating empty states as part of the core UX, not an afterthought.
The three types of empty state and how to handle each one
Not all empty states are the same, and designing a single generic treatment for all of them is a mistake. I tend to split them into three categories.
First-use empty states appear when someone uses a feature for the first time and has no data yet. This is prime onboarding real estate. The design should explain what the feature does, show the user what the filled state will look like (even if just as an illustration), and give them a single, clear call to action. One button. Not three. The copy should be active and encouraging without being patronising.
No-results empty states happen after a search or filter returns nothing. These are different because the user has intent. They were looking for something specific. The design here should acknowledge what they searched for, suggest alternatives (fix the filter, broaden the search, check the spelling), and avoid making the user feel like they’ve hit a wall. If your product is a UK-facing B2B tool and someone searches for an invoice that doesn’t exist, the worst possible response is just “No results”.
Cleared or completion states occur when a user has genuinely finished something: an empty inbox, a completed task list, a fully processed queue. These deserve a moment of positive reinforcement. Something brief that says “you’re done” works better than the same blank void that appears everywhere else. The tone should feel different to the first-use state, because the context is totally different.
Copy is doing 70% of the work
Most empty state design discussions focus heavily on the illustration. And look, a well-crafted illustration helps. But I’ve reviewed products where a decent illustration sat above catastrophically bad copy, and the screens were still useless. The copy is doing most of the heavy lifting.
A few principles I come back to repeatedly. First: lead with what the feature does, not with what’s missing. “You haven’t added any team members yet” is worse than “Invite your team to start collaborating on projects.” One focuses on absence; the other focuses on possibility. Second: keep the call to action on the screen and make it obvious. Users who hit a blank state shouldn’t have to navigate somewhere else to fix it. If the empty state is a contacts list, there should be an “Add contact” button right there on the screen. Third: match the tone of your product voice. A fintech product aimed at UK accountants shouldn’t suddenly go whimsical with a cartoon dog in the empty state. Consistency matters.
The GOV.UK Service Manual has good underlying principles about clarity and plain language that translate usefully into SaaS copy, even if the style is obviously different. The core idea, that users shouldn’t need to think hard about what to do next, applies everywhere.
Illustrations: useful tool or distraction?
The illustrated empty state became almost universal in SaaS products around 2019 and I’ve watched it calcify into a cliché. Teams reach for an undraw.co illustration, drop it above a heading and a button, and call it done. That’s not necessarily wrong, but it’s rarely right either.
An illustration earns its place when it genuinely communicates something: the nature of the feature, what the filled state might contain, or a sense of scale. It doesn’t earn its place when it’s decorative filler that adds loading weight without adding meaning. For mobile especially, an oversized illustration that pushes the call to action below the fold is doing active harm.
If you’re working on a product that needs to feel serious, like a compliance tool, a legal SaaS, or anything facing UK regulated industries, an illustrated empty state can actually undermine trust. A clean typographic treatment with precise copy often performs better than anything illustrated. Test it. Don’t assume.
Empty states in dashboards: the hardest case
Dashboard empty states are particularly awkward because dashboards are often module-based. You might have eight widgets and only three have data yet. The result is a patchy grid of partially populated information and multiple empty modules, each with their own small sad state. This fragments the experience badly.
There’s a strong argument for using a progressive disclosure approach here: show only the modules the user has data for, surface the others as locked or greyed-out with a prompt to set them up. This is the approach I’ve seen work well in UK SaaS products that handle analytics or project management. It’s related to a broader point about structured layout thinking; the article on why British editorial and SaaS sites are returning to structured grid layouts has some useful thinking about how composition affects perceived completeness.
For data-heavy dashboards specifically, there’s real value in pre-populating with sample data. Show the user what their dashboard could look like with placeholder numbers, labelled clearly as sample data, so they understand the value proposition before they’ve put any real information in. Notion does a version of this with their templates. It’s honest, it’s useful, and it turns what would be a confusing blank grid into an immediate demonstration of product value. More on designing those kinds of interfaces in the piece on designing data-dense dashboards that actually work.
Testing your empty states properly
Most teams test empty states by manually clearing their test account and looking at the screen. That’s better than nothing. But the real test is watching a real new user hit an empty state for the first time and seeing what they do. Do they understand what the feature is for? Do they know what to do next? Do they feel lost or do they feel guided?
User testing sessions with participants who are genuinely unfamiliar with the product are invaluable here. If your team is based in the UK and doing any kind of remote testing through tools like Maze or UserTesting, recruit participants who match your actual user profile, not just whoever is convenient. You’ll learn things from a 45-year-old accountant in Birmingham navigating your empty transaction list that you’d never catch internally.
Typography also matters on these screens more than people expect. A well-chosen typeface with the right weight and spacing can make empty state copy feel considered rather than thrown together. If you’re still using system defaults without thinking about hierarchy, the piece on building a proper typography stack in 2026 is worth your time.
The bottom line is that empty states are not maintenance work. They’re product design work. Every time a UK SaaS product ships a blank white screen with two words of placeholder text, it’s leaving activation, retention, and trust on the table. The fix isn’t expensive. It’s just attention, and a bit of craft applied to the moments most teams skip.
