In a design system, what is pattern-level usage guidance, and why can component pages alone not cover it?
answer
- a user task, not a part
- several components composed together
- arrangement, order and hand-offs
- empty, loading and error states
- links down to component pages
basics
~20 sPattern-level guidance documents how components combine to solve a recurring user task, such as finding an available rental car. Component pages describe single parts; they cannot say how parts are arranged, which states the whole task needs, or when to vary it.
solid answer
~50 sA **pattern** is the system's answer to a recurring user task — finding an available car, filtering results, recovering from a failed payment — and pattern-level guidance documents how existing components combine to serve it. Component pages describe one part each, so the knowledge that spans parts has no home there: the **arrangement and order** of the location, date and results areas, the **states of the whole task** (loading, no results, error), how parts **hand off** to each other when a filter changes, and sanctioned **variations**. Without it, teams rebuild the same task six slightly different ways from correctly used components. A pattern page states the problem, when to use it, the composition, the states, dos and don'ts with reasons, and links down to each component page. It may be guidance plus a reference recipe rather than one coded component.
go deeper
Recall that a pattern documents a recurring user task and how several components combine to serve it, and that it links down to the component pages.
Explain which concerns span components — arrangement, whole-task states, hand-offs, variations — and why no single component page can own them.
Show how you would pick which tasks deserve a pattern from audit evidence, and when you would keep a pattern as a recipe versus promote it into code.
Weigh the cost of documenting and maintaining patterns against the inconsistency of teams re-deriving tasks, and decide how far up the stack the system should reach.
## From parts to tasks A **design system** documents its **components** — buttons, text fields, cards, date pickers — typically one page each. But people do not use components; they complete tasks. **Pattern-level guidance** documents a recurring user task and how the system's components combine to serve it: finding an available car, filtering results, entering a pickup address, recovering from a failed payment. A **pattern** answers 'how do we solve this kind of problem here?', where a component page answers 'what is this part, and when is it the right one?' ## Why component pages cannot carry it Each concern below spans more than one component, so no single component page is its natural owner: - **Arrangement and order**: where the location and date fields sit relative to the results, and what comes first on a narrow screen. - **States of the whole task**: loading, no results, partial results, error — each involving several components at once. - **Hand-offs between parts**: what happens to the result list when a filter changes, and where attention goes next. - **Variations**: the same task on a small screen, for a returning renter, or inside a partner's embedded view. - **Cross-component rules**: 'once dates are chosen, show the total price rather than the daily rate' touches the date range, the card and the summary. If this knowledge lives nowhere, each team re-derives it, and the product ends up with several slightly different searches built from identical, correctly used components — consistent at the part level and inconsistent where users actually notice. ## What a pattern page contains | Section | Answers | |---|---| | **Problem** | The user task and its context, in one or two sentences | | **When to use / when not to** | Which situations the pattern fits, and the pattern to use instead | | **Composition** | The components involved and how they are arranged | | **States** | Loading, empty, partial, error and success for the whole task | | **Variations** | Sanctioned adaptations and the condition for each | | **Do / don't with reasons** | Real misuses side by side, with the user consequence | | **Related** | Links down to each component page and across to neighbouring patterns | ## A worked example: finding an available car 1. **Problem**: a renter wants to see which cars are available at a location for a date range, and compare them. 2. **Composition**: a location field, a pickup-and-return date range, a search action, a filter group (vehicle class, transmission, seats), a sort control and a list of vehicle cards. 3. **States**: - Loading: keep the search criteria visible and show placeholders where cards will appear. - No results: say why ('no automatic cars at this branch for these dates') and offer the nearest fix — other dates, a nearby branch, clearing a filter — rather than a bare 'nothing found'. - Error: keep the renter's input so they never re-enter dates. 4. **Do / don't**: do keep active filters visible above the results; don't clear filters silently when the dates change, because renters assume the list is still filtered and misread what is available. 5. **Related**: the date range, vehicle card and filter group pages, each linking back to this pattern. ## Guidance, recipe or component A pattern does not have to be a single coded component. Many systems document patterns as **guidance plus a recipe** — a reference composition built from existing parts — because the task varies too much between products to freeze into one component with dozens of options. A common rule of thumb is to promote a pattern into a coded component only once its composition is stable and teams keep rebuilding it the same way. Either way, the pattern page is where the task-level decisions are written down. ## Writing patterns people use - Name patterns after the **user task** ('find an available car'), not the screen or the team that built it first. - Source them from real, repeated product needs, not from a wish to document everything. - Keep component-level detail on component pages and **link** to it; a pattern page that restates every component property soon contradicts the component pages. - Write for designers and engineers at once: describe arrangement and behaviour in user terms, with the component names used identically in the design library and in code, so a web team and a native mobile team can each build the same task from their own components.
- When should a documented pattern be promoted into a single coded component?When its composition has stabilised and teams keep rebuilding it the same way, so a component removes real duplication without needing a long list of options to cover every product's variation. If each team needs a different arrangement, a coded component turns into a configuration maze; guidance plus a reference recipe serves better until the variation settles.
- How do you decide which user tasks deserve a pattern page?Start from tasks that recur across several products or teams and where inconsistency hurts users — search and filtering, entering an address, recovering from an error. Evidence comes from interface audits showing divergent versions, repeated questions to the system team, or design reviews that keep reopening the same decisions. A task only one screen performs rarely justifies a pattern.
saying these in an interview costs you the question
- If every component is used correctly, the task will automatically be consistent.
- A pattern must be shipped as one coded component before it is documented.
- Empty and error states belong on each component's page, not the task's.
- Pattern pages should restate every property of the components they use.
- Patterns are for designers only; engineers work purely at component level.