A component is a thing; a pattern is a solution to a recurring problem, one level up – and four of them (disclosure, empty, skeleton, confirmation) cover most screens you'll ever review.
A component is a thing – a button, a card, a dropdown. A pattern is a solution to a recurring problem, which might use several components together in a proven arrangement. “How do we let someone recover from a destructive action” is a pattern – the answer usually involves a confirmation dialog, itself built from components. “How do we onboard someone without overwhelming them” is a pattern with several valid answers: a walkthrough, a checklist, an interactive empty state.
The level distinction is the working part: one pattern can be implemented with entirely different components in two products and still be recognisably the same pattern, because it solves the same behavioural problem. Practitioners use the word loosely in conversation – which is exactly why using it precisely gets noticed.
The one you already use by name
Progressive disclosure: show only what’s needed now, reveal complexity on demand. You’ve been operating it all lesson – the glossary popovers hold their definitions back until you ask, and the case study below folds closed until it’s wanted. You also already named it unprompted in your placement quiz, about a Melbourne bank – and UP turns out to be the load-bearing version of the pattern, where disclosure carries a legal compliance burden rather than tidying a settings page:
The four moods of every screen
The patterns most products forget to design cluster around one question: what does this screen look like when the data isn’t there yet? Any screen that fetches anything has four conditions – loading, empty, error, populated – and a happy-path mock shows exactly one of them. Skeleton loading answers the first (the layout arrives before the data, so content lands without a shove); the empty state answers the second, and done well it doubles as onboarding – the blank screen teaching its own first step; a recoverable error answers the third, in words rather than codes.
Run all four on one screen – notice which ones you’d never have seen in a design review:
Same screen, four moods
You control what the network sends back. The design has to have an answer either way.
Recent transactionsidle
The panel before its first request – pick an outcome above.
Nothing requested yet – choose what the network will return.
The network returns
Loading, empty, error, populated – a screen isn't designed until all four have an answer, and three of them are invisible in a happy-path mock. The skeleton mirrors the incoming layout instead of spinning; the empty state teaches the first step instead of shrugging; the error names the problem and offers recovery instead of a code. These are named patterns precisely so you can ask for them by name – and ask where each one is, when a design review only shows you the populated version.
That demo is your review checklist compressed: when someone shows you a screen, ask to see the other three moods. If they don’t exist, the pattern vocabulary gives you the ask in one sentence each – “what’s the empty state teaching?”, “does the skeleton match the incoming layout?”, “how does the error recover?”.
This page practises it:This page reveals its own complexity progressively – popovers hold definitions back, the case study folds closed – and the demo runs all four data conditions live on one screen.