Screen State

Origin & evolution

The clearest articulation is Scott Hurff's "UI Stack", set out in his 2015 article and his book Designing Products People Love (2018). Hurff names five states every screen can occupy: the ideal state, the empty state, the error state, the partial state, and the loading state. The argument is that a screen is awkward when its designer planned for the ideal and left the other four to chance, so users hit blank voids, dead spinners, and unhelpful error messages.

The idea took hold across design systems🧰Design SystemDesign SystemThe root design system entityView reference →, which now treat empty, loading, and error states as required deliverables rather than optional polish. The empty state in particular was reframed as an opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference →: a first-run screen with nothing in it is the best moment to teach a new user what to do, so the "empty" state often does the heaviest onboarding work on the whole screen.

How it works in practice

A team designs an inbox screen. The mockup shows twelve tidy messages, the ideal state. Working through the stack, they design four more: the empty state for a brand-new account, which explains how mail arrives and offers a first action; the loading state, a skeleton rather than a spinner so the layout does not jump; the error state for a failed sync, with a retry control and a plain explanation; and the partial state for the user with one message, which must not look broken. Five states from one screen, and four of them are the ones most users see first.

Screen State vs. its neighbours

• Screen is the surface; the screen state is a condition that surface can be in. One screen🖥️ScreenExperience DesignA distinct screen or view in the productView reference → owns many screen states. The screen is the noun; the state is the adjective applied to it under a runtime condition.
• Design component🧱Design ComponentDesign SystemA reusable UI componentView reference → is reusable across screens; a screen state is specific to one screen's composition. A loading state may be built from a skeleton component, but the state itself is the particular arrangement this screen shows while waiting.
• User flow🔀User FlowExperience DesignA navigation path through the productView reference → is the path between screens; screen states are the conditions encountered along it. A flow says "from cart to confirmation"; the states say what the confirmation screen looks like when the payment is still processing versus when it has failed.

In the graph

In the Unified Product Graph, a screen state sits in the Experience, Design & Brand region as a leaf hanging off a screen🖥️ScreenExperience DesignA distinct screen or view in the productView reference →, joined by a screen_renders_as_screen_stateScreenrenders asScreen Statehierarchy edge. Modelling each state as its own node makes the unhappy paths first-class and countable: a screen with a populated state and no empty, loading, or error siblings is visibly incomplete, which turns "did we design all the states" from a review-time hope into a structural fact the graph can answer.