We’re likely all familiar with many great, beautifully presented design systems that quite rightly, the teams involved will shout about. Whether it’s a style guide, a component library or another more individualistic take on what a design system is, there’s a reason these things have so much attention at the moment.

This post isn’t about most of that; it’s not about the tech we’ve used or how lovingly crafted it might be. I think one of the most important and difficult bits of starting a design system is often the bit most overlooked: people.

A year and a half ago, we started on our design systems journey. Not that before that date nothing existed, perhaps the work and conversations were less joined up as they could’ve been. At Auto Trader, there’s not just the main, public-facing website that focuses on cars but other niche vehicles as well as a suite of tools we call Portal. There were challenges around consistency of implementations on the front-end, whether design reviews were able to happen at the right time and feed back in a timely way, to the release process, etc.

Having some kind of design system shouldn’t be taken as a given, I think you have to both be clear on the problems you have and who they affect first. From the first shout out around the company, we got a core team together to share stories, understand each other’s problems and work out where the pain points were. Some of these were process driven, some weren’t consistent in which squads or tribes were affected, some were around communication.

That stage of asking questions and listening was vital, not least because at that point I was new to the company myself but across different part of the business there wasn’t always a need for people to’ve met. In listening, there were naturally a few issues we could look at: how might we get some basic building blocks…perhaps our typography and colours from our design teams, communicate any changes, code these in a peer reviewed and versioned way to be consumed by developers?

Through all of this discovery, we found ourselves with a slow burner project; one that we could talk about the problems it solved and work with people to ensure it would actually help us move forwards. We had designers, front-end developers, delivery, product and content people at various times either contributing to it or helping us understand how to best work it into their workflows.

In getting to know where we were all coming from; listening before ‘solutionising’, I feel like what we now have as a multi-part design system (as young and evolving as it is) wouldn’t be as successful as it has been. From this core group, we’ve brought more people into the fold that act as advocates for the system and a shared desire to do what’s right for us and our problems – in this way, I’m not sure many off the shelf systems could’ve really fit the bill.