Why is the ideal screen not enough?
A meaningful share of an interface's real life is spent outside its ideal state. Connections slow down, searches return nothing, a new user has not created data yet, or a service request fails. Designing only the populated screen leaves the most fragile moments of the experience undefined.
A screen state is not decoration; it is behavior. The flow is not complete until its states are defined.
The 6 states every flow should cover
| State | The user's question | The design's answer |
|---|---|---|
| First use | What do I do here? | A short explanation and one starting action |
| Loading | Is the system working? | Feedback appropriate to the duration |
| Empty result | Why is nothing here? | The reason and, where possible, a next step |
| Partial data | What is missing? | Keep available content and mark the missing part locally |
| Error | What happened and what can I do? | A clear reason, retry action or alternative path |
| Success | Did it work? | Confirmation and the next logical action |
An empty state is more than an empty box
An empty state can have two very different causes: the user has not created anything yet, or their filters and search returned no results. The first should help them add content; the second should help them clear a filter or change the query. Reusing the same illustration and copy for both hides the cause of the problem.
- Explain why the state is empty in one sentence.
- Offer one primary action the user can take.
- If no action is possible, explain the expectation instead of adding a false button.
- Separate search and filter emptiness from first-use emptiness.
Choose loading feedback by duration
The same loading indicator should not be used for every wait. On very short operations it can create a visual flash; when the content structure is known, a skeleton prevents layout shift; beyond a few seconds, users need to know that work continues and whether they can leave the screen.
| Estimated duration | Suitable approach | Avoid |
|---|---|---|
| 0-300 ms | Usually show no indicator | A brief visual flash |
| 300 ms-2 sec | Skeleton or local indicator | Locking the whole screen unnecessarily |
| 2-10 sec | Clear status copy and progress feedback | An ambiguous endless spinner |
| 10 sec + | Background task, notification or real progress | Making users wait without context |
An error message should answer three questions
- What happened? State the outcome for the user instead of leading with a technical code.
- Is my data safe? Do not leave it unclear whether the operation completed.
- What can I do now? Provide a retry, correction or support path.
An error that does not concern the whole screen should not block the whole screen. If a profile photo fails to load, keeping the remaining profile visible and showing the error in the photo area gives the user a better recovery path.
A development-ready design handoff
Delivering one ideal screen in Figma defers behavior decisions to development. Every critical screen needs a state matrix that defines its content, action, component variant and transition rule in one place.
- Component variants: default, focus, disabled, loading, error and success
- Realistic sample content and overflow scenarios
- Responsive behavior for mobile and desktop
- A clickable prototype showing transitions between screens
- Notes distinguishing local errors from page-level errors