Delicately building a design system supporting 1k+ products, only to watch it get put on ice
Why did this happen? Did we build the right thing?
I spent six months delicately building a design system that would support multiple product design teams. Each with unique needs and levels of adoption for Pearson's global rebrand. We built trust. We demo'd. We coached. And we got buy-in. Then, just weeks before the end of the project, a new Head of UX stepped in and pulled the plug!
We'd helped Pearson complete a major rebrand, but their products told a different story
Rolling off building a marketing design system for Pearson, the head of product approached us to apply their new brand to their product catalog.
We'd need to work tightly with the brand team to create a system of accessible UX design patterns, with just enough flair. That includes learning platforms for kids, university assessments, corporate training software.
There was no shared foundation and every product looked like it belonged to a different company. Which, given most were acquired, makes sense.
This was the first time many of the teams had met, let alone worked together
Most of Pearson's products have an aligned team. We got to work with 10 of these teams across eight time zones. Which meant a few late nights and early mornings.
In creating shared channels and meetings to make our work visible we found it was the first time many of the teams had met, let alone worked together! We encouraged an open forum and collaboration.
For weeks, we dug into how each team was managing their design process. Some teams had a handful of components in Figma. Others had static files, and a few had pretty well structured design systems. We audited their design files for structure, naming conventions, and components. And hosted alignment sessions with them.
Each team had built something genuinely useful for their specific context. And we wanted to be respectful of that.
10 teams across 8 time zones, coffee was required.
The real challenge wasn't technical. It was human.
Our recommendation was to build a centralised design system. Like Google material. And a cross-team governance process.
This would let designers use brand approved colours directly into their own files. Colours that are obvious where they should be applied. And provide pre designed components where products already shared a common UX pattern. All without remove too much creative freedom and control from teams.
Not everyone was open to our proposed changes
Shocking, I know, not everyone was open to our proposed changes. And every designer had some pretty strong opinions on what a new system should look like. It was going to be hard work to get the buy-in we needed.
Showing teams how to use the system unlocked the buy-in breakthrough we needed
Early on, feedback came in drips and drabs. Teams were more interested in getting access to the "finished" thing. But they didn't have full access to use it and drop feedback just yet.
Our variables shamelessly stole naming conventions from Material UI. Surface and on-surface pairings for reliable accessible color combinations.
Patterns that millions of designers and developers already understood. We built complete light and dark mode theme support with careful aliasing that let teams map the new system to their existing tokens. Teams could adopt the toolkit without breaking their current workflows.
Our breakthrough came when spending one on one time with Katie Dove, lead product designer. Once she understood the concepts, she wasn't thinking about the system anymore. She was thinking about her users. The toolkit had disappeared into her workflow, exactly what good infrastructure should do.
Then came the Fredly teams breakthrough. When they mapped our variables into their own theme layer, they were surprised they could just... switch. Light mode, dark mode, out of the box. For teams that had never had a dark mode, or for teams without any design system at all, they suddenly had both.
One by one, teams started getting it, and committing. Not just to use the toolkit, but to contribute to it.
By building something flexible, not rigid, we started conversations that would help us refine the system for weeks.
Why the project got put on ice
After four months of progress, a new Head of UX stepped in, and our primary stakeholder changed. With a fresh set of priorities and a new vision for where design investment should go.
We got dragged into an internal conflict and were forced to defend the ROI our solution provided in some pretty intense meetings. We spent more time justifying the work than doing it.
But the metrics and sentiment supported our work and decisions. 70% of teams had already integrated with the system. Designers were moving faster, accessibility issues were history, and brand consistency was on the rise.
In spite of the facts, they decided to shift and invest in "brandable moments". Developing animations and characters, things that looked impressive in executive presentations. Design infrastructure, no matter how valuable, is a hard sell to execs that don't understand it.
Six weeks before our planned completion, the project was put on ice. The remaining budget was reallocated.
So did we build the right thing?
By the time the project was officially cancelled, we'd already delivered the core system. Teams had it. They were using it. They'd seen how it made their work better. They didn't need us anymore.
70% of teams had integrated the toolkit into their workflows. The remaining 30% weren't resistant; they were just further out in their product cycles. But everyone was now equipped to commit to meet the first goals: updating colors and logos by December, even if they couldn't fully integrate.
We'd set out to create a centralised design system. What we actually did was spark a design collaboration movement at Pearson.
Internal politics meant that what the business wanted changed, but that's out of our control. An adoption rate of about 70% lets me confidently say yes, we built the right thing.
What I learned
Don't be too precious, plan your exit from the start
We made teams feel heard, respected their existing work, and gave them a system that solves real problems. So when the project got pulled early, those teams stepped in, because it was theirs. A consultation role is fleeting - so it's important to partner with the folks who'll maintain the project as soon as possible.
Stakeholders can kill the right solution
We measured success by adoption, efficiency, and team autonomy. Leadership had a change of heart at the very end from "consitency and brand alignment" to "brandable moments". This internal change has no bearing on the quality or success of our solution for the former.
