Designing Kingfisher’s Design System
First, who are Kingfisher?
Kingfisher plc is an international home improvement company with over 1,500 stores, supported by a team of 80,000 colleagues. We operate in eight countries across Europe under retail banners including B&Q, Castorama, Brico Dépôt, Screwfix, TradePoint and Koçtaş. We offer home improvement products and services to consumers and trade professionals who shop in our stores and via our e-commerce channels.
At Kingfisher, we believe a better world starts with better homes. We help make better homes accessible for everyone.
Now you know who we are, what is this article about?
This article will be the first in a series written by my colleagues and I about Kingfisher’s journey into Design Systems, what we have done and learnt, our successes and our failures.
Do we even need a Design System?
This is a question every company should ask themselves before they begin. There’s no point in following trends or implementing the newest thing if it does not add value to your business. How do you know if it will add value to your business? First of all, you need to understand what a Design System is.
A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
A comprehensive guide to design systems | Inside Design Blog (invisionapp.com)
A Design System is aimed at helping teams scale, reducing bottlenecks, improving consistency and shipping quality designs and code, faster.
We went and found as many different design systems as we could, to see how other people were doing it, learn from them and decide what would be best for our organisation. For reference, you can check out quite a list by following this link: https://designsystemsrepo.com/design-systems/
Design Systems are ideally made up of design and coded components that can be assembled in any number of ways to create your digital products. We decided to break this language up, so that we could have clarity around the different sections that made up a Design System.
The Design Library is a collection of reusable components, housed on our design platform of choice e.g. Adobe XD, Sketch or Figma.
The Component Library is a coded reflection of the designed component on whatever platform/framework is chosen e.g. HTML, React, Vue, PHP etc.
An example of a component could be a button for instance — but we will cover components in a later article.
We did this because the system needs ownership and collaboration between all parties, otherwise it doesn’t work as well as intended. You could just have a suite of Design Libraries, which would benefit Design, but you might not see any improvement during the build phase.
So what?
What makes this so important?
In the market, we were finding there were some benefits to working this way. These included but were not exclusive to:
x2–3 faster speed to market
50% saving for common patterns & journeys
50% reduction in future managed costs due to getting it right earlier (increased UX)
25% increase in efficiency and efficacy of design and development teams (as system matures)
25% faster prototyping due to reuse of assets
Increases usability of apps, which leads to increased adoption and ROI
Increased consistency leads to better brand equity and perception
Why are we doing it?
At Kingfisher, we put the customer first — so we are constantly learning from the people we are designing for. If we can get our designs out faster, we learn faster, we design and build faster with more impact.
This is made even more important as we are building platforms that house multiple brands in different markets, on multiple platforms, each with their own needs and expectations.
We need to have flexibility over how, when and where design happens so this can flex with the ever-changing demands faced by the businesses we work with and the market we are in.
So, what did this look like?
We evaluated our working practices, the length of time something took from identifying the problem/requirement to going live on our platforms. To gauge the viability of what could be achieved, we took a website with an upcoming re-platform and did a proof-of-concept trial for just the design stage at this point, and we would compare this to our current ways of working.
The proof-of-concept involved breaking our designs apart by conducting an interface inventory so that we knew what we would build going forwards and allow us to streamline what we had — highlighting a lack of and improving consistency at the same time.
We then ran the two streams in parallel to see the difference in design time. We did not include the time taken to setup the design library or sustain the library in the results, as we were trying to understand the overall difference if the system was mature and established. The results were very surprising:
To design the entire ecommerce platform, the old way, took 12 weeks of 1 designer’s time.
To design the entire ecommerce platform, the new way, took 4 weeks of 1 designer’s time.
(This is obviously very high level and I’ve saved you from the details, but you can always contact me to discuss further if you like).
That was a noticeable saving, not only in terms of time, but also money and what that designer could then move on to. We were talking the difference of 2 months of iterating and learning. That is massive.
This provided us enough proof to take this further and get buy in for establishing this further (an article on getting buy in will follow at some point in the future).
What did we put together after this?
So, what did we put together after this test and what did we learn from it:
The concept here was that we could design our components on our design platform and then output Design Tokens that would control the look and feel of these. This would allow us to accommodate a multi-brand Design System for each of the companies we work with. These could then be translated into framework agnostic coded HTML components for reusability and a single source of truth for how the component would look, feel and behave. For an alternative route, the Design Tokens could be adopted directly for platforms such as iOS and Android.
Running further tests on this model, reaped some very promising benefits — it gives us a platform that could be exceptionally flexible without changing base code to accommodate multiple themes. We changed to themes, rather than brands, as we discovered the flexibility to introduce themes such as dark mode within the brands. It allowed for an automated pipeline to change that theme instantaneously in both design and code. To also update the styling of a component and see that transverse to code, instantaneously.
What we learnt though, is with great power comes great responsibility. The power to change things that fast could be too fast — what about governance around design library updates, the cascade of what seems like a simple change, could have unexpected results elsewhere. How could we govern and test these changes? How could we roll back if we did discover this? Could we arrange our component differently?
Conclusion
So — during this initial phase, we found that there were potentially massive gains to be had by implementing a Design System into our ways of working. We could see the time benefits but there were other benefits too — there was less time to onboard new members of the team, increased productivity, decreased redesign or inconsistencies reaching the platforms.
We learnt that the simple implementation we had considered ballooned into further discussions around process, team size and location, governance, and suitability of platforms/tooling.
However, we knew we had to take this forward and get further buy in, not only from the teams around us, but from senior management as well. We also needed to test and validate the next steps of making this system grow and what it could evolve into.
But this needed doing, the benefits far outweighed the costs for us.
And so, this is where our journey began.
