Design System Governance
In mid-2021, we set out to create a governance system for a design system for our entire product portfolio. This was no easy feat. In the past, the org struggled to create a unified design system. Those initiatives were often top-down and fell short of understanding our products.
Citrix has over 30 products and endpoints at different levels of maturity. They also didn’t all use the same code base. And Engineering teams had different implementation processes.
We needed a design system that was flexible enough to accommodate these differences. Yet, we also needed a system to provide a consistent aesthetic and experience across the portfolio.
Establishing the governance process
I wanted to include based on my previous experience creating a governance system. These were:
- A federated, bottom-up approach. We would only add components if they proved successful.
- Establishing a team of designers that represented all our products and aspects of design (e.g., visual design, interaction, motion, and so on)
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!
The system at a high level
Product designers and engineers created and contribute to the design system. jUice, our system, takes a layered approach to ensure consistency and flexibility.
At the base are the most common components, such as buttons and dropdowns. All products leverage base components first. Then for each product area, there’s an add-on with areas-specific components. Products might have a secondary add-on for components specific to them. This layered approach allows teams to create components without blockers. We up-level components when opportunities arise to align and combine.
The actual governance process
I learned about governance models from Lisa Welchman’s book, Managing Chaos. She talks about digital governance, but the same principles apply to a design system.
The critical part of establishing a governance process is setting expectations. This way everyone understands and has confidence in the process. As I designed the processes, I reviewed my work with leadership and maintainers. Bringing them along in the process helped address any concerns and built confidence. I shared my design system flows and models Miro board, so anyone could see what I was thinking. I did caution them saying that jumping into the chaos was at their own risk.
Leading the maintainers’ team
The most important part of establishing this broader team was starting off on the right foot. This group varied in design system experience and many hadn’t worked together before.
Our kick-off was an opportunity to get to know each other and workshop our team charter. This helped us understand our expectations, including decision-making and participation. We also had a lot of fun.
We spent the first quarter finding our stride. The team had many questions about the process because it was something super new to them. Once we vetted a few components, everyone started to feel more confident. Later, we went on a roadshow to share the process with the broader org.
Achievements and challenges
With any large-scale effort, challenges surface. There are also opportunities for some wins with them. Here are a few highlights:
- Switching to Figma – During this, we switched to Figma. We needed to create all new components. The whole org needed to learn how to create components and use them. We’re still working on this effort. To reduce the gap, I led an effort to get designers ramped up on Figma and had them create components.
- Establishing a space for engineering maintainers. There isn’t an engineering ops counterpart for my role. So any design system work by engineering comes from a passion for doing the right thing. A designer and I assembled these dispersed engineers and our technical squad. They would vet components from a technical standpoint. We brought them together so they could get a chance to know each other – and to talk shop about implementation.
Our journey’s just started
This was a big effort to get the process established, but we still have so much more to go. We’ve learned a lot and it’s evident that we don’t have the resources we need to get us where we need to be.
For the next steps, I’m working on a design system strategy to close the gaps and get us to a mature system. Some of the ideas I’m looking into include:
- Identifying an engineering ops counterpart to organize that aspect of the system
- Hiring dedicated designers and engineers to work on the production of the components
- Establishing the creative direction of our portfolio with a small team
- Creating an illustration system
- Finding ways to streamline the process and increase efficiencies
jUIce
We named our design system “jUIce.” We’re a company founded in Florida and Citrix is a play on citrus. jUIce is our play on that. Not to mention, there’s “UI” in jUIce. Most importantly, when our design system needs some tidying, someone gets to scream, “The jUIce is loose!” 🤣