interaction design
UI state
What is UI state and why design every state?
UI state is the particular condition a screen or component is in at a given moment - empty, loading, partial, error, or full of ideal content - and each one looks and behaves differently. Designing a product means designing all of its states, not just the polished "everything's perfect" one, because users will hit the empty, slow and broken states constantly.
Also known as: ui state, states, empty states
Prefer to watch?
Watch the recap 1:07
The demo
One “Your projects” panel - but it's never in just one state. Flip through the states a real user meets: the empty first day, a slow load, a failure, and the ideal. Notice how different each feels.
What this demo shows (text version)
A single "Your projects" panel is shown in the different states a real user encounters. The empty state (no projects yet) is designed to welcome and guide with a clear first action, rather than being a blank void. The loading state reassures with a skeleton preview. The error state explains plainly what went wrong and offers a retry. The ideal state shows the rich content designers usually focus on. Flipping between them shows how different - and how designable - each is.
That's UI state: an interface is always in some state, and designing only the ideal one leaves the empty, loading and error states - which users hit constantly - to chance. Design every state deliberately, especially the first-run empty state and the failure states, because that's where products most often fail users and where thoughtful design helps most.
An interface is never in just one state, so designing only the "ideal" state leaves most of the experience to chance. The states that matter: empty (no data yet - a chance to onboard and guide, not a void), loading (reassure and show progress), error (explain plainly and offer a way forward), partial (some content, some missing), and ideal (the happy path). The empty and error states are where products most often fail users, yet they're where good design helps most. Design every state deliberately - especially the first-time empty state and the failure states - because users meet them more than you'd think, and a thoughtful one turns a dead end into a next step.
Designers love the ideal state - full of perfect content - but users spend real time in the others: the empty screen on day one, the spinner on a slow connection, the error when something breaks. Cycle through them and notice how a blank "empty" feels broken while a guided one welcomes you, and a vague error frustrates while a clear one helps. Every state is a design decision - the question is whether you made it on purpose.
The core states to design for a data-driven screen are: empty (nothing to show - first use, or all items cleared), loading (data arriving), error (something went wrong), partial/sparse (a little content, or some sections failed), and ideal (rich, intended content). Each needs its own layout, copy and actions. Designing only the ideal state - the trap of mockups full of perfect data - leaves the most-encountered states undesigned.
Empty states are a hidden opportunity, not a void: a first-run empty state can onboard, explain the value, and offer a clear first action (teach by doing), turning "nothing here" into momentum. Error states should explain what happened in plain language, avoid blame, and offer a recovery path. Loading states should reassure and show progress (see loading states and perceived performance). Partial states should degrade gracefully rather than break.
Practically, enumerate the states for every meaningful component and screen, and design the empty, error and loading ones with as much care as the ideal. Use realistic and edge-case content (long names, missing fields, zero items, huge lists) when designing, not just tidy placeholder data, so the interface holds up in reality. The states people actually live in are where good UX is won or lost.