Building (re-building) the design system at Auto Trader (Part 1)
Design systems are a hot topic these days. So much so, that it’s not uncommon for large companies to make their systems open and available to the public to browse. They present excellent showcases of neatly organised UI components, code and descriptive documentation that is enough to satisfy any perfectionist or those with a keen eye for detail and organisation.
But what really is a design system, and what does a good one actually look like? The answer is simple, Google it. Jokes aside, my belief is that it varies from company to company, circumstance to circumstance. So, this blog post series is all about answering what that question looks like from our perspective and the journey that we have recently undergone to get the Auto Trader Design System (ATDS) up to speed.
Identifying the need for change / improvement
So, where did we start? Here is a brief summary:
- We already had the framework for our design system (ATDS) organised into atomic layers similar to that of Brad Frost’s Atomic Design.
- We were storing our components on Storybook (code), which allowed us to view the library as a webpage and interact with real examples of our components.
- We were also storing our components on Figma (design) where our components were accessible to be used by our design team.
This all seemed like a fine start, however after speaking to some of the main stakeholders and running a few feedback sessions for both designers and front-end developers, it was clear that there were some fundamental issues that needed addressing.
- Both Figma and Storybook didn’t match up. There was not a confident parity between our design and code components.
- There was a lack of documentation in our system. Our components were missing key guidance around how to use them and what problem they were designed to solve.
- There was no real contribution model in place. It felt like a closed system and suggesting new additions / challenging old ones wasn’t clear.
Formulating what we wanted from our design system
From the initial discovery, we could quite clearly outline what it is that we wanted from ATDS, and therefore define what we feel makes a good design system. Here is what we set out to achieve. *Inhales deep breath*…
Complete parity between Figma (design) and Storybook (code) to increase confidence in using the system to design and create new products and experiences.
A clear organisational structure to keep our system organised and clearly define different levels of component complexity. Also, to aid navigation for anyone using it.
Documentation for every component to provide the relevant guidance where needed and record what our individual components do and why. Including details around best practices for the content within those components and accessibility considerations.
A clear reference for contributing new components to remove the confusion around what processes are in place to help the design system grow and expand in the correct way.
A more community-based approach to take away that feeling of ATDS being a restrictive tool that is owned by fewer people and turn it into a means for collaboration and something that feels like a living, breathing entity that everyone continually helps to evolve.
Easily accessible and usable for anyone to allow anyone to access and learn about the system easily. From designers and developers to product people. New starters to the company and people who have been in the company decades.
Measurable to allow us to record whether the changes we make to the system work for the people using it and help us continually identify ways in which we can continue to improve.
So just to recap. We had a design system in place which we reviewed and gathered feedback for. We identified exactly what our design system needed to do to be successful and from that, we formulated a vision for what a good design system looks like through our lens.
Part 2 will go into how we acted on this initial discovery work and started to make changes to our system. Expect to read about:
- Why we took the decision to re-build our Figma component library.
- How we roadmapped, planned and rolled out our changes.
- Achieving parity between code and design.
