This blog is adapted from a talk at Rightmove ProdDev Data Con co-presented by Caroline Snare, Content Design Manager and Chantal Slagmolen, Lead Product Designer.
A design system is not just a UI kit.
It’s an organisational change programme wearing a Figma hoodie
Building a design system is easy, relatively, but getting an organisation to actually use one isn’t. This is what three years of trying taught us – starting, for reasons that will become clear, with a colour.
Teal has been around for roughly four thousand years, which is a long time for a colour nobody could quite agree on. Ancient Egypt loved it, in glazes and tomb decoration, though they never called it teal. The Greeks and Romans chased the same blue-green through verdigris, the colour copper turns when it ages and goes, in the most beautiful way, slightly wrong. Medieval artists ground up malachite and lapis lazuli to get close to it. For almost all of that history the colour had no agreed name. It was just expensive, slightly unstable, and impossible to ignore, hanging about in the awkward space between blue and green.
The name only arrived around 1917, and it came from a duck. The common teal has a blue-green stripe on its head, and at some point one person looked at that stripe and decided that colour was teal. There was no committee. No brand guidelines. No stakeholder sign-off. No phased rollout. One person, one duck, one decision, and the name stuck because people simply kept using it until it was true.
Hold that thought, because it’s the only easy part of this story.
This was never about a colour
This isn’t really about teal. It’s about what happens when you try to get an entire organisation to agree on something, adopt it, and change how it works.
A design system is never just components, tokens, or a tidy Figma library. It’s behaviour change. It’s delivery pressure. It’s engineering constraints, habits, trust, governance, and a thousand tiny decisions happening across teams every day. Or, as we like to think about it: a design system is a change management programme wearing a Figma hoodie. We learned that the hard way, because we assumed the opposite. We assumed that if we just built the thing, people would use it.
The blue dot
There’s a moment, when a UI Kit goes live in Figma, that’s supposed to feel like a finish line. A small blue dot appears on the library icon. Every designer in the organisation can see it. Behind that dot sit months of work, and in our case years of it, all suddenly available to everyone at once.
We did the sensible things. We sent the announcement email. We ran the onboarding session. We told people the kit was ready and waited for them to use it. And then we watched teams not quite use it.
Here’s the part that took us a while to understand. They weren’t rejecting it. The problem was, the old Figma file was still right there, two clicks away and backed by years of muscle memory. When a team was mid-feature and up against a deadline, the familiar thing won. Most of the time, people weren’t choosing to ignore the system. They were choosing to deliver.
A UI Kit is the part of a design system you can ship. It’s the visible artefact, the library you can point at and say there, it’s done. The design system is the larger, messier thing around it: the way an organisation agrees on how to build, and actually changes how the organisation works. We had shipped the kit and made it available. What we hadn’t done was land the system.
Which is where teal becomes useful again. Teal did not spend four millennia in the awkward space between blue and green because it was broken. It spent four millennia there because value takes time to become obvious. We had expected a blue dot to do in a week what a colour took centuries to do, which is to become something people reach for without being told to.
Before the blue dot, there was Kanso
To understand why a launch was never going to be enough, we have to go much further back. Years ago, our engineers looked at the codebase and kept seeing the same atomic components copied over and over. It wasn’t sustainable, and they knew it. So, they built a small, shared component library and called it Kanso. There was no grand strategy and no name for what they were doing. It was just engineers trying to do the right thing, long before anyone called it a design system.
Then designers joined, and started moving everything into Figma. Then more designers joined, with new ideas, which didn’t always line up with the previous designers’ ideas, which in turn didn’t always line up with engineering’s. Designers had their components in a UI Kit. Engineers had their own library. And before those two things could ever become one, the organisation spent a long time circling a single, deceptively simple question: what’s the source of truth?
About three years ago, the system got its first dedicated designer, later joined by an engineer. What they inherited was years of good intentions, different interpretations, mismatched libraries, and competing Figma files, all of which somehow had to become a single coherent thing. It was less a clean build than an archaeological dig with a design system brief attached.
That’s the part the blue dot hides. By the time a kit goes live, the slow, invisible work of reconciling years of divergence has already happened, or is still quietly going on in the background. Shipping was not the beginning of the story. It was a milestone somewhere in the middle of a much longer one. The rest of this is what it actually took.
Urgency is something you cultivate, not announce
The first thing we got wrong was thinking urgency was an event. A launch, an email, a Friday all-hands. It’s none of those things. Inside a product organisation, urgency turns out to be every small, repeated, unglamorous act of making the system feel real to the people who need it.
So the team did the work. The Storybook. The dedicated Slack channels. The Figma guardrail documents. The screen recordings, the onboarding sessions, the backlog, the decks, and the decks that had decks of their own. Every one of those artefacts is someone quietly choosing to invest their time in making the invisible visible. Most of it happens without anyone noticing, which, we came to realise, is exactly how you know it’s working.
The barrier we did not see coming
We assumed the obstacles would be the usual suspects: process, time, people. The biggest one turned out to be our own brand colours. Our use of teal had been a given for years, but our specific teal was too intense for our designs. On dark backgrounds, and especially on Apple devices, it vibrated and overwhelmed the interfaces it was meant to sit quietly inside. The interesting thing was how we found out. Three separate teams noticed it independently, none of them working together, and all of them landed on the same signal. A palette built for print and web no longer held up in a world that has mostly moved on from both.
What happened next mattered more than the fix. Design, Brand and Engineering sat down together and rebuilt the palette from first principles, for accessibility, for dark mode, for every surface. Removing the barrier was never going to be one person’s call. It was a shared decision, sparked by different people seeing the same problem from different teams.
You feel the shift in the small wins
For three years it had been almost there. Then last November the first properly tokenised, fully mapped version of the UI Kit went live, and the change started to show up in places we hadn’t expected.
An engineer who built a set of landing pages with it told us the work had been completely uneventful, that it was a weight off his mind, and that he had not needed to do any of the translation work he was braced for. We had been trying to earn that sentence for three years. Around the same time, a thank-you appeared in Slack for a colleague whose guardrails had saved someone hours, decorated with a frankly excessive number of heart emojis
That’s what a cultural shift actually looks like. Not a milestone on a roadmap, but a reaction in a channel. That was the moment the blue dot finally meant something.
Belief compounds too. While we were focused on adoption, our engineers quietly built their own tooling, a prompt that migrates components, updates tokens, and even flags the parts that could do with a glow-up. They’d reinvented Clippy, except this one is useful, and it exists only because someone wanted to make life easier for whoever migrated next. Nobody asked them to. They did it because they believed in the system.
It takes a village to build a design system
None of this happened because of the quality of the kit. It happened because of how the system fits into the way people actually work, and that takes a village. And our village was extraordinary.
The engineers who started Kanso before any of this was fashionable. The designer who took years of sketches and turned them into foundations. The business that decided it was worth investing in. The product managers who gave us time when the roadmap had none to give. The designers who kept coming back, even when the system felt heavy rather than helpful. And the engineer who decided that migration didn’t have to be painful, and then proved it.
Standards don’t land through mandate. They land through use
Turns out, teal wasn’t tealing, because tealing was never about the colour. Teal never needed everyone to agree on what it was. It just needed to keep showing up until the value was undeniable. As it turns out, the same is true of design systems.
To celebrate all the work that has gone into getting us this far, Steve Inglis, our dedicated Senior Designer for the Design System, has put together a sizzle reel to showcase not only his work, but the collective contributions of designers and engineers across the company.
