Updating a design system
Figma’s new component properties opened up a world of new possibilities, but presented new challenges too.
Realm (Kingfisher’s design system) encompasses a wide range of different products, some aimed at retail customers, others supporting our colleagues in store. But by far the largest and most complicated set of component libraries are the ones that power the eCommerce website.
They’re made up of well over a hundred components, many with a variety of permutations depending on context, or layouts optimised for device size. Often there can be variations based on location, and everything needs to be themed with colour, fonts, and styling for each brand under the Kingfisher umbrella (read ‘Theming a design system’ to find out how we manage that kettle of fish).
The system has only been operational since March 2022, but is already being used by Designers in all of our feature teams, across myriad files, screens and artboards. So, when a major change comes along that needs to be rolled out, how on earth do we manage that without causing complete and utter devastation?
Design systems are never ‘done’
When we made the switch from Sketch to Figma, the Web component library was the first piece of the puzzle we put together — we simply had to get it usable early on in the migration process to enable the team to transition.
We created the library the best way we knew how, using the accepted methodologies available at the time. Base components powered the majority of the library, with variants doing the heavy lifting in terms of customisation options.
Fast-forward to Config 2022, and Figma introduced a whole raft of new features and functionality to the tool. Dark mode, improved auto layouts, properties for components, individual strokes… The Realm team were enthusiastically watching the announcements on the livestream when it dawned on us. Component properties were definitely an exciting step forward, but this meant our shiny new library was already feeling out of date.
So where did that leave us?
Without putting too fine a point on it, feeling caught between a rock and a hard place. Realistically we knew that sooner or later there would have to be a substantial update made to the library. But the Designers had only got up and running with the new version of the design system relatively recently — did we really want to add in more upheaval for them this early on?
As luck would have it, our Researchers were already running sessions to gather feedback on how the team were finding the new system. These (very timely) workshops gave us clear insights into what people liked and where they hoped we could make improvements.
For example, something as simple as editing the text inside a component involved drilling down into a veritable labyrinth of auto-layouts and layers. Add in the fact we’d built all of our components using spacers to extract token values, and the end result was often an explosion inside the left-hand panel.
There was also a lot of work involved for the team building and maintaining the library. In order to create the different combinations of elements needed to support the business, we had to create tens, sometimes hundreds of variants. Base components went some way towards alleviating the difficulty of change, as an update to the one rippled through to all, but it was increasingly feeling like an overhead we could do without.
There’s never an ideal time to make change, and there will always be some degree of pain and disruption involved. If we kicked the can down the road, the likelihood was that the pain would be greater — more people would have done more work using the ‘old’ components, and moving everyone onto the new would be harder.
The general feeling was that we could make this better for everyone concerned, and the sooner we did that the sooner we’d all reap the benefits.
Everything is… complicated
Since we were planning on quite a drastic rework, we did consider building a new library from scratch. But only very briefly.
A second option was to update the library and implement all the changes inside the current components, though a few tests revealed the fatal flaw in that approach. Where variants were removed and new properties added, when the change was published it often broke any instances housed inside existing designs. And we had a lot of existing designs. Text content didn’t always carry through, we couldn’t guarantee icon choices would be retained, and if we’d split the original component into multiple, more contextual ones, the instance in the design would detach completely.
Clearly, we weren’t there yet. We realised that what we needed was a way to keep all of the old components and phase them out, rather than wipe the slate clean in one fell swoop.
Looking at the library and how we’d built our components gave us an idea that might work. We hadn’t wanted all our base components to be visible to end users, so we’d hidden them using a period at the start of the component name. People working inside the library could see and use them, but they were invisible to anyone linking to it.
This all looked very promising, as it would present Designers with the updated components, stop them being able to bring in old versions and best of all, no-one’s designs would break as the old components would still technically exist. It fell at the last hurdle when we noticed that hiding components from Designers also hid them from Figma’s analytics tools. We wanted to be able to track declining usage so that we understood when a component could be safely removed, and if the analytics couldn’t see them then we were effectively blind.
Where we ultimately landed was on an extension of this idea. Each old component would be named and tagged as no longer in use, and moved into a deprecated section. The new build would then take its place, allowing us to monitor both.
Designers, make it work
The Core library had around 150 components inside, many of which were linked to or used by another in some way. Refactoring them in alphabetical order wasn’t going to be an efficient way of managing the changes, so instead we organised them into a list, starting from the smaller atoms and working up to larger molecules and organisms. We couldn’t build Alert for example, without having Icon in place first.
As each component was picked up, we ran some checks to ensure it was rebuilt correctly. We had to be sure that our Figma was an accurate reflection of what was live, and that we’d coped with all the possible variations — in some cases, we had to determine if it was even used any more.
Once we were sure about a component, we could then try to understand if there was a better way of building it. Was it something that made sense to be all in one component, or should we break it apart into multiple smaller ones, each with a specific context? Our original Alert for example was four different types all wrapped up in one. A Designer could choose between variants for error, warning, success or generic, but the preview in the Assets panel only showed generic. Was it obvious that the others were available? And did it help them to know which to use and when?
With all that in place, it was now possible to decide on the properties and variants for the updated component. We were able to strip out a huge number of variants from the majority of the library, which immediately made things feel less overwhelming. Sure, we still needed them to control differences is colour, size or spacing, but on average components were cut down by at least half, often more. Alert used to be a single component with twenty-four variants. Now we just had eight — two variants each over four specific components. If it hadn’t been for some complications with line heights and icon sizes, we could have halved even that.
It’s in beta at the time of writing, but we also saw that the ‘Simplify instances’ functionality could really help Designers when they were working with the library. Text and instance swap properties meant that content could be controlled in the right-hand panel, without having to navigate deep into that layer labyrinth. And if they did open up the layers, all the spacers and elements that couldn’t be edited were neatly filed away.
Lastly, each reworked component was given a bespoke tooltip description, so Designers hovering over it could quickly understand its purpose. More in depth documentation was also produced, to provide additional context for Designers, Developers, and the business alike.
We didn’t want to spam everyone with constant library updates, so fresh components were published in batches, using a Teams channel to communicate the new releases.
How did we do?
All told, reworking the entire Web component library took around three weeks.
Since all the original components were filed them away rather than removed, Designers didn’t experience disruption is any of their existing files. Instances of old components updated to be named ‘Deprecated’ (indicating the need to be swapped out) but remained in tact.
The design system team can use Figma analytics to track adoption of the new components and decline of the old. Once we see outdated items reach a certain threshold, we can be confident that it’s safe to remove them from the library completely without impacting ongoing work.
But best of all, Designers themselves have reacted positively to the change. There has been an almost seamless switchover, letting them phase out the old elements without enforcing any kind of hard reset. The introduction of component properties has been well received too, with the team feeding back that using the library has become easier as a result.
Now that we’ve proven the method works, we can expand it out to all our other component libraries, keeping them up to date. Design systems are always evolving, and even large scale change needed not be something teams are afraid of.
