How small does a team need to be for the design system to be neglected?
The real question is not how many people, but whether anyone has been assigned ownership of the system.
There is no absolute number of people that determines whether a system will be neglected. The deciding factor is whether someone is clearly assigned responsibility and has the budgeted time to maintain it. Without a true owner, regardless of team size, the system will gradually dilute and everyone will revert to being hands-on.
- there is at least one clearly assigned owner
- many teams use it together, choosing a federated model
- No one is assigned to maintain the system, the team maximizes features.
- not being able to allocate even a portion of time for maintenance
A common question Sinh Vũ hears is: how many people should be on the team to create a design system? The more relevant question is: is anyone on that team assigned to maintain the system? When no one is clearly assigned, the system will be neglected, regardless of whether the team has five or fifteen members.
Why the number of people is not a deciding factor
The design system is a product that serves other teams. Like any product, it needs an owner, a time budget for maintenance, and a process for updates. Without one of these three elements, the system will stagnate while the actual product continues to evolve. After a few months, the gap between the system and the actual product widens, people stop using it, and revert to manual design.
This happens in both large and small teams. Large teams may fall into the trap more easily because everyone thinks someone else is taking care of it. Small teams at least know they lack personnel, so they can make more practical decisions.
Three team models and appropriate scopes.
Nathan Curtis from EightShapes classifies three team models for design systems:
- Solitary unit: One person simultaneously maintains the system alongside their main job. Suitable for small teams, but can only sustain if the system's scope is small enough for one person to manage.
- Centralized: A dedicated team solely focused on the system. Suitable when the organization is large enough and has the budget to allocate a team specifically for this.
- Federated: multiple teams contribute to a common system. Suitable when many teams use it and need to share the maintenance load, rather than relying on one person or a central team.
The smaller the team, the most practical model is a solo one. And the solo model only works when the system's scope corresponds to the capacity of one person taking on multiple roles.
When to do everything thoroughly, and when to simplify
Create a complete system when at least one person is clearly assigned ownership and has availability in their schedule to maintain it, or when a small focused team is established for this purpose. The scope can expand according to the team's actual capabilities.
Simplify at the token level and a few core components when the technical team is very small and no one has time to maintain a full system. Tokens here refer to design variables like colors, spacing, and fonts that are named and stored centrally. A smaller scope means lighter maintenance and less risk of being neglected. As the team grows, gradually expand.
Common mistakes when a small team creates a system
- Assign to a general team: meaning no one is truly responsible. When issues arise, everyone waits for someone else to handle it.
- Building a system larger than the capacity to maintain it: Launching with hundreds of components, but the team only has one person handling it. A few months later, the system stagnates, and the team returns to manual work.
- Viewing the launch as the end: Not factoring in ongoing maintenance costs into the budget and personnel from the start. Maintaining the system is not a one-time task.
- No feedback contribution process: Teams only consume the system without a way to contribute improvements back. The owner becomes the only bottleneck and gradually becomes exhausted.
The viewpoint of Sinh Vũ
Sinh Vũ states this clearly within the service boundary: when the technical team is too thin and no one is assigned to maintain the system, the digital design system can easily be neglected, and in such cases, it is better to focus on product development first.
According to practical observations from Sinh Vũ, teams of fewer than three people often find themselves in this situation. However, this is an operational observation, not a hard threshold. The determining variable remains whether someone is responsible for maintenance, not the number of people.
For teams capable of implementation, Sinh Vũ not only delivers the products but also mentors the technical team through collaborative working sessions and provides Storybook documentation for the team to operate independently in the future. The focus is on the actual application rate in the products, not just completing the handover.
The system is a product that serves other teams. Without an owner, the system will become diluted and neglected, regardless of the size of the team.
Nathan Curtis, EightShapes
Decision checklist
Topic: How small can a team be before the design system is neglected. 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, Team Models for Scaling a Design System, EightShapes. Sinh Vũ, internal convention on the boundaries of service A3 (operational perspective, not industry standard).
Frequently asked questions
Is a team of three enough to create a design system?
Three people or fewer is neither a sufficient nor an exclusive condition. The deciding variable is whether any of those three are clearly assigned to maintain the system and have time in their schedule for that. According to Sinh Vũ's operational convention, teams with fewer than three people often find that no one is available, but this is a practical observation, not a hard threshold.
If there is no owner yet, should we do anything or just abandon it?
No need to abandon completely. Sinh Vũ recommends narrowing the scope: just create tokens (design variations, color rules, spacing, typography) and a few core components that are used most frequently. A smaller scope means lighter maintenance and less risk of being neglected. As the team gains capacity, gradually expand.
What is the federated model and is it suitable for small teams?
Federated is a model where multiple teams contribute to the system instead of relying on one person or a central team. This model is suitable when multiple teams use the system to share the maintenance load. For a small team with only one group, a federated model does not have advantages; at that point, a single-person model with a narrower scope will be more practical.