Is a pattern library necessary?
The question is not whether to do it or not, but whether your product is complex enough to require it.
You need a pattern library when the product has complex interface scenarios that repeat: multi-step forms, data tables, search and filter flows. At that point, the issue is not with each individual button, but with how the components fit together to solve an experience problem. If the product is still simple and only one team is working on it, a core component library is sufficient; adding a pattern library early only adds maintenance work.
- Has a complex template, data tables, and a multi-step flow that repeats.
- many teams work together to solve the same experience problem
- the product is simple, with few screens, one team
- the core component library has covered all needs
In many design system projects, Sinh Vũ receives this question quite late, after the team has completed the component library and begins to realize there are situations that don’t fit anywhere. The answer is not always "yes" or "no," but depends on the actual complexity of the product and the number of teams involved.
Pattern and component: two different layers.
This is the most important distinction, and also where many teams get confused.
Components are building blocks: buttons, input fields, information cards, status badges. Each component operates independently and can be reused in multiple places. Patterns (interface scenarios) are ways to combine these building blocks to solve a specific experience problem, for example: a multi-step ordering flow, a data table with filtering and pagination, a registration form with real-time validation.
A component answers the question "What is this?" A pattern answers the question "How to do this?"
Nathan Curtis, EightShapes
According to Brad Frost's Atomic Design framework, components correspond to the atom and molecule levels. Patterns correspond to the organism and template levels, where smaller parts are purposefully assembled. These two levels complement each other and cannot replace one another.
Consideration factors
- Product complexity: Does the product have many flows and steps, large data tables, or complex search and filtering scenarios? If not, core components are usually sufficient.
- Number of teams collaborating: One team can agree verbally. Many teams need a common standard document; otherwise, each team will create its own version for the same situation.
- Repetition frequency: If a situation only appears once across all products, a note in the design file is sufficient. If it repeats across many screens and flows, a written pattern is needed.
- Sustainability: The pattern library needs to be updated alongside components. If the team lacks someone responsible for maintenance, creating it and leaving it alone is worse than not having it at all.
When is it needed, when is it not needed yet
Should create a pattern library when: The product has multi-step forms, data tables with filtering and pagination, or complex flows that repeat in many places. There are two or more teams working on the same product. The team is discovering that each sprint has someone re-solving the same interface problem in a different way. There are people willing to maintain and update the pattern documentation.
No need for a pattern library when: The product has few screens and a simple flow. Only one team is working and can agree directly. The core components cover everything necessary. The team does not have the bandwidth to maintain an additional layer of documentation.
Most common mistakes
- Stuffing everything into an unstructured repository: The result is that users don't know whether they are looking for a tile or a way to build; the repository becomes hard to search as it grows.
- Create a pattern library too early: When the product is not complex enough, the pattern library becomes a document that no one uses or updates.
- Are there patterns but no usage guidelines: A pattern without descriptions of when to use it, when not to use it, and why this approach was chosen is essentially just a screenshot in a cold storage.
Sinh Vũ's viewpoint
In the A3 handover for products with medium complexity or higher, Sinh Vũ clearly separates the core component library and pattern library into two distinct layers. Complex interface scenarios already have standard solutions, so the team does not need to rethink each time they encounter the same problem.
For simple products, Sinh Vũ advises against creating a pattern library. Not because it lacks value, but because doing it too early without enough real-life scenarios can lead to patterns built on assumptions that do not match how the product actually operates later. It is better to let patterns emerge from real repeated situations and then standardize.
The principle Sinh Vũ follows: the pattern library serves the team, not the other way around. If you have to convince the team to use it, it may have been introduced earlier than necessary.
Decision checklist
Topic: Is a pattern library needed in the design system? Sinh Vũ guide, sinhvu.com
Select each item you find appropriate, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Nathan Curtis, EightShapes: UX Patterns are not UI Components. Brad Frost: Atomic Design, Chapter 2. Practical experience in delivering A3 at Sinh Vũ Studio.
Frequently asked questions
What is the difference between a pattern library and a component library?
Component library contains individual building blocks: buttons, input fields, information cards. Pattern library contains ways to combine those blocks to solve a specific situation, such as a multi-step ordering flow or a data filtering table. In the framework of Atomic Design by Brad Frost: components are atoms and molecules, while patterns are organisms and templates. These two complement each other, not replace each other.
When do you know it's time to create a pattern library?
The clearest sign is when multiple teams or different sprints have to solve the same interface problem, each time producing a different style. Or when reviewing designs, the question is no longer whether this button is the right color, but how this flow should function. At that point, a pattern library helps finalize a standard solution once and reuse it multiple times.
Can patterns be integrated into the same component library?
Technically acceptable, but it can create confusion as the inventory grows. Mixing two layers in one place makes it difficult for users to know if they are looking for a tile or a way to build. Sinh Vũ recommends clearly separating the two layers when the inventory starts to include both individual components and complex configurations, to keep everything in its proper place and easier to maintain.