Every screen has more than one state
Design tools encourage designing the ideal state: the list with eight items, the profile with a photo, the dashboard with a satisfying chart. Real screens spend a lot of their time in other states, and those are the ones shipped as an afterthought — a blank area, or a red sentence saying "Error".
| State | When | Usually shipped as |
|---|---|---|
| Ideal | Populated with typical data | Carefully designed |
| Empty — first use | New user, nothing created yet | A blank rectangle |
| Empty — user cleared it | Everything done or deleted | Same blank rectangle |
| Empty — no results | A filter or search matched nothing | "No results" |
| Loading | Waiting on data | A spinner, or nothing |
| Error | Something failed | "Something went wrong" |
| Overloaded | Far more data than expected | Never checked |
Three empty states, three different jobs
First use — teach and invite
The user has nothing because they've just arrived. This state should explain what goes here, why it's useful, and give one obvious action to create the first item. If you can, seed a realistic example they can look at and delete.
Cleared — acknowledge and reassure
An inbox at zero is an achievement, not an error. Say so plainly and offer the sensible next step. Reusing the first-use screen here is a small tell that nobody thought about it — it will instruct an expert user on something they finished doing.
No results — explain and offer an exit
This one carries a diagnosis. Say what was searched and what filters were applied, then offer to clear them. "No results for 'inovice' in Archived" tells the user both what happened and, often, that they made a typo.
Error messages that help
A useful error answers three questions: what happened, why, and what to do now. Most production error messages answer none of them, because they were written by the system rather than for the reader.
| Unhelpful | Helpful |
|---|---|
| "Something went wrong" | "We couldn't save your changes — your connection dropped. Try again; nothing was lost." |
| "Invalid input" | "Enter a date after today." |
| "Error 403" | "You don't have permission to edit this itinerary. Ask the account owner for access." |
| "Upload failed" | "That file is 24 MB. The limit is 10 MB — try compressing it." |
- Put the message next to the thing that failed, not in a corner of the screen
- Never blame the user. "You entered an invalid email" and "That email doesn't look right" cost the same and read very differently
- Say what happened to their data. "Nothing was lost" prevents the panic that causes people to redo work
- Keep the technical detail available but out of the way, so a support conversation can get at it
- If it's recoverable, put the recovery in the message as a button
Covering the states you have
- List your screens, then multiply by the state tableIt's a shorter list than it sounds. Most products have six or seven core screens.
- Design first-use empty states firstEvery user sees them. They're the highest-traffic screens in the product.
- Collect the error messages actually in your codeGrep for the strings. The list is usually shorter, worse, and more repetitive than expected.
- Rewrite each one to answer what, why, and what nowAn afternoon of copy for a visible drop in confused support messages.
- Test with far too much dataA name of two hundred characters, a list of five thousand rows. The overloaded state is the one nobody has ever looked at.
Common mistakes
- Designing only the ideal state and shipping the rest by default
- Reusing the first-use empty state for a cleared list
- "Something went wrong" as a production error message
- Clearing a form's fields when submission fails
- Never testing with unrealistically long or numerous data
Key takeaways
- Every screen has an ideal, empty, loading, error, and overloaded state
- First use, cleared, and no-results are three different empty states with different jobs
- A useful error says what happened, why, and what to do next
- The first-use empty state is the highest-traffic screen in any product
Try it yourself
Create a new account in your own product and screenshot every screen before adding any data. That sequence is what every user sees first — and it's usually the part of the product nobody has ever reviewed together.