Help Center

Design system governance models and which is right for your organization

Michelle Chin

Once your design system gains traction and people get excited about it, many things can happen simultaneously. Some might start contributing to it without checking in. Others start voicing their opinions on components. And a few might even ask what’s the process to contribute. As exciting as the interest is, not having a governance model can quickly erode people’s confidence in the design system. Things can feel arbitrary if there’s no solid methodology behind decisions or identifying decision-makers. It’s hard to feel confident in a single source of truth that is random.

No matter where you are in your design system’s maturity, make sure you have some governance model. This model doesn’t have to be permanent; it can evolve as the organization grows and the system matures.

We’ll cover three primary types of governance models – federated, centralized, and hybrid. While there are other models, we see these three when teams scale. We’ll cover:

• Their approach to organizing and staffing
• Who they most commonly benefit
• Any drawbacks
• Considerations for resourcing the models

Federated

In a federated model, representatives from your product portfolio form a team to contribute and maintain a design system. As changes are made, they’re distributed to all of the product teams. A Design System Manager can lead the team, help facilitate discussions, and ensure accountability.  

Sometimes, federated models form organically. When the team realizes they need a design system, one or two designers and engineers usually create a system based on their familiarity with the product. As that gains momentum, people from other products may contribute. Soon after, someone will realize that the product portfolio needs full representation, and the team will grow.

The most significant benefit of a federated model is a realistic and practical understanding of component usage in products. People won’t create components and patterns for the sake of making them. Instead, they’re created from actual needs and use cases.

Organizations that typically benefit from a federated model have a broad product portfolio, have products in different stages of maturity, or don’t have the resources to commit to another model. Because product representatives drive the model, it can be easier to adopt.

If you use a federated approach, there are a few things to be aware of:

• More representatives mean more conversations and opinions. While it can be a good thing, it can also hinder the ability to move forward. We recommend establishing a team charter and defining decision-making. Will decisions be made by majority vote or consensus? Learn more about governance in a previous article I wrote.
• Ensure the federated team covers a breadth of skillsets, not just product knowledge. When creating a well-rounded team, consider all aspects of a component, including visual design, interaction, accessibility, localization, detailed thinking, systems thinking, and so on. This will guarantee that the component is well-vetted and doesn’t need frequent redoing.
• People might feel the need to have several one-off components. As you’re forming a design system from existing products, representatives might feel compelled to stick to their existing designs. Establishing a mission or vision for the design system and some goals will help the team see when it’s appropriate to have unique components or to consolidate. It’s also vital to have a great facilitator who can help identify potential opportunities for alignment and help steer conversations toward decisions or action items.
• Staffing federated teams can be challenging. Federated team members work on their usual product work AND the design system. Splitting time between the two always looks good on paper, but in reality, designers spend too much time on one or the other. And unfortunately, product work usually gets higher priority. When establishing a team, work with leadership to develop expectations. If people can only spend 25% of their time on the design system, then everyone needs to understand that the design system will take longer to create. Depending on your leader’s priorities, that might be OK.
• Design direction (aesthetics) might not be clear. When a system is federated, there could be multiple stakeholders (e.g., Design Directors, Product Directors, etc.). How much influence in the design system might be determined by how your organization is structured. To navigate this, discuss with stakeholders what’s important to them. They’re also busy people, so consider how their role might lengthen the time for component creation – and level set expectations. As you have these conversations, be open and empathetic. It can make these discussions smoother.
• If engineers coding the components are also federated, it can be difficult to carve out their time. We’ve seen where organizations have dedicated design system teams with only designers. They usually have everything designed and spec’d out, but aren’t able to get the coded library updated, which creates fragmentation and misalignment. Ideally, dedicated engineers would be great and can make sure design and code are in tight alignment with each other. If you have to rely on a federated team of engineers, try having discussions with engineering management to secure their time and resources to minimize misalignment.

Centralized

With a centralized model, a dedicated “core” team creates and maintains design system components. They then push out the design system components to all the product teams. 

Sometimes a centralized team is set up when a “design system team of one” is scaled to include more designers and engineers. Some organizations might hire an agency to be the centralized team to get the design system off the ground or redesigned.

In a centralized model, more focus can be on creating UI kits and coded components. With this emphasis, kits and code tend to be up to date, and design systems can be more aligned.

Centralized models benefit newer, smaller organizations or organizations with smaller product portfolios. With fewer or younger products, it’s easier to create an aligned system. Centralized models also might have a single person accountable for the design direction of the design system, which can ensure consistency and make decision-making easier.

While the focus sounds excellent, there are challenges with a centralized model:

• Decisions might not fully consider how products behave “in the wild.” The components created by this team might seem ideal in theory, but when used in the actual product, they might not meet the end user’s needs. When possible, work with product teams for feedback or usability test components. We encourage centralized teams to be flexible within reason to accommodate the realities of a product. When teams aren’t flexible enough with component usage, it can lead to poor user experiences and frustrated designers and engineers.
• Adoption across the organization might be difficult. This model can feel like a “top-down” directive, which doesn’t always go over well with organizations. To help with adoption, some centralized design system teams sit in on design critiques or sharing sessions. Not only does this help the centralized team get more insight into products, but it also helps advocate for using the design system.
• Contractor engagements aren’t always set up for success. Design systems are inherently complex. Hiring a third-party agency to set up your design system sounds like a great way to augment resources in a contained effort. However, their contracts are often underestimated. Contractors need to learn an entire product portfolio. Depending on how extensive the portfolio is, that can take three to six months. Because they’re working in a silo without context, they might not be able to create components that can work well “in the wild.” This can also create extra overhead if someone needs to implement and review their code. I’ve seen engagements extended for several quarters that haven’t amounted to much because of the missing context. I’ve also seen short arrangements amount to very little output because there was no time to create more. 

