Empty States, Errors and Loading: The Forgotten Screens
By CodexierPublished 5 min read
Most design files show a product at its best: lists full of realistic data, every request successful, everything loaded. Real users meet something else first. A new account is empty. A network drops. A report takes ten seconds. These states decide first impressions, drive a large share of support tickets and are often left for a developer to improvise the night before launch. This guide gives patterns for each.
Why these states matter
A new user's first screen is usually empty. If it says "No projects found" and nothing else, you have lost the moment where they were most motivated. An error that says "Something went wrong" produces a support ticket. A blank white screen for three seconds makes the product feel broken even when it is not. Designing these states is cheap; not designing them is paid for in churn and support time.
Empty states that teach
| Type of empty | Example | What to show |
|---|---|---|
| First use | A new account with no customers yet | One sentence on what belongs here, a primary button to add the first item, optionally sample data or import |
| User cleared | Inbox zero, all tasks done | Confirmation that the work is finished, with no call to action needed |
| No results | A search or filter with no matches | The query shown back, a way to clear filters, suggestions for similar terms |
| No access | A section the user's role cannot see | Why, and who to ask for access |
Keep the tone plain and useful. An illustration is optional; a clear next step is not. Our guide to microcopy for buttons and errors covers the wording in detail.
Errors that explain and recover
A good error message answers three questions: what happened, is my work safe, and what do I do now. It appears close to the problem, not in a generic banner at the top. It avoids technical codes in the main text, but can include a reference for support. And the product should recover automatically where possible: retry a failed save, keep form input when submission fails, queue changes while offline.
Validation errors
Next to the field, in plain language, shown after the user leaves the field or submits, not while they type.
Network errors
Say the connection dropped, confirm unsaved data is kept, offer retry and retry automatically in the background.
Permission errors
Explain which role is needed and how to request it, instead of a bare "forbidden".
Server errors
Apologise briefly, show a reference code for support, and never lose what the user entered.
Loading and skeleton screens
Loading design is about perceived speed. Skeleton screens that mirror the coming layout feel faster than a centred spinner because the user can see structure arriving. Show content progressively as it loads rather than waiting for everything. For actions over a few seconds, show progress and let the user keep working. For very short waits, show nothing at all; a spinner that flashes for a fraction of a second only adds noise.
- Under about half a second: no indicator.
- Up to a few seconds: skeleton or inline spinner on the part that is loading.
- Longer tasks: progress with a description, and the option to continue elsewhere.
- Background jobs: notify when done instead of making the user wait on the screen.
- Announce loading and errors to screen readers with appropriate live regions, as covered in our WCAG 2.2 guide.
A checklist per component
- List every component that fetches or saves data: tables, lists, dashboards, forms, uploads.
- For each, design empty, loading, error and populated states, plus partial data where relevant.
- Write the copy for each state, reviewed by someone who talks to customers.
- Add the states to the design system so developers reuse them instead of improvising.
- Test on a slow network and with the server switched off before launch.
We cover these states as a standard part of a product design sprint. When you do not need a sprint: if your product is small and you have a designer in-house, this checklist alone will get you most of the way. If you want an outside review of your forgotten screens, book a free call.
Frequently asked questions
Should empty states use illustrations?
They can, but the illustration is the least important part. A sentence explaining what belongs here and a button for the next step do the real work. Keep illustrations light so they do not slow the page.
Are skeleton screens better than spinners?
For content that loads in a predictable layout, usually yes, because they show structure and feel faster. For short actions such as saving, a small inline spinner on the button is clearer.
Should error messages include error codes?
Not as the main message. Lead with plain language and a next step. A short reference code in smaller text helps support find the problem in logs.
Who is responsible for these states, designer or developer?
Both, but they should be designed, not improvised. The designer defines the patterns and copy; the developer implements them consistently, ideally from shared components.
Want your forgotten screens reviewed?
Show us your product. In fifteen minutes we will point out the empty, error and loading states that cost you users.
Book a free 15-minute call