By the end of this lesson you can
- Identify the states every data-driven screen needs.
- Design empty, loading, partial, error and success states.
- Write helpful messages that tell people what happened and what to do next.
The idea
Designers often draw the "ideal" screen: full of perfect data, loaded instantly, with nothing going wrong. Real screens spend much of their time in other states.
The common states
- Empty: no data yet (a new user's inbox) or no results (a search with no matches). A good empty state explains what will appear and how to start.
- Loading: content is on its way. Use skeleton screens or spinners, and show progress for longer waits.
- Partial: some data, but not much (one item in a list designed for many). Check the layout still looks intentional.
- Error: something went wrong. Say what happened in plain language, whether data was lost, and what to do next.
- Success: the action worked. Confirm it clearly and suggest the next step.
- Ideal: the screen with typical data.
Messages
Good state messages are specific and kind. "Something went wrong" is not helpful; "We couldn't save your changes because you're offline. They're stored on this device and will save when you reconnect" is.
Why it matters in real projects
Users judge products most harshly when things go wrong or when they are new. A thoughtful empty state can turn a confusing first visit into a clear start; a helpful error can prevent a support call. Designing states up front also prevents developers having to invent them under deadline pressure.
A realistic example
A shared shopping-list app shows a blank white screen to new users. Many never add an item.
The designer creates an empty state with a short illustration, the text "Your list is empty. Add your first item or invite someone to share this list", and two buttons. They add a skeleton loading state, an offline error that keeps items locally, and a success toast when someone joins the list. First-week retention improves noticeably.
Step by step
List screens with data
Find every screen that loads, saves or depends on data.
List states for each
Empty, loading, partial, error, success and ideal.
Design empty states
Explain what will appear and give a clear first action.
Design loading
Choose skeletons or spinners and plan for slow connections.
Design errors
Write messages that say what happened and what to do.
Design success
Confirm and suggest a next step.
Common mistakes
Mistake Only designing the ideal state.
Instead Design every state for every data-driven screen.
Mistake Vague error messages.
Instead Say what happened, what it means and what to do.
Mistake Blank empty states.
Instead Explain and offer a first action.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 45 min
State set
Design all states for the "My bookings" screen of a fitness class app.
Steps
- Wireframe the ideal state.
- Wireframe empty, loading, partial and error states.
- Write the message text for each.
- Design a success state for cancelling a booking.
Deliverable
Six state wireframes with messages.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Real screens spend much time in non-ideal states.
- Design empty, loading, partial, error, success and ideal.
- Write specific, helpful messages.
- States shape first impressions and trust.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
- Designing empty states in complex applications (opens in a new tab)Nielsen Norman Group
- Error-message guidelines (opens in a new tab)Nielsen Norman Group
Your notes
Marking complete updates your course and roadmap progress.