Designing Empty States and Error States Well

The states everyone forgets

Most design effort goes into the path where everything works and the screen is full of content. But users spend real time in two other places: the empty state, when there is nothing yet, and the error state, when something went wrong. These are precisely the moments of greatest uncertainty, and a blank screen or a cryptic error at those moments does lasting damage to the user’s confidence.

Treating these states as afterthoughts is a mistake, because they carry disproportionate weight. The first empty state is often a new user’s first real impression, and the first error is often where a user decides whether the product is trustworthy.

Empty states should orient and invite

An empty state is an opportunity, not a void. For a new user it is the first thing they see, so it should explain what will eventually be here and offer a clear way to get started. A genuinely empty list with no guidance leaves the user to guess; an empty state with a single obvious action moves them forward.

• Explain briefly what the area is for and what will appear here.
• Offer one clear action that lets the user fill the space.
• Distinguish a first-use empty state from a no-results state, since they need different messages.

Error states should explain and guide

An error message exists to help the user recover, not to report a failure to the developer. A message that states only that something went wrong, in technical language, leaves the user stuck and anxious. A good error explains what happened in plain terms, says whether it was the user’s action or a system problem, and offers a concrete next step.

Design for the unhappy path on purpose

The deeper principle is that the unhappy path deserves explicit design. Enumerating the states a screen can be in, loading, empty, populated, error, and partial, and designing each one, prevents the common failure of building only the populated case and letting the rest fall back to something raw and confusing.

This is not extra polish; it is core to whether the product feels reliable. A user who hits an empty state that guides them, or an error that helps them recover, comes away trusting the product more, not less. The states where things are uncertain are exactly the states worth designing with care.