Creating a Design System Governance Model
Sometimes reaching critical mass forces you to take action. We reached this point when our new end-user product needed its own design system – ASAP. Here’s how I established a governance process for our design system, jUIce.* For this project, we were definitely building the plane as we were flying it!
Citrix Workspace originally leveraged the ShareFile design system. We were the ShareFile design and engineering teams, so it’s what we knew. Yet, we quickly outgrew it and needed more components and patterns. Things started to get messy – every designer had their own variation of a Sketch kit. While things mostly looked the same, lots of tiny details were different. But no one knew which details were right.
At first, I gathered two “design-system passionate” designers and they started to chip away at the basics. But, we were going through a big design growth spurt. So many components were evolving, so many new ones were created. As a result, we had to stand up a governance process of some sort.
Establishing a governance process
No one likes bulky processes descending upon them. It’s a lot of change, even if it’s for the best. So we took this approach one step at a time and tailored it to our needs as we learned what worked for us.
I roughed out a high-level process, which explained the steps and who’s involved when. Right before each step, we roughed out some more details, tried it out, and iterated if needed.
Overview of the design system governance process. Select the image to see a larger version.
Step 1. Design Brain Trust review
Here’s where we gathered a select team of designers to serve as a “brain trust.” As much as we wanted everyone to take part, it wasn’t a good use of people’s time. Another design manager and I selected a team for the brain trust. We tried covering all the bases for evaluating a component/pattern including:
- Systems thinking
- Detailed thinking
- Interaction
- Visual design
- Technical considerations
- Accessibility
- Globalization
This team could vet a component/pattern to see if there was something missing or concerning. They also decided if this should move forward as part of the design system.
We had an in-take form people filled out to present a component/pattern. We used Podio to capture this info – as a way to capture the item’s lifecycle. But it turned out to be too far removed from Sketch and a lot of extra work. It also didn’t get to all the questions that engineers would ask us.
Iterating
To resolve this, I created a Sketch template. In the template, designers provided context for the component/pattern and all its variations.
While tedious, this worked out better. It created a “case study” that we could walk engineering and the design director through.
Step 2. Citrix-UI review
After we felt good about our component/pattern, the other manager and I would review it with the Citrix-UI maintainers. (Citrix-UI is the coded component library of jUIce.) They’d look at what we were proposing from a technical aspect. They’d determine tech feasibility and if it was worth including it in the design system.
Much of my role revolved around framing questions and scenarios so design and engineering could talk through options. Based on my design background, familiarity with code, and experience implementing products, I could propose high-level suggestions to get engineering feedback. From here we would weigh our options with how it affects the user’s experience. This negotiation was a delicate balance, but my goal was always around how we could keep moving and iterating.
These conversations were really helpful. But since designers didn’t attend, the context had to be repeated to make the updates.
Iterating
To remedy this, we started inviting designers working on the component. It was great having them take part and engage with engineering. They could get the context, but also ask questions, and learn more about aspects they need to consider when designing.
Step 3. Design Director review
After the Citrix-UI review, we took the final proposal to the design director. This often involved providing a lot of context and asking for an “OK” right away – so it could get delivered, coded, etc.
In our first few components, it seemed to take forever to get the “OK.” Weeks could pass by between revisions and finding meeting times with the director. Our director needed to feel informed and we weren’t telling a holistic story. We also spent a lot of time debating tiny things that were already debated in previous steps.
Iterating
Leveraging the template for these reviews helped tremendously. It presented a thorough case study of the component. Later, we included the explorations to show its evolution. This provided the context needed for our director to make a confident decision.
Because we were vetting so many components, we needed to be judicious with our time. We applied centralized/decentralized decision making to this.
- Centralized – the director made the final decision on components frequently seen or ubiquitous in the UI (for example, buttons)
- Decentralized – the managers informed the director of where the team landed for less frequent, more obscure components (for example, admin components)
This sped up the process and made conversations more focused and efficient.
Up against time
Even by taking a scrappy approach to the governance process, we were always behind. Decisions took time and components were in high demand. We had a dilemma – do teams wait for the coded component or do they code things anyway and then update the code later? At the same time, Engineering was shifting to SAFe, which didn’t leave room for ad hoc design requests.
Iterating
I hosted a discussion with PM and engineering stakeholders to get buy-in building this into SAFe. We agreed on the importance of this and had a good solution. But soon after, there was an engineering org change, so we couldn’t move forward. Rather than try to fit this into “the System,” I had to find a way that didn’t rely so much on the System. My solution wasn’t rocket science. I asked if the Citrix-UI maintainers could fit in updates. They gladly said yes, so we could catch up on where we were behind.
Once over that influx of updates, we were able to maintain the components more sustainably. Citrix-UI was inner sourced, where any engineering team can contribute to it. Some teams, who needed components for their project, would contribute to Citrix-UI.
Impact + Outcomes
Product Design and Engineering formed a great working partnership and demonstrated getting things done together. The maintainers were also passionate about doing the right thing.
After getting through that growth spurt, we now have one single source of truth. For the past 1.5 years, we’ve been in maintenance mode. We’ve slimmed down the brain trust and have combined both meetings into one review. When we meet, we actually have a lot of fun. We talk about design and engineering in their purest sense. Our conversations aren’t influenced by business requirements or time constraints. Everyone’s passionate and takes pride in our success. In our retro, designers and engineers agreed they valued our collaborative discussions.
It also opened solid lines of communications. We often reach out for design/engineering questions outside of the design system. And we’ve collaborated on winning Hack Week projects together.
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!” 🤣