By the end of this lesson you can
- Design the full lifecycle of a screen: first use, loading, partial, ideal, error and empty.
- Write helpful copy for each state.
- Plan states before visual design.
The idea
Screens are not static. A useful model is that every screen has several states during its life:
- Blank or first use: nothing has been created yet. Explain value and guide the first action.
- Loading: show progress. Skeleton screens work for content layouts; spinners for short waits.
- Partial: some data exists. Encourage the next step.
- Ideal: the screen as normally designed.
- Too much: very long lists, huge numbers. Use pagination, truncation and summaries.
- Error: something failed. Explain what happened and how to recover, keeping people's work.
- No results: a search or filter returned nothing. Suggest how to broaden it.
- Offline: show what is available and what will sync later.
Copy carries states
Each state needs clear, human copy: what happened, why and what to do. Avoid blame and technical jargon.
Why it matters in real projects
People spend more time in non-ideal states than designers expect, especially new users who start with empty screens and anyone on a poor connection. Well-designed states reduce support requests, help people recover and keep trust. In Stage 4 you sketched them; here you design them to production quality.
A realistic example
A shared expenses app shows a blank white screen for new groups, a spinner for up to ten seconds on slow connections and "Error 500" when sync fails.
The redesign shows an illustrated first-use state: "Add your first expense — everyone will see it instantly", a skeleton list while loading, a partial state suggesting inviting friends, and an error banner: "We couldn't sync your latest expense. It's saved on this phone and we'll try again automatically." Support tickets about "lost" expenses fall noticeably.
Step by step
List states
For one key screen, list every state from the model.
Prioritise
Mark which are most common or most risky.
Write copy first
Draft what each state says before designing it.
Design each state
Use system components for alerts, skeletons and empty states.
Link them
Prototype transitions between loading, ideal and error.
Review with support
Ask support staff which states cause most questions.
Common mistakes
Mistake Designing only the ideal state.
Instead Design the full lifecycle.
Mistake Technical error messages.
Instead Explain in plain language with a way forward.
Mistake Losing user input on errors.
Instead Keep work and allow retry.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 1 h 15 min
Screen lifecycle
Design the full lifecycle of a notifications screen.
Steps
- List the states.
- Write copy for each.
- Design at least six states.
- Prototype loading to ideal and loading to error.
Deliverable
A set of state frames with copy and a short prototype.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Screens move through many states.
- Design first use, loading, partial, ideal, too much, error, no results and offline.
- Copy carries the meaning of each state.
- Good states reduce support and build 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.