Building and Scaling a Unified Design System

📝 I have been provided a very small sample of my work due to my previous company's IP policies, and have done my best to illustrate the story using public domain images. 

When I joined Q4, the team had recently transitioned to Figma, leveraging a system imported from Sketch. The existing Figma design system was a great start, and a few engineers had built out a basic component library using Storybook and React.

This case study is a condensed history spanning more than 2 and a half years at Q4, working with a small team of 5-7 designers on our design systems in parallel with day-to-day initiative work. .

Key problems and opportunities

Reduce inconsistencies: We had 4 distinct applications, either using parts of the design system, or no design system at all. Engineers who weren't using the design system were building required components from scratch using Storybook as a guideline, which inevitably resulted in divergence from the system's UX and UI.

Faster design, easier handoff to development: Designers were often forced to break components in Figma to make them work, leading to a slower design process and  inconsistent application of components, states, and use cases. 

Transparency through documentation and governance: The absence of concrete documentation meant that teams relied on individual knowledge and constant peer confirmation, which made collaboration and onboarding of new team members difficult and time consuming. 

Mismatch between Figma and Web Components: Designers understood what our components could do using Figma, and Engineers knew our Web components well. But there were incongruences between the two. Designs were being implemented in unexpected ways, resulting in more bugs and improvements.

Iterative improvements and early wins

I proactively worked on small improvements focusing on component usability within Figma, and aligning our Figma and Storybook libraries. This work was very ad hoc, but it was forward progress, and I had a few advocates that were eager to contribute.

Improving the efficiency of the design team: I ensured auto layouts were correctly applied and variants were clearly labelled and usable for designers with the goal of making components easier for designers to use. Components started working better in responsive layouts, helping our design teams move faster and design for all use cases with consistency.

Collaborative review process: I established a review process of component changes, so that our teams could track changes and learn what could be leveraged in their designs and built products. It also allowed for a better feedback loop across products, to better understand what each product needed.

Aligning Figma and Built components: Collaborating with the engineer who build out the Web component library, we identified the most frequently used components and how they were inconsistent between Design and Build. We made an agreement to align Figma to what was built in Storybook when the UX and UI made sense, and make small improvements to our Web components when the functionality or UX was not quite right.

Outcomes: Seeing small progress

We were not measuring anything concretely at this point, but even small progress felt like a real win for the design team.

• Design efficiency: We saw a small reduction in component breaks occurred in designs, leading to more consistent application across products.
• Consistency: Design and Build were now in alignment, improving consistency of the products that were able to adopt it.
• Transparency: We now had a core group of engineers and designers that had a shared understanding of our system components and how they could be leveraged.

Addressing deeper challenges and planning for scale

As adoption of our design system began to grow, further challenges emerged:

• Multiple contributors caused divergence: Components designed and built by different stakeholders lacked comprehensive or consistent states, properties, and taxonomy. This made it much more difficult for designers and engineers to find the right component, variant, or property and communicate efficiently. 

• Accessibility compliance was incomplete: Components did not meet Accessibility guidelines (WCAG, AODA). The design team was working to ensure simple pieces like contrast and hierarchy were baked into the system, but this didn't ensure components worked well with assistive devices when leveraged in product experiences.

• Borrowing time and resources: We had a small group of design and engineering advocates, but no concrete team or committee dedicated to working on the system. 

• Disparate and disconnected documentation: Our component usage and functionality documentation lived in Figma only, and engineers building in Storybook focused on adding technical documentation. Stakeholders had to reference multiple sources to get a sense of each component.

• In parallel to building, we were rebranding: Our company had embarked on a new Platform strategy and a company-wide rebrand. This presented an extra layer of work on top of everything we were trying to achieve. 

Collaboration and Processes

Together with the Director of Design, and a colleague, Jenna Piunno, we actively partnered with our development advocates. We knew that a collaborative approach would help ensure that the design system was not just a design deliverable but a shared product, fostering a shared language between teams. Now that the Design team had a toolkit, we needed a strategy to build our new system by either upgrading our existing Web library, or to build a new one. 

Building a Design System Committee

Collaborating with the Director of Product Design and the Director of Product Development, we formed a committee comprised of 6 engineers and 2 designers to ensure alignment and shared ownership over the new system. Our goal was to craft an ad-hoc plan of opportunities to tackle, advocate for roadmap time, and start tracking progress. We set out to:

• Prioritize the foundational build of the updated web component library using Storybook; Aligning which foundational library to leverage (we landed on MUI!)

• Strategize development plans within individual product roadmaps to contribute to the Web library by collaborating with Engineering and Product management across products.

• Build a shared method of communication by creating a single document to track component status as they went through Design, Build, and Release.

• Document baseline metrics for design and development usage to help us understand what our goalposts were for the first iteration and tracking progress.

Initial goals  🎯

• Design and build 20 core components
• 20% speed increase for designers using new components
• 30% reduction of component detaches
• 100% adoption of one product by the end of the year

Moving forward: New brand, new foundation

Leading the rebrand of the design system, I focused on establishing a solid foundation in Figma based on the updated look and feel from our Marketing partners. 

• Developing a Typography Scale: Using a mathematical approach and factoring in our team’s agreed-upon 8px grid, I built out a typography scale using the Typescales plugin, ensuring a consistent visual hierarchy.

• Prioritizing Accessibility and Color tokens: The color palette provided by the Marketing team did not meet accessibility contrast standards, and provided only base colors, with no tints and shades. I collaborated with marketing to refine the color palette to meet contrast standards and stay within the brand look and feel. 

