How many interface components are enough?
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? The 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. Products change, tokens (design units like color, spacing, typography) are updated, and technical platforms are upgraded. Each time, all components must be checked and adjusted. A small team that takes on 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.
- The real difference between variants: Do two components that look different actually behave differently and serve different contexts? Or are they just duplicates that can be consolidated into one component with parameters (variants or props, which are the configuration values of the component)?
- Product scale and complexity: A simple application with few user flows requires a much smaller system. A platform with many products and truly different interface situations requires a larger system.
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.
- Pre-built for when needed: Pre-built components that are not actually needed are often overlooked or misused in context. They still require maintenance effort 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
To assess the health of a design system, you can ask: what percentage of the running interface actually uses components from the system? That number reveals more than the total number of components in the library.
Decision checklist
Topic: How many interface components are enough in a design system. Sinh Vũ guide, sinhvu.com
Tick each item that applies or that you can already answer, 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. The quantity varies depending on the complexity of the product and the actual level of reuse after review. The more important criterion than quantity is the actual application rate 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.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.