The Challenge

For a complex product with a legacy design system, change is never easy. The biggest challenge we encountered during the process was getting teams to adopt the new system, a difficulty we didn't foresee at the outset. In this case study, I will show why our initial approach didn't work and how we pivoted to ultimately achieve success.

step 01

Auditing existing components

Before redesigning any components, it is crucial to conduct a comprehensive audit of existing elements and leverage insights from past research. I examined the company's Figma files and the current usage of components, as well as identified any in-progress components that might be built in the near future. 

step 02

Planning the rollout

The audit allowed me to visually assess the inconsistencies of components and document their relationships and placements within the product, which set the ground for component criteria when I got to the creation stage later.

I decided to phase out the rollout based on the Atomic methodology, which starts with the simplest components, such as buttons, badges, and selection controls.

step 03

Starting with the foundations

I began by establishing the typography scale, which is at the core of the sizing system. Next, I meticulously adjusted the functional color palette to ensure that each color meets the AA minimum accessibility standard. I then honed the spacing, elevation, and icons based on the 8-point system, establishing a robust and reliable foundation to build on.

Once I solidified the foundations, I worked with developers to develop a token system that works best for them.

step 04

Pivoting the approach

Once the foundations were established, I began creating components, starting with the simplest and most atomic elements—buttons, badges, and selection controls.

However, throughout the process, we encountered adoption challenges after the initial release of these atomic elements.

To overcome the challenges, I conducted further research. I discovered that other organizations with similar experiences prioritize creating the most widely used components first.

This insight led us to pivot our approach and remap the release plan for components based on usage.

step 05

Designing the component

As a result, instead of focusing on the buttons, the first component we ended up creating was Tabs.

We will let Tabs be the main character for the rest of this case study.

During this design phase, I worked closely with product managers and designers to capture their use cases and requirements, such as optional icons and optional dismissible tabs. I collaborated with developers to understand technical feasibility and consulted with an accessibility consultant to ensure accessibility and inclusivity were considered at the component level.

I dedicated time to meticulously setting up all variants and properties in Figma with the utmost precision, ensuring a flexible and user-friendly component system.

step 06

Stress-testing the new component

Partnering with the engineering and critical product teams, we piloted the new component with real user interfaces and interaction flows. This helped us stress-test the component, evaluating its performance under various conditions and edge cases. It also allowed us to elicit feedback from product teams, which was crucial for further refinement and improvement of the component.

step 07

Documentation and handoff

Creating detailed documentation is crucial for any design system. I strive to promote adoption and allow smooth collaboration for designers and engineers from day one.

I crafted the initial draft in Figma and utilized zeroheight for the final documentation. I ensured it mirrored the structure of Figma, enabling designers and developers to locate what they needed swiftly.

step 08

Maintaining and governing

I want everyone involved to feel comfortable and confident using the new design system. In addition to providing written design guidelines, I also set up: