Torque Design System

Building a shared design language for in-store & B2B products

About this project

When our team at Advance Auto Parts grew a few years ago, I was able to convince our leadership to transition the entire team to using Figma. This opened up an opportunity to build a shared team design system to standardize our approach and styles across multiple products and platforms.

Skills used
  • User experience design
  • User research
  • Visual design
  • Writing
  • Information architecture

The colors in Torque include brand colors, neutrals for the UI, and status colors for messaging, along with a variety of tints and shades.

The problem

When I started at Advance Auto Parts in 2016, each designer on the team used a different tool for creating mockups: Photoshop, Sketch, and even Illustrator. Collaboration between designers was a tricky dance of either converting from one format to another or (more often) taking screenshots and overlaying changes as new layers. It was inefficient and time-consuming to say the least.

As the lone designer using Sketch at first, I started building up a small library of reusable components to speed up the process. This helped me, but didn’t help other teammates using different software. When our team more than doubled in size a few years ago, I was able to convince our leadership to transition the entire team to using Figma. This opened up an opportunity to build a shared team design system, and I seized it.

The process

Conducting an interface audit

Our team works across multiple products, from in-store systems to the B2B e-commerce platform, but we wanted to implement a common design language across all of these. So we started with an interface audit. We made a list of the most common interface elements across all of our platforms, and broke down the elements by function type to organize them logically. Then we assigned portions of the list to each designer to collect samples.

A small sample of the numerous form fields from across the apps we surveyed in preparation for building Torque.

Syncing on styles

Once we had a robust sample for an element, we discussed the various approaches and decided upon what best fit our collective vision of the brand, starting with simpler elements like buttons and form fields. Because our team was scattered around the globe, I made an asynchronous voting tool within Figma for the team to pick which styles best matched the language we were aiming for. These early votes informed the direction for all components to come later as we built from the established components.

An example of a voting form where I asked our team which style attributes they preferred for a simple button, from corners and colors to shadows and text case.

Building a foundation

For our foundational elements like colors, typography, and icons, we pulled first from the overall brand guidelines established by the marketing team. But we deviated where we felt it was important for our platforms. For instance, we selected different red and yellow colors from the brand for denoting error and warning colors. (We did not want to dilute the brand colors as connoting errors and warnings.) We also opted for filled, solid icons over line icons because the majority of our products are used in bright environments with older technology (think garages and retail stores) where contrast is important.

Adding complexity

Once we defined the foundational elements and a few basic components, I set to work creating the variations that would make the design system truly shine. Then the team used those fundamental building blocks to create more complex components and eventually combined all of the elements to envision what a final version of one of our products might look like.

In the meantime, as we made the design system in Figma, we began conversations with developers and product managers on various products to advocate for adding design system work to the roadmap.

Testing early and often

Testing components for robustness was an important part of the process. I tested components regularly by:

  • placing variable data into components, like shorter and longer text, different image sizes, etc. to see how each component adapted,
  • using components in existing layouts as well as recreating mockups with all new components,
  • and resizing components to test responsiveness.

Documenting in detail

I also documented the components as we made them using Confluence. In the long run, the plan was to move documentation alongside the coded components, but I wanted to capture use cases, best practices, and expected functionality as they were fresh. I then added links to the documentation with the component pages in Figma so it would be easy to find.

Anotherr example of a vote where designers on the team helped to select the name they wanted for our system by placing their selected emoji next to their preferred name.

Naming the system

As we approached the milestone of defining all of our initial components, I facilitated a workshop over two weeks to name the system. Each member of the team came up with between 5 and 15 names, many of them themed around automobiles and garages. We took a few days to review them and each person nominated 2-3 favorites from the group. Finally, I held a vote within Figma to select the ultimate name: Torque.

My role on the project

I was excited to take the lead on this project when our team switched to Figma. Having built robust components within Sketch, I understood both the value and the process for doing so, which translated well to Figma.

I came up with early lists of components to audit and grouped them according to their logical functions. I facilitated asynchronous workshops to review the audited UI elements and define the overall style we wanted to aim for.

I then used those styles to create the foundational colors, text styles, and variables, and a handful of basic components. I worked with individual designers as they took those starting components and built others to train them on how to create components in Figma. I documented everything within Confluence. The ultimate goal was to move final documentation into a code repository alongside the coded components.

Finally, I met with product managers and engineers to work on getting design system work into the roadmap for various products. I made the initial set of CSS custom properties to define design tokens for coded components, and I worked with another designer on the team to begin coding and testing components.

Evolution of a system

A screenshot of my early components within Sketch

I started this project almost 7 years ago as a personal Sketch library. At the time, I named it Chassis because it formed the framework I built from.

Another screenshot of a design system built using InVision DSM.

I experimented with InVision DSM as a potential tool for collaborating between different design products.

A screenshot of a design system website showing design tokens.

And even built a web-based design system to document design tokens, icon names, and coded components.


Within about 9 months of starting, we had the majority of our components, styles, and variables in a shared library that the team could build from. We were starting to use them for all new feature mockups and making traction on getting the first wave of components built in code.

Less than a month after that, our B2B e-commerce design team rebuilt the entire application as mockups within Figma using the design system. They were previously relying on screenshots or outdated Sketch files to create new mockups because most of the application designs pre-dated our transition to Figma.

Sadly, just as we were picking up steam, the majority of our UX team and product managers were laid off in a company-wide reduction. So the future of the design system is dubious at best. Still, it's there and ready to be picked up, and it may prove to be an efficient tool for the remaining teams should they need it.

Lessons learned

  • The hardest part of system design is people. Everybody has different preferences, experiences, and priorities, and a good system relies on reaching a shared compromise.
  • Test components early and often. “Perfect” components can break quickly with unexpected data or unintended use cases. Add longer text, resize components, and more to get a feel for where components can break.
  • Combine components in realistic layouts as you build them. It’s easy to lose the forest for the trees. When you spend a ton of time nailing the minute details of a component, it can be disheartening when you place it in a larger context and it doesn’t work at all.
  • A good design system is just like any other product. It needs upkeep and maintenance, or it will quickly slide into irrelevance.