Design systems on steroids
We’ve learned an awful lot by pushing Figma (and occasionally ourselves) close to breaking point to build Realm, our design system.
If you’d told me when I first joined Kingfisher that in three years’ time I’d have helped to build a design system from the ground up not just once, but twice, I’d have said you were joking. In fact, if we’re being honest I would’ve had to ask you to back up for a second and explain what a design system actually was first. Because strange as it may seem, despite having worked inside large corporates as a Designer for over twenty years, I’d never come across or used one before. In fact it says a lot about how widely and rapidly design systems have been adopted that today, no-one bats an eyelid about them.
In the spirit of jumping straight in at the deep end, what we needed to create for Kingfisher was a complex beast. In hindsight, perhaps the naivety that came with never having done this before was actually a blessing in disguise — coming in with no real preconceptions meant we approached everything with no self-imposed limitations on the art of the possible.
If you spoke to us now of course, we have the benefit of experience (and no little amount of hindsight). We’re a small team, and we hit a few bumps in the road as we were getting our design system set up; not everything we tried worked — we built and re-built the button component seven times in order to get it the way we wanted (much to our managers’ chagrin, and we can only apologise profusely for any premature grey hairs he’s found as a result).
What makes Realm so demanding is that it’s like an onion; peel back one layer and there’s a whole load more layers underneath. It was the sheer amount of functionality that we had to take into consideration when piecing it together — something that worked for numerous products, over multiple platforms, in different screen sizes and for different brands.
All design systems have to deal with some of these aspects, and truthfully there have been days when I would happily have bitten your arm off to have worked on one of those systems instead. But it’s still reasonably rare for a system to need so many levels of complexity all at once, each of which asks fundamental questions of the team and how we work. It’s putting them all on top of each other that exponentially increases the challenge, as each is liable to have an impact on the others.
It has to be multi-product
We’ll start with this, and already it’s a big one. Kingfisher doesn’t just support one product. It actually supports several, each with different audiences and requirements.
We have the main eCommerce website, which does the bulk of our trading and is the one most people would be familiar with. But there’s also an eCommerce app that contains a lot of the same journeys… plus some additional functionality, all designed around mobile devices. The handset that colleagues use to run and stock the stores? There’s a product for that. The self-checkout kiosks for customers? There’s a product for them too. The manned tills and Electronic Point Of Sale (EPOS) machines? Yep, you guessed it.
Each of these products are made up of more or less the same things at a very functional level — text, buttons, form fields etc — but the actual construction and presentation of them can differ wildly. Website buttons for example are designed to be 44px high with a minimum of 16px padding left and right, in line with best practice to make them an accessible, clickable size. On an EPOS till though, that button is boosted up to 68px and the padding to 40px to meet the specific needs of that product, its users, and the particular device it’s displayed on.
Realistically one component library is never going to be able to rule them all, as there would be an overwhelming amount going on inside; too many options for Designers to have to handle, and too many opportunities to make mistakes. Not to mention the work and maintenance involved on the library itself and keeping it organised.
Our answer was to split the products into their own separate component libraries. Some of the larger products needed additional, extension libraries to support features or journeys that aren’t considered ‘Core’ or site wide. But by grouping them into distinct Figma projects, they’re all housed in the same place, so there’s no ambiguity over what to use and when.
The flip side of course is that it does mean we have a lot of libraries to look after. And yes, the argument could be made that we’re duplicating many of the components. On balance though, it’s a trade-off we’re happy to make for the benefits of clarity and ease of use for the teams’ day-to-day.
It also needs to be multi-platform
Tied into supporting multiple products, we also had to take into account that they can be designed to work on web, iOS, and Android devices.
This really cemented the idea of running multiple libraries, as each of those platforms has their own styling conventions and system components. It was actually a hotly debated topic — do we have a single dialog box design that runs across every platform, or are users expecting to see a Material looking dialog on their Android device?
We aim to be consistent and cohesive in everything that we design and at first glance, a single solution felt like what we ‘should’ be doing. But patterns exist for a reason. Rather than create custom look and feel that might also negatively impact performance, we agreed that certain native elements should just remain native. That way, users know what something is and how to interact with it without having to take any time to think.
We set up small ancillary libraries to contain those components that were unique to Android or iOS and stored them in another Figma project. As a bonus, it meant that anyone could use them as they weren’t product specific — design files for both the customer facing app and the colleague facing app could link to the Android library and grab a keyboard component without bringing in another products’ component set.
Don’t forget it’s multi-size
We have our set of products with libraries to power them, and we have the ability to support different platforms. It’s getting there, but it’s nowhere near done yet. Now we’re starting to get into the actual components themselves, we have to think about sizing.
Products like the tills or self-checkouts are designed for a particular device and at a very definite size. On the other hand, the website content needs to respond from a small 320px phone all the way up to a 1396px desktop screen, and that means the components do too.
For some, the typography and spacing need adjustment as the component shrinks and grows. Others can change layout to make better use of space, often quite drastically. A few will remain constant no matter what the screen size. So, for each component that we create, we also have to give Designers the right version for the right screen size.
To that end, we’ve used Figma variants and component properties to create the responsive behaviours that we need. Changes to sizing, spacing or colour are traditional variants, all using constructed with auto-layout so that they’ll flex inside their given breakpoints.
We’ve also been able to eliminate a large number of variants by using text, image swap and Boolean props to control the visibility and content of component elements. We bring in the mobile-sized, most common option as the default and let Designers configure it from there using the toggles, dropdowns, and inputs.
And now make it work for multi-brand
As if all that wasn’t enough, we also have to consider branding.
Kingfisher is a group made up of several home improvement companies across Europe — B&Q, TradePoint, Screwfix, Castorama and Brico Depot. In fact, the name of our design system, Realm, actually came from the collective noun for a flock of kingfishers.
The thing is, each brand inside the Kingfisher umbrella has its own unique identity, from typography, icon set and colour all the way through to tone of voice. They can also have different propositions, different legal obligations, and different customer bases for what is essentially the same product. In some ways, ensuring that each company sees designs that are representative of their brand guidelines is one of the hardest parts of the whole design system.
We’ve set up one last Figma team to sit parallel to the one for component libraries to contain groups of theme files. Just like the libraries, it’s sub-divided into the different products, so all the themes that power the website for example are kept together.
Themes look after as many of the branding decisions as they can, containing the font and typographical hierarchy styles, icon and illustration sets in the house look and feel, and all of the colour styles to apply to elements of the components. A theme can be whatever we need it to be — for a particular brand, for light and dark modes or sometimes both.
All that really matters is that within a group of themes for a product, each file contains the same styles with the exact same names, as these also feed through to our design tokens. So, every theme for the website product contains a colour style called Button/Primary for example, but the hex code that lives behind that name is different per file.
To see a design in a different theme, all a Designer has to do is run either Figma’s in-built Library Swap function, or use the Themer plugin. As all the style names are the same, the designs seamlessly change branding in one or two clicks.
But have we succeeded?
The answer to that is (of course) both yes and no.
We have indeed been able to build something that allows a Designer to create journeys and designs for any of our products, displayed on a range of devices, at any breakpoint and in any brand identity. But that isn’t to say what we’ve created is perfect.
Our goal is to take theming and customisation even further. This year we’re aiming to support more complex styling based on the unique brand identities and really push those boundaries. We can already play with fonts and colour, but aren’t yet supporting things like border radii or theme specific sizing or spacing. We‘re also going to wrap our heads around a simpler way of handling our icons, as we haven’t got that completely optimised yet.
But overall, we’ve made a huge first step in getting design systems established in the business and within the team. If you’re interested in how we started our journey, my colleague Mike Heaver sets out our first steps in Designing Kingfisher’s design system. We’d also love to hear if you’ve experienced any of the same challenges we have in creating a design system, and how you solved them.
