Design System Governance

👋 Here’s a little summary of how I created a design system governance process at an enterprise organization. 


For years, Citrix struggled to create a unified experience across its product portfolio. Despite several attempts at a unified design system, none succeeded. With over 30 products using different technologies and processes, this struggle was understandable.

As DesignOps Manager, I was tasked with creating a unified design system (called jUIce). A top-down approach had failed us multiple times, so we needed a different strategy. Our new design system had to be flexible enough to accommodate various technologies yet consistent enough to provide a cohesive aesthetic and user experience.

The solution was a design system governance process. This process would enable us to manage contributions, organize the team, and set clear expectations across the company.

Screenshot of our design system components in Figma
Screenshot of our design system components in Figma

Establishing the design system governance process

Drawing from my experience with smaller teams, I aimed to leverage successful elements for this new governance process. Key components included:

  • A federated, bottom-up approach: Components were added only if they proved successful.
  • A diverse team of designers: Representing all products and aspects of design (visual design, interaction, motion, etc.).
  • A supportive team of engineers: To handle the technical implementation.

I faced a unique challenge—there was no full-time design or engineering support for maintaining the design system. Participants in the federated team would be balancing their regular product work with this initiative, which was a significant ask from leadership.

To gain leadership support, I embarked on a listening tour with directors of each product area. This helped me understand their organizational structure and resourcing needs. I invited them to identify representatives for their areas and demonstrated the flexible, high-level approach of the design system. Involving them early made buy-in easier, and I successfully assembled a team of 16 design system maintainers!

For context, I wouldn’t have dedicated designers for this. All the designers would be working on products and could commit a little time to the design system. What I wanted was asking for a lot.

To get everyone on board, I went on a listening tour with the directors of each product area. I got a better sense of their product area’s organization and what resourcing would need to look like. I invited them to identify representatives for their product areas. I also showed the high-level approach of the design system, including how flexible it was. Getting buy-in was easy since I involved them in the process. I was able to assemble a team of 15 design system maintainers!

Overview: a multi-level, flexible design system

Part of the governance process involved creating a multi-level system to ensure consistency and flexibility.

  • Base Level: Includes the most common components, such as buttons and dropdowns, which all products can use. Teams are encouraged to leverage these base components as much as possible.
  • Add-on Level: Each product area has specific components tailored to their needs. Additionally, individual products might have a secondary add-on level for their unique components.

This layered approach allows product teams to create components without blockers. When opportunities arise to align and combine, we promote components to more foundational levels. 

Diagram of the design system at a high level
Diagram of the design system at a high level

The design system governance process

Drawing from Lisa Welchman’s book, Managing Chaos, I adapted her digital governance principles to our design system. 

The key was setting clear expectations so everyone understood and trusted the process. I collaborated with leadership and the federated team, sharing my Miro board of workflows and models to keep everyone informed and engaged.

The governance process included:

  • Criteria for determining which components and patterns are included in the design system and at what level.
  • Responsibilities at each phase of the review process.
  • Guidelines for contributing components and patterns.
  • Methods for communicating design system updates across the organization.

By involving stakeholders early and maintaining transparency, I built trust and confidence in the governance process.

Screnshot of my design systems model brainstorming board
This is a screenshot of my Miro board of design system workflows and models. Design is messy!

 

Practicing the governance process—leading the federated maintainers’ team

Starting off on the right foot was crucial for our 16-person team, which had varied design system experience and hadn’t worked together before.

Our kickoff meeting was an opportunity for the team to get to know each other and workshop our team charter. This helped set clear expectations for decision-making and participation. I included some fun activities to build camaraderie within our distributed team. (I later created a Figjam template of this team charter at zeroheight.)

We spent the first quarter finding our stride, with many team members having questions about the new process, especially on such a large scale. As we vetted a few components, confidence grew. Eventually, we went on a roadshow to share the process with the broader organization.

Screenshot of the team charter workshop
Screenshot from our team charter workshop

Achievements and challenges with the process

Large-scale efforts come with their share of challenges and wins. Here are a few highlights:

  • Switching to Figma: Transitioning to Figma was exciting but required recreating our components in a new UI library. Additionally, the entire organization needed to learn how to create and use these components. To facilitate this, I collaborated with leadership to host activities focused on learning Figma and practicing component creation.
  • Establishing a Space for Engineering Maintainers: Without an engineering ops counterpart, any design system work by engineers stemmed from a passion for doing the right thing. With the help of another designer, I formed a technical squad of engineers to vet components from a technical standpoint. This group proved invaluable—even though they typically didn’t work together, they often helped each other troubleshoot and solve implementation issues.

Screenshot from our playbook with the team of our engineering maintainers
Screenshot from our playbook with the team of our engineering maintainers and key design maintainers

Advancing the design system

Implementing a working design system governance process across an enterprise organization was a significant achievement, especially considering previous unsuccessful attempts. We learned a lot and realized we needed more resources to reach our goals.

For the next steps, I developed a design system strategy to elevate our efforts, which included:

  • Identifying an engineering ops counterpart to organize the technical aspect of the system.
  • Hiring dedicated designers and engineers to focus on component production.
  • Establishing the creative direction of our portfolio.
  • Creating an illustration system.
  • Finding more ways to streamline processes and increase efficiencies.