
An eye-opening audit
Designers and developers at Zuora knew there was a major disconnect and why we needed a design system but did not realize how inconsistent things were until we audited each experience across our products, CMS, and internal tools.

So all we needed to do was make things more simple, right? Well, as other designers may empathize with this statement, simplifying is often times the most difficult thing to do.
Problem 1: Change is hard at larger organizations
People have a very reliable and tangible preference for things that have been around for a long time. At Zuora, employee retention is very high due to an amazing culture and leadership — resulting in a large number of people who are used to certain styles and design approaches.
Our approach
In order to limit chaos and disruption, we decided to amend and repair the current foundation — which might have been much harder than just starting completely from scratch. I’ll explain more in Problem #2.
Problem 2: Amending an out of date style guide
The most recent style guide at Zuora was first created for print design. Our color schemes had zero consideration for accessibility standards and the fonts in production did not pair well at all.
Creating a true design system spanning across all of Zuora’s “experiences” would require aligning not only our core products, but also our marketing, community, and other CMS platforms as well. Color palettes, font styles, and other components would need to work across all mediums when paired together.
Our approach
Before this amendment, Zuora’s brand fonts were primarily Brandon Grotesque and Museo Sans while the product used Roboto. Because these three fonts did not work well when used together, we decided to find an alternative typeface that did.

After numerous comparisons and trials among our products, we decided to use Brandon Grotesque for content requiring a major proclamation and Muli for everything else.
Creating usage guidelines around our typography forced us to think more about how we wanted content to be showcased — ultimately leading to us treating type on the component level, instead of creating another vague numeric scale.

In order to also abide by the WCAG accessibility standards, we also needed to simplify our current color palette and define where/how colors would be used.

Because our Brand colors are not naturally web standard accessible, like the majority of other tech companies today, we needed to create usage around our system that would not affect accessibility.
Problem 3: Treating the system as a product, not a one time project
Like many other teams starting out, a few of us began building the system in our spare time. Designers made decisions and then passed those onto development to figure out. There was no clear organization or collaboration between design and development.
Our approach
We soon realized that our design system could not be treated like a one time project, but instead thought of more as a product with a real roadmap and constant collaboration.

The team paused all progress to create a clear roadmap, with one designer and one developer who would be allocated a percentage of time dedicated to executing on the decisions we made as a group.
Key Takeaways
- Design with purpose — clearly defining the usage around foundational elements will help simplify styles
- Fuse engineering and design from the start —creating a framework, similar to Airbnb and numerous other tech companies, where design works with engineering from the beginning will save you time and minimize design/development inconsistencies in the future
- Treat your system like a product — establishing a clear roadmap will help your team understand what is needs to be accomplished on a weekly basis and set your team up for success as the system evolves

