Empty States and Error Messages: The UX Work Nobody Budgets For

Every product has a moment where there’s nothing to show. A new user’s dashboard before they’ve added data. A search with zero results. A form submission that failed for a reason the server understands but the user doesn’t. These moments get built last, if they get designed at all. Most of them ship as whatever text the engineer typed while wiring up the API: “No data.” “Error occurred.” “Something went wrong.” Then the team moves on to the next feature, and that placeholder becomes permanent.

This is a mistake with a specific, measurable cost. Empty states and error messages are not edge cases — they are load-bearing parts of the product that a meaningful share of users hit constantly, often at the exact moment they’re deciding whether to keep trying or give up.

Why These Screens Get Skipped

Empty states and errors lose the design budget for a predictable reason: they don’t show up in the happy-path flow anyone demos. Nobody builds a pitch deck around the “no results found” screen. Design reviews walk through the primary user journey — sign up, add an item, see the dashboard populate — and the states where something is missing or broken get treated as implementation detail, left for whoever writes the code to fill in.

The problem is that these screens are disproportionately present at the moments that determine whether someone becomes a customer. A brand-new signup almost always lands on an empty dashboard first. A user trying your search for the first time has a real chance of typing something that returns nothing. Someone hitting a payment error is at the single highest-stakes moment in the entire funnel. These aren’t rare failure paths — for a meaningful slice of your users, they’re the first real interaction with your product.

What a Good Empty State Actually Does

A well-designed empty state does three things a blank screen or a generic placeholder does not:

It confirms the user is in the right place. “No data” reads like something broke. A specific empty state — “You haven’t created any projects yet” — tells the user the screen is working correctly and they just haven’t taken the next step.

It tells them what to do next. The best empty states include the exact action that resolves them: a button to create the first project, a link to import existing data, a suggestion for what a first search might look like. An empty state with no call to action is a dead end dressed up as a feature.

It sets expectations for what will appear. If a dashboard is empty because no data exists yet, showing a preview of what it will look like once populated — even a greyed-out mock — does more to build confidence than text alone.

What a Good Error Message Actually Does

Error messages fail in a more consequential way, because they show up at moments of friction that are already frustrating. Three things separate a useful error message from a useless one.

It says what happened, specifically. “Something went wrong” tells the user nothing they can act on. “We couldn’t process your card — the billing address doesn’t match what your bank has on file” tells them exactly what to fix. The specificity costs nothing extra to build; it just requires the backend to surface a real reason instead of collapsing every failure into a generic catch block.

It says what to do about it. An error without a next step forces the user to guess: retry, refresh, contact support, give up. State the recovery path explicitly, even if it’s just “try again in a few minutes” or a link to support.

It doesn’t blame the user for a system problem. A payment that fails because your payment processor timed out is not the customer’s fault, and the message shouldn’t imply it is. Conflating system failures with user error erodes trust fast, especially at a moment — checkout, account creation — where trust is already being tested.

Where to Start

You don’t need to redesign every state in the product at once. Audit the handful that matter most: the first-run empty state on your primary dashboard, the zero-results state on your main search or filter, and the error messages on your checkout, signup, and payment flows. Rewrite those with the same care you’d give a landing page headline, because for a real share of your users, that’s exactly what they are — the first or most consequential thing they read.

Treating these screens as afterthoughts is a design decision, even when nobody consciously makes it. Treating them as real product surfaces is a better one, and it’s cheap relative to almost anything else on a typical roadmap.

PNK WORKS designs and builds the full product experience — including the empty states and error messages most teams skip. Start a project.