• Defining Grid and Layouts: I established grid breakpoints and layout styles in Figma, aligning with an 8px grid and collaborating with both design and engineering teams for approval. Working with engineering and design partners, we agreed to leverage MUI's grid breakpoints as a starting point.

Establishing design processes

To foster a culture of shared ownership and ensure the Figma design system's stability, I implemented a process for team contributions:

Introducing Figma Branching: Drawing on experience with version control in design systems, I championed the use of Figma's native branching feature to manage component updates and prevent conflicting work.

Creating Process Documentation: Many designers were unfamiliar with branching concepts. I drafted  documentation for the team outlining the process, and conducted a quick, interactive workshop with the team to review.  

Establishing Review Processes: Based on this workshop, the Design team agreed on the number of team members required to review a component before it could be published. Our goal was to ensure transparency, quality, and consistency. This review process also helped designers know what the design system had to offer well before a component was built.

Creating a Component Backlog: Working collaboratively with Jenna, we created a backlog of core components to be designed, allowing the team to contribute effectively, based on our goal to build 20 core components.

Ongoing evolution

Even with a growing library of components, we continued to identify areas for improvement:

Retrofitting Existing Products: Product teams began strategizing how to integrate the updated components into existing products, bringing with it challenges to deliver unified experiences that didn't resemble a Frankenstein UX. The first iteration of this was applying our new color and typography tokens to all of our applications, and designing a rebranded toolbar for our Platform

Prioritizing Component Documentation: We set clear goals for adding comprehensive documentation to components using our new documentation standards, and created Jira tickets to track work to be done and our progress.

Continuous Accessibility Evaluation: Partnering with accessibility experts, (Level Access), we conducted scans of our components to identify and address any remaining accessibility gaps. This ongoing commitment would ensure that our design system adheres to the highest accessibility standards.

Speeding up design and establishing consistency: As new Figma functionality was released, I added a system of variables for our sizing, typography, breakpoints, and modes. This enabled designers to choose from a standardized set of styles and values, keeping our components as consistent as possible. In addition, I worked with the Committee's engineers to build our variables as constants within our Storybook library, and experimented with API connections between Figma and Storybook to maintain consistency.

Building and learning

Working on the design system in parallel to product initiatives meant working fast, but when you're running, sometimes you forget the fundamentals.

Speed kills

I initially built a single line text component, one of our core 20, and then picked up a ticket to work on the multi-line component. I designed these separately in Figma, and reviewed them with the team. To attempt to make our components as consistent as possible, I had tried nesting the single line component into the multi line component, enabling designers to resize it to the height they needed, and re-use familiar properties from the single line component. When designers used this new multiline component, they provided feedback that the nested properties were hidden, and difficult to use. I needed take time and leverage my UX process toolkit to implement components properly.

Research, iterate, test

I researched the MUI documentation, and found that the text input was built to manage both single- and multi-line use cases within one component. I looked at the taxonomy MUI used for their component properties, worked with engineers to better understand how the component was built, how it resized using rows, not a pixel value. This helped me refine my approach to this component.

I created an experiment in Figma to try to unify the single-line and multi-line components into a single component using a set of properties that worked well for both use cases and aligned to what MUI had to offer.

I conducted a quick, internal usability test with 4 designers, comparing the two iterations of the components. 

Testing outcomes

Quantitative

• 4/4 designers were faster when using and configuring the unified component than the separate components using nested parts

Qualitative

• Unified properties were easy to find and use
• Taxonomy aligned with MUI made it easier to cross reference
• Additional properties in the unified component were warranted

This experiment set the foundational process for how our design team would leverage MUI and collaborate with engineering teams for the remaining component designs.

Evaluating our goals

Together, we transformed our initial design system into a powerful tool that empowers our teams begin to create seamless user experiences efficiently and consistently. We came very close to hitting all of our initial goals for the end of 2024, and exceeded our adoption goal! We used the committee's previous benchmark data to evaluate our progress.

In addition to designing and building 20 consistent, easy to use components:

• Designers were now using updated components and properties, speeding up their design workflows by up almost 15%
• The rate of breaking components within design files fell by more than 50%.
• By the end of my tenure at Q4, we had 100% adoption of the design system in one product, and 3 additional products with at least 50% adoption. 

Learning from trips and falls

Looking back, I learned a lot during the course of this project. What would I have done differently?

• Cross-collaboration before diving into design:  I started making initial improvements in Figma before we had clear communication, buy in, and a strategic plan with Engineering. Being proactive is great, but having tunnel vision about only the design team's needs caused more problems.
• Building transparency and advocacy at the outset: I waited to act until the rebrand was imminent. I could have started sooner by building connections with stakeholders and advocates to strategize what resources we may need and bring a business case to Product leadership. This would have brought transparency to the project needs, and alignment to business goals, giving us the opportunity to plan for resourcing, rather than designing and building in between other roadmap initiatives.
• Accessibility first: While the design team did the best they could to factor in accessible design considerations in Figma, there was no team guideline or checklist for us to follow. Fixing accessibility issues retroactively caused a backlog of extra work that is still being done. Building out an accessibility checklist for designers and developers first, and educating our team members would have helped us bake accessibility in from the start.
• Can't stop, won't stop: Design systems are never done, and it's important to always anticipate the next challenge, opportunity, or evolution. As soon as you think you're in a good place and pause, you are behind. I would keep measuring and moving the Design System's goal posts with the Committee to ensure the design system is always meeting the needs of product teams, users, and the business.

Throughout this journey, I learned that the most important pieces of making progress on any Design system were to build advocacy, listen to your partners, understand what different stakeholders need, and continue to make and measure progress. Working on a Design System is a continuous, collaborative effort that is always presenting challenges and opportunities, but it is always a meaningful labour.