Governance is a design system’s friend

Do you cringe when you hear the word “governance?” I used to! I would actively try to avoid it. We don’t like rules as creatives, and it’s tough being told what to do. But when design leadership asked me to create a governance process for our unified design system, I had to become friends with it. But what is governance anyway? When it comes to design systems, governance is a framework for clarifying roles, responsibilities, and authority over decisions. Having that clarity ensures that decisions for the design system funnel smoothly through the governance process. After learning what governance was, I realized what would lead us to a successful unified design system and that single source of truth we were seeking.

illustration of governance and a laptop looking at each other confused

I’ll cover how I created governance around a design system and its team without feeling awful. The examples I provide are for a previous company where I worked. They were an enterprise software company trying to align all its products to use one unified design system.)

Governance is two-fold

For a design system, two areas benefit from a governance model. The first and most obvious is around the component in the design system. Some questions governance models answers are:

• How will you decide what’s a component or not a component?
• When does a component go into the component library?
• What’s the process for submitting and reviewing (i.e., a contribution model)?
• What documentation do we need for an element (i.e., usage guidelines, functionality details, animation specs, accessibility)?

The other aspect of governance is around how the design system team functions. Some questions that governance answers are:

• How often will you meet?
• What’s essential to the team?
• How does the team arrive at a decision?
• Who are the decision-makers? Who are the stakeholders?

Our governance book character holding a ruler

Governance Framework

Managing Chaos: Digital Governance by Design by Lisa Welchman helped me recognize that governance provides answers to those questions.

Governance is your friend. It’s there to provide a shared understanding with everyone – designers, developers, stakeholders, and other cross-functional partners. Lisa was a pioneer in digital governance. When websites were becoming popular, she was at the forefront of figuring out who was responsible for what. Imagine a time when it wasn’t clear who maintained the company’s website. Should it be IT? Should it be Marketing? Should it be Product Managers? Thankfully, websites are no longer uncharted territory – we have a much better idea of what departments and roles handle the responsibilities of maintaining them.

Design systems are still evolving, and that’s where governance might feel uncharted. I used Lisa’s book to help define our design system governance. Lisa breaks down governance as a framework containing three parts policies, strategies, and standards. You probably have some of this established already for your design system.

Policies
Design system policies are high-level policies that your design system needs to follow in the company’s best interests. They are a subset of corporate policies, so they’re not always something determined by your team. For example, my company decided that all software it creates will adhere to WCAG 2.0 Level AA guidelines. These guidelines also become part of our design system policy.

If you’re not sure what policies should apply, reach out to legal experts at your company. Some policy areas to consider are legal items like GDPR, intellectual property, open-source usage, data retention policies, etc.

Strategies
Design system strategies include guiding principles of how you operate and performance objectives. Performance objectives were our goals for the year. We created a team charter for our guiding principles that addressed how we would work as a team.

If you’re looking for a team charter specifically for design system teams, check out our Figjam template.

Standards
Design system standards can be both general and specific. You probably already have some particular standards like usage guidelines on components. General standards can include things like how the team vets a component or voice and tone for content.

Our governance book character holding a key

Keys to good governance

Identifying policies, strategies, and standards are the bulk of establishing governance. But to ensure good governance, we have a few tips:

Set the right expectations with everyone. Keep stakeholders and teammates informed as you create the process. Let them know how they’ll be involved and when they can provide feedback.  When everyone’s on the same page, it’s much easier to have productive conversations. I created a playbook with all the details of our design system’s governance. The playbook was helpful because it gave everyone a tangible guide to reference if there were questions about expectations or the process.

Collaborate on the governance process. While you can answer all the previous questions on your own, the guidance will resonate much better if the right people are involved in shaping the process. Determining who’s most appropriate for providing feedback will depend. I reached out to the Design Directors to see how they imagined their involvement in strategic decisions and final say. For the day-to-day operations or more minor choices, I turned to the maintainers on the team since they were most affected. When people know you haven’t been working on this in a silo, they’ll feel more confident in the process, which is excellent!

Know your stakeholders. Understand who the stakeholders are and how they want to participate in the process. Some might be hands-off, and others might be hands-on. Navigating who should have a say can be tricky. Depending on your org, it might not be the HIPPO (highest paid person in the room). Nor should it necessarily be the most vocal person either. Consider designing your governance to be inclusive of everyone in a way that leverages what everyone brings to the table and helps accomplish the team’s goals.

In my case, the Directors of Design were ultimately accountable for design decisions in their product area. This responsibility could have them gravitate toward being heavily involved in the design process. But we had some talented designers who could solve tricky problems and create incredible designs. When defining the governance, I set expectations that the designers would explore a breadth of solutions and make educated decisions. If the component had a significant impact on the UI, the designers would make a recommendation for the directors to approve. With suggestions, we remedied the impulse for directors to start designing solutions themselves. If the component was more obscure, the designers would decide, and the directors would be informed. Being informed was a great way to meet their accountability needs without having them get into the weeds.

Evolve the governance. While governance defines guidelines and guardrails for the team to follow, it doesn’t mean that things are unchangeable. Set the expectation from the beginning that you’ll try this out and evaluate it in three or six months to see how well things are working.  Some decisions on paper don’t work out well in real life. Like in design, it’s crucial to iterate and pivot to improve.

People often ask me if we’re iterating should we go with less governance or more. That’ll depend on what works best for your team. Because I was trying to align a whole product suite and manage a 15-person team, I opted for more governance. However, I told everyone that we’d try it out with more governance and get rid of anything that we felt was too much along the way. We found out that some components needed more governance than others, so we kept all the steps but knew when we could skip some.

Our governance book character holding tools

Tools for governance

Once you’ve figured out your governance guidelines, consider the tools you’ll use.

• Where will you keep your team charter and governance documents? There are tons of solutions out there. Some different types of options include Miro, Confluence, or zeroheight. Think about what tools your team is comfortable with and frequently uses. Making the information accessible will invite people to reference it easily.
• How will you track progress? Jira, a spreadsheet, Miro kanban, or Airtable are tools that can help in tracking progress. Before adding any additional tools, see if you can use one tool for multiple purposes. It’ll help the team feel like the process is more cohesive and less scattered.
• What tools will you use to review components? Maybe taking notes and adding comments in the Figma file makes sense. Perhaps it’s more suitable to set up reviewers in zeroheight to provide feedback via comments. Or depending on the role someone plays in the process, they might be involved at different times and use other tools.

Discuss what works best for the team and what would help accomplish the goal. Once you’ve decided, document it as part of the governance process.

Our governance book character smiling and cheering

Do you have any other questions about governance?

Governance does take time, and it’s not always one-size-fits-all. Following these tips will help you arrive at a good governance model and documentation that serves as a single source of truth.  If you have any questions, please reach out to our other Design Advocates or me on the zeroheight Slack community. We’re always happy to talk about governance.