If you’re considering the agency route, evaluate your exact needs and be realistic about the time it’ll take. Find agencies that have extensive experience in creating design systems for their clients. If you can, have the agency embed with the organization or a few team members responsible for maintaining the design system after the contract ends. You want to ensure that the design system can flourish without the agency. Alternatively, you can consider hiring individual contractors to augment the centralized team. This is less risky and can help your team get ahead of any production needs.

Hybrid

A hybrid approach is a combination of a federated and centralized model. In this model, a federated committee provides direction and feedback, then the centralized team creates the UI libraries, coded components, and updates the documentation. Those changes are then shared with all the product teams.

There are a few different ways to set up this model. Some organizations create guilds or committees of product representatives. They meet to provide feedback to the centralized team and help communicate design system changes to their teammates. They also make great champions of the design system, which can help with adoption. Some organizations might have a more open forum for collecting feedback on components. How you decide should depend on the size of your organization, the number of products, how much time people can spend contributing, and the decision-making culture. Regardless of your set up, the hybrid approach can foster a sense of community among everyone involved. 

Hybrid models compensate for the drawback of only using a federated model or only using a centralized model. They can benefit from contractor support for the centralized aspect. However, hybrid models do come with some challenges:

• There might be more people to manage and organize. Depending on the number of your federated and centralized members, there might need more coordination. Try to keep things as lean as possible. It’s much easier to scale up when needed than starting with a large team and paring down.
• Other managers might not understand the need for federated representatives when there’s a centralized team. It’s common for design teams to be understaffed. Often design managers will be protective of their designers’ time and want them to focus on their product work. Be prepared to answer expectations around contribution, the importance of feedback, and the benefits of participating.
• Design direction (aesthetics) might not be clear. Similar to a federated system, you might still have this challenge. Setting expectations around this will make things much easier if there isn’t one person setting the design direction for the system.
• Bandwidth of federated engineers. Likewise with federated systems, if your engineers are also federated, you run the risk of misalignment with code and design. We recommend trying to set expectations around engineering’s capacity. Some teams try to fit in design system updates in their sprint work when they’re working on a flow that includes the update. Some teams also rotate engineers, where they sit out for a sprint to focus on design system maintenance. Because every organization is unique, we recommend discussing with your counterparts to see what everyone can try and iterate to improve the process as needed.

Advocating for more resources

Needing more resources for your design system is a common challenge, regardless of your chosen model. You might want full-time employees dedicated to the design system or just get more of their time. You may wish to have contractors augment your current team to bring the design system up to speed. Here are some tips on asking for more resources:

• Compare your design system to a more mature one from a similar company.  If you’re a small company, comparing your design system to top-notch systems like IBM’s Carbon won’t get you much traction with stakeholders. They can easily say, “Well, we’re not the size of IBM.” Instead, showing the design systems of similar-sized, similar types of companies or even from competitors might resonate better. With some diligence, you might be able to find out how these companies staff their design system teams. You can use that info as a benchmark for your system.
• Show examples of design systems you’re team is aspiring to or inspired by. This helps provide some context around what caliber design system you’re trying to create. So when you ask for more resources, the requests feel more grounded. Stakeholders will see you’re not trying to over-resource the team to make the next Material Design.
• If you can’t get full-time employees, see if you can manage with contractors in the short term. Consider what options you have to negotiate with and identify the pros and cons of each. This helps stakeholders see and weigh all the options. From there, they might pick an option or propose another option, and you can negotiate expectations from there.
• Discuss the risk of not staffing a design system. Talking about the ROI is always challenging, especially if the team has managed to carve out a design system with existing resources. Stakeholders are business people, so in that scenario, they see that they were able to get a design system for “free.” When ROI is difficult to calculate, leaning on risks might make a better case. Some risks that might resonate with stakeholders include tech debt, building customer trust through good UX and alignment, employee retention in this market, and hiring. Any designer or engineer can leave for a company with a mature, well-functioning design system that’s making their life easier. If you lose talent, hiring, and onboarding new employees and maintaining the design system is expensive.
• Consider talking about your design system as infrastructure and not a product. Check out the article I wrote about that earlier.
• Don’t get discouraged if you can’t get resources immediately. While we want more resources, we might get out prioritized or we might not get them in a timely manner. Focus on getting something in place for your design system and making incremental improvements. A design system takes time to create and get well established, so it’s better to have something started, than striving to get it all done and perfected right away. 

Which model is best for you?

While we wish there were easy answers, it depends on your organization, the product portfolio size, stakeholder expectations, and resourcing. Picking a model might mean thinking about where you want to be eventually but being OK with what model you can put in place at the moment. Whichever model you choose, we recommend setting clear expectations with contributors and consumers of the design system and stakeholders. 

Want to talk about governance with the Design Advocates? Join zheroes, our Slack community, to discuss this and more topics. Sign up today for free at: bit.ly/zheroes-signup