Three management models for the design system: choose the one that truly fits.

Three management models for the design system are often mentioned: centralized (a core team dedicated to creation and delivery), federated (representatives from multiple product teams collaborating), and hybrid (a combination of both). The practical question is not "which model is best" but "which model fits your current scale and budget."

Three models, three different ownership approaches.

The centralized model places all responsibility on a dedicated core team. This team builds components (interface elements), maintains standards, and distributes them for product teams to use. The advantage is high consistency and quick decision-making. The limitation is that when the organization grows rapidly, the core team becomes a bottleneck, unable to meet all demands.

The federated model decentralizes contributions from representatives of product teams. It sounds democratic and cost-effective, but according to Nathan Curtis in The Fallacy of Federated Design Systems, federated is not the first choice and will never run effectively without central investment. This is not an independent model but an extension layer placed on top of a solid centralized foundation.

The hybrid model maintains a fixed core team to manage the foundation and common standards, while having contributors embedded in product teams to bring real needs into the system. This is the goal of most healthy systems in the maturity stage.

Factors that need consideration beforehand when choosing

• How many teams and how many products are using the system together?
• Is there a budget and personnel to maintain a stable core team?
• Do product teams have people with enough time to contribute regularly and with discipline?
• The speed at which components need to be released compared to the consistency that needs to be maintained.
• Who is ultimately responsible for the overall standards in case of conflicts.

When to choose which direction

Choosing to focus when: the organization is just starting to build a system, needs a quick and highly consistent foundation, and has few shared teams. This is not a poor model; it is the right starting point.

Transition to hybrid when: there is a solid enough foundation, team size and product count increase, and the core team starts to struggle with the pace of demands. At this point, integrating contributors into each product team is a natural way to expand, not to discard the core.

Purely federated is not a reasonable choice at any stage if the definition is understood correctly: without a central core, no one owns the standards, and the system will disintegrate over time.

Federated is not an option but an aspect. It should never be pursued first and cannot function without central investment.

Nathan Curtis, The Fallacy of Federated Design Systems (EightShapes)

Common errors

• Choose federal from the start to save on core teams. The result: no one owns it, and the system gradually dies.
• The core team takes on all requests, becoming a bottleneck, unable to keep up as the organization grows rapidly.
• Confusing a federation with abandoning the center, while it still needs a core to maintain standards.
• Choose a model based on industry trends or how large companies operate, not according to your actual scale and budget.

Sinh Vũ's viewpoint

In projects, Sinh Vũ often establishes a focused foundation during the implementation phase, with the Sinh Vũ team playing a temporary core role. Upon handover, the first question Sinh Vũ asks the client team is: internally, who will own this system? If there is no clear answer to that question, then discussions about hybrid or federal models should not take place, as a lack of a central core makes any structure diluted.

The common roadmap is: starting with focus, stabilizing the foundation, identifying who is core within the client's organization, and then gradually opening up contribution mechanisms from product teams, which means moving towards hybrid. The speed of this transition depends on the number of teams, operational discipline, and the budget to maintain the core; there is no one-size-fits-all formula for every organization. This is something that should be discussed directly based on your specific situation.