Building (re-building) the design system at Auto Trader (Part 2)
ATDS = Auto Trader Design System
In Part 1, I wrote about how we went about identifying and defining what a ‘good design system’ looks like to us, and the things we set out to achieve to be able to make that a reality. This next (and much longer) part is all about how we worked towards the objectives that we had set and made a considerable change within our design system space, specifically our Figma library.
The title of the next section will give you a subtle hint into our starting point…
We re-built our entire Figma library
As mentioned in Part 1, we had a consistency issue in that our design library in Figma wasn’t doing a very good job of matching our coded components stored in Storybook.
At the time, our Figma library was being used daily by our design team, and so the issue of consistency was something we had high on our list of things to fix. Essentially, the longer our designers were using out-of-sync components, the more damage and future tech and design debt we were creating.
Did you really need to start the whole thing again, I hear you ask?
Yes. Yes we did. And these are the 3 main reasons why:
1) As previously mentioned, our current Figma library was in use. Trying to update, change, add and remove components that were actively being used in various projects was an added complexity that we simply just didn’t like the sound of.
2) Large new features in Figma had recently become available in Variants, Properties and Auto Layout — meaning that all our components could now be built much more effectively than they were at the time. Starting again meant that we could also learn to use these new features along the way.
3) In the grand scheme of things, our library really wasn’t that big. If we were going to re-build a fresh library from scratch, now was the time to do it.
By creating a new library, it gave us the freedom to build it properly — and with less pressure than working directly on our active one. It was also an opportunity for us to take some of the issues we currently had and turn them into questions for how we could improve our new library along the way. Such as…
- How do we make working and updating a live library much less scary in the future?
- How do we ensure that we’re always up to date with the latest Figma features and best practices that are beneficial to us?
And most importantly…
- How are we going to avoid ending up in the same position again?
So, it was decided. We were going to build our Figma library again, from scratch, and we had a lot of work ahead of us.
The roadmap
To organise the tasks that we had ahead of us and give ourselves a rough idea of time scales that we’d be working to, we created a roadmap.
Within our roadmap, which spanned the length of around 6 months, we plotted our objectives to get us from essentially nothing, to a new Figma library — all rolled out for the design team to use.
The objectives we had along the way consisted of things like initial sessions and alignment on what systems we would use, how we would work and rollout our changes, gathering feedback on how we were going to build our new components and the obvious tasks around actually building the components themselves.
Our roadmap naturally took shape into 3 main ‘phases’.
Phase 1 was to publish the first half of our library, our Foundations and Elements layers. This would allow our designers to start updating their work with the real fundamental parts our design system and give them access to the bare necessities like buttons and form fields.
Releasing the first half of the library as soon as it was ready also gave us a chance to trial it with the team and gather any feedback they had whilst we worked on the other layers.
Phase 2 was very much like the first, but publishing the second half of our library, our Patterns and Collections layer — and further thinking around our apps components and where they fit into the wider library and system.
Phase 3 was around starting to de-commission the (now) old library and any extra objectives that weren’t deemed an initial priority, such as building up some additional templates of our core pages for prototyping.
Making a start
So, at this stage we had a vision of where we wanted to get to, road mapped into a set of stages to get there and a solid starting point to get us going. The next step was simple. Start.
We started by creating a brand-new shared Figma library, with each folder representing each atomic layer of the design system. This was no real change for us so far, as it was the format that we were used to and that we had found worked well.
This time however, we added in an additional space for any (and all) exploration work currently happening on the design system. This was essentially an open space to encourage designers to experiment with future improvements or contributions to the system, in a space that was visible and accessible to everyone.
Within each Figma folder (eg. Elements) we created a separate space for each component, and split them out into each of their individual variants. Each variant represents a different way in which that component can be adapted and displayed. For example, our button component has variants that represent each state (on hover, selected, inactive etc.), the presence of an icon, and if so, where that icon can be positioned.
These variants directly reflect all of the ‘props’ that are built into the coded version of the component and so we were still maintaining consistency across platforms while working with these new Figma features.
Having all these instances built in as variants on Figma means that our designers are just using and locating 1 adaptive component at a time when using the library, rather than sifting through a ton of separate component instances for each state or possibility. Which helps simplify our system and make it more usable for everyone.
For our larger components, we used variants to represent responsiveness, and how components display at different viewport sizes. Auto layout helped us to mimic responsive behaviour when working ‘in-between’ these main viewport sizes.
Finally, to achieve the best consistency we could, we built each of our Figma components up by using the code and CSS values from the coded components themselves.
How we rolled it out
Within ‘Phase 1’ — we ran some design critique sessions around how our (then future) components were going to be built in Figma. This allowed a lot of the design team to have a play around with using components and ‘variants’ within Figma and feedback around what might work best for the team.
Not only did we gain great feedback, but running these crit sessions worked heavily in our favour as when it came to moving to the new library, the team were already somewhat familiar with how to use these newly created components. Not only that, but running those sessions also meant that the whole team were getting involved in the changes we were making. Creating a community around the design system was one of our underlying objectives, as we had previously felt like our design system was a closed project — so it was incredibly important to make our system feel like it was something we could all be a part of.
While rolling out, to support with migrating the team over, we created a shared document on Miro which basically explained what was happening, what to expect, and how to start using the new system — which we did for each phase.
This meant that everyone had something that they could read in their own time, refer back to if necessary, and share among others (which was especially helpful getting those that may have been away at the time and missed any announcements up to speed).
Once the new library was rolled out, the design team were using it, and we felt confident that it was holding up, the main objective was slowly making the ‘old’ library disappear…
Throughout the entire rollout, we kept the ‘old’ library active while people were getting used to the new one (just in case something really went completely wrong!) — but asked that the team turn off any links to it, to avoid any accidental use.
After a few months we then started to silently ‘un-share’ the old library until we were fully migrated and using the new system. Hooray!
Tracking the change
How did we know that the new system was a success?
Apart from the feedback from the team that had been involved throughout the process, one of the things we tracked (and learned along the way) was how to use Figma analytics.
Through the built-in analytics feature, we could see that over time, our Figma system was gradually getting more and more usage where it should.
We monitored this over time and saw the usage climb and keep a steady constant. We could also see that component ‘detaches’ were low, which we took as a positive indicator that our components weren’t causing frustration and working as expected.
Something that was especially useful in the beginning were the weekly ATDS (Auto Trader Design System) drop-in sessions that we ran. Essentially this was an open slot each week for anyone to join and discuss, feedback or ask questions around anything ATDS related. This was another way that we could get a gauge on how well our new ATDS library was working for those using it.
One other thing we have also done, and have continued to do since then, is run surveys around how people are finding the design system generally. This helps us track changes and highlight areas for improvement, which can then filter down into future objectives for us to work on.
The result
We now have a much more effective and accurate Figma library for our design system. There is a much clearer understanding of how our components are built — and the refreshed library has led us to on a path to craft a much better way of working with design systems.
From here, we have started to explore further things, like how we update our system through using another new feature in Figma ‘branches’, and linking our library to Slack for shared updates to our system. We even have a shared channel where we post updates around new Figma features so we can all stay up to date.
Because the library, and the way it has been built has been improved, we’re starting to see more of a culture emerge around our design system too. More people are taking an active interest and getting involved in it’s future and continual improvement — which stands us in a much better place going forwards, as we still have a long way to go.
This piece of work was a journey to say the least, but I think ultimately it helped us solidify a large part of our system and the way we work for the long term. If we can evolve as we go from here, and we don’t have to start from scratch again, then I think we’ve done alright!
