Compare the Market’s Design System
An insight into Compare the Market’s design system, being the first fully dedicated design resource managing close to 3,000 components, and moving from Sketch/InVision to Figma/ZeroHeight.
How we got here:
In the early days of Compare the Market, there was no design system, in fact, there were very few standards or patterns to be seen. Every product was responsible for their experience, which naturally lead to having fragmented experiences, multiple shades of blue and green, and siloed codebases.
This continued for many years until around 2018 when there was some appetite to start to align the visual language, alongside building out shared React components.
Why do we need a Design System?
To improve consistency and cohesion across the Compare the Market estate; when people use CtM products, whether it be an insurance journey or claiming a reward via the Meerkat App, we want it to feel familiar because it’s all made up of the same visual language. We’ve gone from a time of people using a single comparison site to compare several insurance companies, to people comparing multiple comparison sites.
2018–2020
From a design perspective during 2018 and 2019 we tried resourcing the design system in several ways; from everyone in the team spending 1 day a week contributing, to having a couple of dedicated designers working on this part-time, which we made a lot of progress with, but with the business fully bought into the concept of having a design system, it needed dedicated design resource.
We were quickly becoming a bottleneck where we had a dedicated engineering team focussed on building out our shared React components, but not enough design resources providing validated and accessible design, alongside detailed documentation.
Because of this, we were also seeing teams across the business still building or customising their own components because we didn’t have everything they needed. Something needed to change.
The 2020 reset
Building a design system is all about learning, adapting, and iterating — I don’t think this is any different for the team working on it. 2020 was the year of a full-time engineering team, dedicated design resource, and even a product owner! It was time to reset and give this another go. That dedicated design resource was me….
Tooling & documentation
At this point, the design team was all working from Sketch, and at times, unmanaged Sketch libraries. The design system was also being created and documented inside sketch as well, and version-controlled via Abstract — which was then synced to InVision. Having the design system set up this way meant that creating or editing any documentation became a design task in itself, and documentation was being updated, but not the libraries and vice versa.
I spent some time with designers and engineers, observing how they would go about using the design system and it was immediately clear the way we had things set up was just not fit for purpose. Links were broken, pages/content isn’t searchable, access issues and not having the single source made it extremely difficult to use, and to actually trust.
The first step to try and alleviate frustrated designers and engineers was to introduce a single source of truth that is then synced to accessible documentation. I spent a couple of weeks updating and fixing the Sketch library so that designers could use it, and had trust in the components they were placing into designs.
I then turned my attention to how and where we were going to document the design system so that it could be synced with Sketch, and any further documentation could easily and quickly take place. We narrowed it down to 2 tools. ZeroHeight and DSM (InVision Design System Manager), whilst they both had pros and cons, at the time ZeroHeight was going to provide us with the most benefits.
The next few weeks were spent migrating all of the documentation from Sketch (via Abstract) into ZeroHeight — this was a painstaking task, but I knew once it was done, we could start to move at speed….. unless we decide Sketch isn’t quite right for us anymore and move to Figma.
We moved to Figma…
That’s right, just when I had set up a single source of truth in Sketch and all of our documentation in ZeroHeight, we decided to not renew our Sketch licenses.
This migration was a bit quicker though, as the import into Figma was fairly smooth and then all we needed to do was to feed the new components into ZeroHeight — the content remained the same. This was another validation that moving to ZeroHeight was the right decision for us — and a fairly seamless experience.
For anyone finishing off projects in Sketch, they still had the updated Sketch library available and for anyone starting new projects in Figma, the Component Library was available from day 1 — all further updates would only be done in Figma.
Our Figma setup was fairly basic at this point, we had 1 component library that was owned by myself, only certain people within the design team having edit access. What this meant, in reality, was regardless of which platform you were designing for, you would get absolutely everything e.g. designers working on the web would also start to see iOS and Android components and vice versa.
The separation of libraries
This was a fairly straightforward decision where I split the single component library into 4:
Global DNA: This is what makes Compare the Market look and feel the way it does. Logos, colours, typography, animation, elevation, etc
Web: Components that are used on Compare the Market’s websites across the estate
iOS: Components that are native to the iOS platform
Android: Components that are native to the Android platform
There were multiple benefits for us doing this
- I can toggle on DNA by default for all designers via Figma admin controls
- Designers can then toggle the correct library for the platform they are designing for
- I can publish and sync libraries independently of each other
Accessibility
It’s been well documented that Design System presents an opportunity to build accessibility and inclusion from the get-go, both from a design perspective and also from a code perspective. That said, making each component accessible doesn’t guarantee that the whole experience is accessible.
We aren’t perfect, but we are trying — there is recognition at Compare the Market that accessibility and inclusion are really important for building successful products.
Maintaining our newfound consistency
The design system is never finished. Maintaining, improving, and evolving the design system takes a lot of time and effort — there is rarely a day that goes by where I don’t publish an update to the Design System. This could come in the shape of Figma releasing AutoLayout and Variants so I work my way back through the design system enabling this for the rest of the team, components not working as expected, or collaborating on projects that evolve and improve the design system.
We use Jira to capture and prioritise the design system backlog, and everything is tagged with emojis:
💭: General feedback
📝: New component/documentation
💅: Component/documentation improvement
🐛: Component Library bug
The library is also open, not literally, but we actively welcome contributions from other designers — contributors then become advocates for the library and it continues to organically grow.
Design System ceremonies are also vital to the success of maintaining and improving the design system, these range from dedicated sessions with the engineering team, design reviews with other designers to catch-ups with individual product owners.
The best way to summarise the size of the design system, and the number of components we are currently managing would be to put it into some numbers (as of the time of writing this):
Global DNA Library
Colour Styles: 61
Text Styles: 58
Effect Styles: 9
Web Library
Components: 1,680
iOS Library
Components: 731
Android Library
Components: 551
Design System Updates
Figma releases: 269
Our dedicated design resource has also recently just doubled in size with Daniel Giscombe joining us after spending nearly 10 years at Auto Trader.
What’s next?
Onboarding more of the CtM estate
The majority of our time has been spent focussing on comparison journeys, but now we are starting to move our attention to other areas of the Compare the Market estate, starting with account and marketing/landing pages.
Accessibility improvements
We have committed to meeting WCAG 2.1 AA accessibility, so we will continue to follow and comply with accessibility and inclusion best practices.
iOS and Android focus
Whilst we do have iOS and Android libraries available, mobile hasn't had the same level of focus, both in terms of design and engineering as the web.
Analytics
We will be spending time getting under the hood of the Figma analytics feature to better understand how the various libraries are being used. It’s important for us to understand what components are being used, detached, and what components aren’t being used at all — and why.
The question you’ve been wondering all along…
What is our design system called? To cut a long story short, it’s named after African animals (Meerkats can be found throughout the desert landscapes of Southern Africa). We’re currently on our third iteration of Design System, so, Chimpanzee. The next iteration will be DikDik, which is where I’m sure someone will put a stop to all this 😅
A massive thank you to everyone who has contributed to Compare the Market’s design system over the years, there are too many to individually call out, but you know who you are.
I’ve purposely left this very light touch on the engineering side of things, I’ll leave this to someone a lot more qualified in that area to write some words.
I hope you enjoyed gaining a little insight into the work of the UX team here at comparethemarket.com, stay tuned for more!
Thanks for reading, Jase.
