Internally, who should own the design system?
A system without an owner will not be nurtured, and sooner or later, it will gradually fade away.
The design system must have a person or a small group clearly responsible for maintaining the roadmap and making final decisions in case of disputes over standards. It cannot be a shared asset without anyone assigned the role of owner. Depending on the size of the organization, you can choose one of three models: centralized, federated, or hybrid.
- organizations with few teams, need to move quickly and maintain high consistency (centralized model)
- many mature teams need a common voice (federated model)
- large businesses need both stability and product alignment (hybrid model)
- consider the system as communal, with no one taking responsibility
- Delivering a system to an individual; if that person leaves, the system loses ownership.
The question about owning a design system (a set of interface standards and shared components) may seem internal, but this decision directly affects the system's longevity. A system without ownership will not be prioritized for maintenance, no one will resolve conflicts in standards, and teams will gradually revert to doing things their own way.
Three common ownership models.
According to Nathan Curtis (EightShapes), there are three ways to organize ownership of the design system within a company:
Centralized: A dedicated team manages the system and serves all other teams. This group maintains the roadmap, processes request queues, and makes final decisions on standards. Suitable when the organization is small and needs to move quickly and consistently.
Federated: representatives from multiple teams participate in deciding the direction of the system. There is no single group in control. Suitable when teams are mature, have their own voices, and the organization accepts a slower decision-making pace in exchange for consensus.
Hybrid: A small core group maintains standards and direction, while other teams contribute in a controlled manner through a clear process. This is the most common model as organizations grow larger.
There is no model that is absolutely correct. What matters is that regardless of the model chosen, there must always be someone responsible for the direction, not just a technical executor.
Factors that determine choices
- Number of teams using the system: One to two teams is sufficient for focus. Many teams with different needs require a federated voice or hybrid model.
- Maturity level of teams: A less mature team needs a core group to lead tightly. A self-sufficient team needs to contribute to the system; otherwise, they will work separately.
- Budget source: whoever funds the system usually has a say in ownership rights. If it's unclear who the budget belongs to, ownership rights will also become vague.
- Product manager for the system: The system needs to operate like an internal product, meaning someone must maintain the roadmap, prioritize tasks, and act as a bridge with the user teams. Without this role, the system will develop reactively rather than strategically.
Common mistakes when the main owner is not clearly defined
- The system is communal, yet no one takes care of it: When no one is clearly assigned responsibility, everyone assumes someone else is managing it. The system stops being updated, and teams begin to overlook it and follow their own ways.
- Assign to an individual without a succession plan: If that person leaves, the system loses ownership immediately. Ownership should be tied to a role or team, not to a specific individual.
- Core team encompassing everything: When the core team refuses contributions from other teams, those teams feel the system is disconnected from their actual needs and gradually turn away from it.
The design system is a product with an owner, a roadmap, and a queue of tasks, serving internal teams just as it serves customers.
Nathan Curtis, EightShapes: A Design System is a Product
The viewpoint of Sinh Vũ
When Sinh Vũ delivers a design system to clients, the handover is not just files and components. Sinh Vũ provides the RFC (Request for Comment) management process along with a set of monitoring metrics. This framework serves as the infrastructure for internal system owners to operate transparently: every change has a proposer, an approver, and a recorded reason.
Sinh Vũ does not impose a rigid ownership model for every client. During the implementation phase, Sinh Vũ sits down with you to assess team size, decision-making culture, and actual resources, then suggests an appropriate model. A hybrid model is often a good starting point for growing businesses, as it maintains consistency without stifling contributions from teams.
What Sinh Vũ considers most important: the decision on who owns the system should be made before the system goes live, not after it has become chaotic.
Decision checklist
Topic: Who should own the design system internally? 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: Team Models for Scaling a Design System. Nathan Curtis, EightShapes: A Design System is a Product.
Frequently asked questions
If the company only has a small design team, is it necessary to appoint someone specifically for the system?
It is not necessary to have a full-time person, but you need to assign a specific role to someone: that person keeps the to-do list, decides priorities, and approves changes. If roles are not clearly assigned, the system will be updated whimsically and gradually lose consistency.
Can other teams outside the core team contribute changes to the system?
Yes, and it should be encouraged, but there must be a process. Proposed changes need to go through a review step with clear approval from someone, rather than allowing anyone to edit directly. This is the key point that distinguishes a managed system from a spontaneous one.