Governing design systems
Common governance models, pitfalls, and solutions
Hey everyone 👋 This week, I want to dive into the different governance models for design systems and offer some advice on which ones to use, which to avoid, and the pitfalls to watch out for. Read till the end to see the model I am currently proposing.
Top-down (mandated) centralized model
In a top-down centralized model, there's a dedicated design system (DS) team responsible for building and maintaining the system. In theory, this sounds ideal—the DS team owns every aspect of the system. They build all the components and assets, coach teams, handle requests, and so on. Everything goes through them, and they have the final say on how the system is used and what teams can or can't do. It’s like a dictatorship.
The design system is tightly managed, and the team has "complete" control over its assets. I put "complete" in quotes because we all know that even if they manage to gain full control, they’ll lose it quickly.
Feature teams tend to move faster than the design system team and love to innovate. A DS team that acts through mandates often loses the goodwill of feature designers, who end up finding their own solutions. This results in less design system coverage and strained relationships with designers.
Bottom-up (service) centralized model
I’ve personally experienced a variation of this model, and over time, I was able to overcome it by evangelizing and coaching designers and stakeholders. In this model, there’s a central DS team that’s told they “own” the design system, but in reality, they function more like a glorified service team. They’re given demands by feature teams and don’t have the authority to push back or say no. “Requests” from feature teams to add new components or features to the design system come in, and the only acceptable answer to these requests is yes.
The result is a bloated design system—a mishmash of components and styles with no rhyme or reason. Scaling and maintaining the system becomes impossible, leading to a deflated and demoralized DS team and, ultimately, a failed system.
Federated model
In a federated model, there's no dedicated design system team; instead, multiple feature teams handle building and maintaining the system. This "design by committee" approach can be effective for smaller design teams or start-ups, but it often isn’t sustainable in the long run.
At a certain scale—say, with 20+ designers—having a dedicated design system team becomes essential, as maintaining a cohesive system requires a full-time focus.
The advantage of the federated model is that it demands minimal buy-in from stakeholders and can be a grassroots way to get the first iteration of a design system off the ground. If your leadership is still unsure about the value of a design system, this model might be a good fit for you.
Hybrid model
In a hybrid model, there is a centralized team that manages the design system. They work with feature teams to contribute back into the system and then ship those features. The advantage of this model is that the DS team owns the design system, sets guidelines and principles, but works with features teams to contribute back into the system. If done right, with the proper guardrails in place, this model can be quite successful. If done wrong it can fall into one of the two centralized models previously mentioned.
Distributed model (proposed)
I'm not aware of any companies using this model yet, but it’s one that I propose. It’s becoming clear that a design system can’t—and shouldn’t—handle everything. I’m currently advocating for this approach, which divides responsibilities into three main pillars:
The design system team: This team manages the core components and primitives, documentation, and design tokens, and provides coaching. Their goal is to cover about 80% of use cases, allowing other teams to easily extend components and create rapid compositions using top-level props, children, and design tokens.
The framework team: This team oversees the implementation of design system components and patterns across all feature teams and the app shell(s). They work closely with the design system and feature teams to ensure that design standards are met.
Feature teams: These teams handle their own UIs, use core components and design tokens from the design system, and, when needed, extend the system by creating localized, shared component libraries.
This model promotes high levels of collaboration and delegation. Teams aren’t constrained by design system mandates or velocity issues and can extend the design system to build shared, localized UI libraries. With the framework team managing app implementations, both the design system and feature teams can focus on innovation and effectively use the system.
Want to learn more about design tokens? Take a peak at my post that goes in-depth on how I approach them.
Tying it all together
Picking the right model for you is hard work. I suggest assessing how you currently govern and determine any areas of opportunity.
There is no one-size-fits-all approach, but try to be mindful of some of the pitfalls I listed above.
Did you find this article helpful? If so you can support this publication by subscribing to get access to weekly content.
You can support me by hitting the like button below ♥️