In a design system, what is the difference between a component and a pattern, and why document patterns separately?
answer
- unit versus recurring solution
- an API versus a recipe
- one element, or many plus rules
- consistent behaviour across flows
- promote when it stabilises
basics
~20 sA component is a reusable UI unit with a defined API, states and spec. A pattern is a recurring solution to a user problem, combining components with layout, content and behaviour rules; documenting it keeps whole flows consistent.
solid answer
~50 sA **component** is a concrete, reusable interface unit, such as a text field or a transaction row, with a name, variants, states and an implementation on each platform. A **pattern** is a recurring solution to a user problem, such as reviewing a money transfer before sending it or showing an empty transaction list, that combines several components with layout, content and interaction rules. Patterns often live as guidance rather than code, because each flow varies. Documenting them separately matters because teams can use identical components and still solve the same problem three different ways; the pattern is where the system records the agreed way. When many teams rebuild a pattern identically, it may be promoted into a component. Note that some authors, including Brad Frost, call every UI part a pattern, so a system should define the term.
go deeper
Recall that a component is a reusable element and a pattern is a reusable solution to a user problem, and have one example of each ready.
Explain why identical components can still produce inconsistent flows, and what pattern documentation records that components cannot: sequencing, content and cross-component behaviour.
Discuss when to promote a pattern into a composed component, the cost of doing it too early or too late, and how you would spot a pattern teams keep rebuilding.
Treat the pattern layer as where the system encodes product judgement; decide how much of it the system team owns versus product teams, and how that shapes staffing.
## Two different kinds of reuse A design system offers reuse at two levels, and interviewers ask this question to check that a candidate can tell them apart. - A **component** reuses an **element**: one named interface unit with a defined contract. A text field, a button, an avatar and a transaction row are components. Each has variants, states (default, focused, disabled, error), a spec, and usually a coded implementation per platform plus a matching asset in the design editor. - A **pattern** reuses a **solution**: the agreed way to handle a recurring user problem. It usually combines several components with layout, content, sequencing and behaviour rules. “Reviewing a transfer before it is sent”, “showing an empty state”, “recovering from a failed network request” and “filtering a long list” are patterns. ## Side by side | Aspect | Component | Pattern | |---|---|---| | Unit of reuse | An element | A solution to a user problem | | Typical form | Design-editor asset plus code with an API | Guidance, examples, sometimes a template or a composed component | | Answers | “How does this control look and behave?” | “How do we handle this situation across the product?” | | Variation | Controlled through variants and properties | Adapts to each flow’s content and context | | Checked by | Component specs, tests, release criteria | Design review, content review, usability testing | ## Why patterns need their own documentation Identical components do not guarantee consistent experiences. In a retail bank’s mobile app, three teams can all use the same button, amount field and confirmation screen and still: 1. show the transfer summary before or after asking for the verification code; 2. word the “insufficient funds” message three different ways; 3. let the user edit the amount from the review step in one flow and force a restart in another. Every screen is built from approved components, and the product still feels inconsistent. The pattern is where the system records the agreed answer: the order of steps, the content rules, what happens on error, and which components to use. Without pattern documentation, that knowledge lives in one designer’s head or is rediscovered team by team. Patterns also carry decisions that no component can own: - **Sequencing**: which step comes first and what can be revisited. - **Content**: message tone, the wording of errors, what to show when there is no data. - **Cross-component behaviour**: where focus goes after an action, what updates together. - **When not to**: situations where a different pattern fits better. ## When a pattern becomes a component Patterns often start as written guidance with examples. A common path, described in many systems’ contribution practices, is **promotion**: once several teams have built the same pattern the same way and its structure has stabilised, the system team codifies it as a composed component or a template so that teams stop rebuilding it. Promoting too early freezes a structure that still varies by flow and forces teams to work around it; promoting too late leaves duplicated, slowly diverging implementations. ## Where the vocabulary collides - Brad Frost’s atomic design uses **“pattern”** for interface parts at every level: atoms are shown in a “pattern library”, and organisms “serve as distinct patterns that can be used again and again”. In that usage, a component *is* a pattern. - Other systems reserve “pattern” for multi-component solutions and use “component” for single units, as in this answer. - Both conventions are defensible. The practical rule is to **define the terms in the system’s glossary** and use them consistently in the documentation site, the design editor and the code. ## Patterns across platforms Patterns travel better between platforms than components do. A native mobile app and a web site may implement their text fields and sheets quite differently, following each platform’s conventions, yet still share one pattern for reviewing a transfer: the same steps, the same summary content, the same error wording and the same rule about what can be edited. That makes the pattern layer one of the main places where a multi-platform system keeps its products feeling like one product, even when the components underneath are platform-specific. ## What a strong answer includes - The distinction (element versus solution) with one example of each. - The reason patterns need separate documentation: consistency across flows is not a property of any single component. - The promotion path and its trade-off. - Awareness that the word “pattern” is used differently by different authors.
- How would you document a pattern so teams actually follow it?Describe the user problem it solves, show a worked example in context, list the components it uses, state the sequencing and content rules, and include when not to use it and what to use instead. Link it from each component page it relies on, so a designer who finds the component also finds the flow it belongs to. Real product screenshots or examples convince teams faster than abstract diagrams.
- What is the risk of turning every pattern into a coded component?A pattern that still varies by flow becomes a component with many optional slots and flags, which is hard to learn, hard to test and often bypassed. Teams then work around it or fork it. Promotion pays off once several teams build the pattern the same way and its structure has stabilised; before that, written guidance with examples keeps flexibility where it is still needed.
saying these in an interview costs you the question
- Says a pattern is just a bigger component with more props.
- Believes using approved components guarantees a consistent user experience.
- Insists every pattern must immediately become a coded component.
- Claims “pattern library” always means multi-component flows, never single parts.
- Treats patterns as purely visual, with no content or behaviour rules.