How many components are sufficient?
The question is not about how much is too much, but how much is just right for the team to actually use.
Sufficient is the number of components that the team actually reuses multiple times across real screens, not just a larger number for the sake of prestige. A system with a few dozen core components applied everywhere is more valuable than hundreds of components sitting idle in a library. Start with the most frequently repeated interface types, then expand when there is evidence of real demand.
- A few dozen core components when starting out, small team.
- more components when there are multiple products, with a dedicated team to maintain them
- measuring success by the number of components
- setting up in advance when needed but no one uses it
When starting to build a design system, the first question many teams ask is: how many components are needed? Sinh Vũ's straightforward answer is: enough for the team to reuse multiple times, not enough to look impressive. A design system is not a museum display; it is a real operational tool.
Why more does not necessarily mean better
Each component added to the system is a maintenance debt. When the product changes, when tokens (design units like color, spacing, font) are updated, and when the technical platform is upgraded, each component must be checked and adjusted accordingly. A small team managing a large system will quickly find themselves caught up in maintenance instead of using the system to build products.
Alla Kholmatova clearly states in the book Design Systems: an effective design system is a small, quality set of interconnected patterns (interface samples), not a bloated and cumbersome repository. A library of 200 components with a real usage rate of only 30% is less effective than a library of 60 components that are almost fully utilized.
Consideration factors
- Actual repetition frequency: How many screens and products does this interface appear on? If it repeats often, it is worth integrating into the system. If used only once, keep it with the product, no need to elevate it to a common component.
- Future maintenance costs: Does the team have enough people to support that number of components when the system needs updates? If not, a large quantity will become a burden instead of an advantage.
- Real differences between variants: Do two components that look different actually behave and are used differently, or are they just duplicates that can be consolidated into one component with parameters (variant or props, meaning the configuration values of the component)?
- Product scale and complexity: a simple application with few user flows requires a much smaller system compared to a platform with many products and genuinely different interface scenarios.
When to choose which direction
Nathan Curtis from EightShapes establishes a clear classification principle: components that are reused frequently should go into the system, while one-time use components should remain in the product. This principle is simple but helps avoid most wrong decisions about scope.
Common errors
- Measuring success by quantity: "Our system has 150 components" means nothing if you don't know what percentage of those are actually being used.
- Create components in advance for when needed: Pre-built components that are not genuinely needed are often overlooked or misused, yet still require maintenance like frequently used components.
- Creating many similar variations: Instead of one Button with parameters for size, variant, and state, the team creates ButtonPrimaryLarge, ButtonPrimarySmall, ButtonSecondaryLarge, etc. The result is a multiplied burden without adding real value.
Build from the ground up using atomic design: atom (the smallest unit like buttons, input fields), molecule (a combination of several atoms), organism (a complete interface block). Add elements only when there is a real need, do not create everything in advance.
Brad Frost, Atomic Design, Chapter 2
The viewpoint of Sinh Vũ
In practice, Sinh Vũ often builds a library of about 40 to 80 core components with full real states. This is a reference scale, not a fixed number, as this number changes depending on the complexity of the product and the level of real repetition after reviewing existing interfaces.
Sinh Vũ's operational perspective is: every added component must pay the price of future maintenance. Therefore, the acceptance criteria are not "how many components the system has" but "what is the actual application rate of the system in the team." If you want to assess the health of a design system, ask: what percentage of the interface is actually using components from the system? That number is the true measure.
Decision checklist
Topic: How many components are enough 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
Alla Kholmatova, Design Systems (Smashing Magazine); Nathan Curtis, EightShapes, Design Systems; Brad Frost, Atomic Design, Chapter 2. The scale data of the library reflects the practical experience of Sinh Vũ, not a fixed technical commitment.
Frequently asked questions
Is there a standard number for the quantity of components?
There is no standard number applicable to all cases. Sinh Vũ typically works with around 40 to 80 core components in full states, but this number varies depending on the complexity of the product and the actual repeatability after review. A more important criterion than quantity is the actual application ratio within the team.
Should you create components first and use them later, or wait until there is a demand to create?
You should wait for real demand evidence. Pre-building components for potential needs is the most common mistake, as most of those components will not be used and still require maintenance. Review the existing screens, identify the most frequently repeated elements, and prioritize building those first.
Why many variations can be a problem?
Many similar variants make it difficult for the team to choose the right one to use, increasing decision time and multiplying maintenance costs when updates are needed. Often, those variants can be consolidated into one component with parameters (props or variants), making it more compact and easier to manage in the long run.