The tangible win
After this lesson, you should be able to tell when a team needs a new component and when it actually needs a reusable pattern.
Why components are not enough
A design system can have perfect buttons, inputs, modals, and alerts, but product teams can still build confusing flows.
Example: every team has a good Modal, but each team asks for delete confirmation differently. One says “Are you sure?”, another hides the object name, another gives no recovery path. The component is fine; the pattern is missing.
Backend analogy: endpoint vs workflow
A component is like an endpoint or library function. It does one thing well.
A pattern is like a workflow: password reset, checkout, invite user, delete resource. It coordinates multiple parts, states, content rules, permissions, and recovery paths.
Common product patterns
| Pattern | Problem it solves | Components involved |
|---|---|---|
| Empty state | What should users do when there is no data? | Illustration, heading, text, primary action. |
| Form validation | How do users recover from bad input? | Input, error text, summary, focus management. |
| Delete confirmation | How do we prevent destructive mistakes? | Modal, button, object name, warning copy. |
| Progressive disclosure | How do we reduce complexity until needed? | Accordion, details, tooltip, secondary panel. |
| Bulk action | How do users act on many selected items? | Table, checkbox, toolbar, confirmation. |
Pattern anatomy
A useful pattern documents more than layout. It should define:
- When to use it — the product situation.
- When not to use it — boundaries and anti-patterns.
- Required parts — components, content, states, and accessibility rules.
- Flow rules — sequence, focus, permissions, loading, success, failure.
- Examples — realistic product examples, not lorem ipsum.
Practice: component or pattern?
A team says, “We need a special modal for deleting projects.” What should you likely propose?
Pattern smell tests
- If teams keep combining the same components differently, you may need a pattern.
- If user confusion appears across multiple screens, a component fix may be too small.
- If the hardest part is wording, sequence, permission, or recovery, it is probably a pattern.
- If the solution only changes one reusable visual part, it may just be a component.
Read next
Skim GOV.UK and Atlassian pattern docs. Notice how they document situations, decisions, examples, and misuse—not only reusable UI parts.