28
Designers across 10 Pearson product teams
1,000+
Button variants our audit found across their systems
80%
Of teams integrating the toolkit within 4 months, 8 of 10
Industry
Education
Role
Design lead
Team
6 at YLD: 4 designers, a developer and me
Pearson had a new brand, and ten product teams needed it in their products. Each team had built its own design system, and none could become the base for everyone. I led a team of six at YLD, working alongside Pearson’s 28 designers, to build one toolkit for all of them. We let each team choose how far to go, and 8 of the 10 were integrating it before the project finished.
Pearson’s new brand had to reach ten products that looked like they came from ten companies
We’d just built a design system for Pearson’s online shop, so its Head of Product asked us to do the same for its products. They range from learning apps for kids to university tests and training software for companies. Pearson had bought most of them. None shared a base, and each one looked like it came from a different company.
Pearson’s own designers were busy keeping those products running, and no one team could build for the other nine. So Pearson wanted an outside team to work with its brand team. The job was accessible UI with some flair.
Six of Pearson’s products before the toolkit
Ten teams across eight time zones, and many had never worked together
We worked with 10 of Pearson’s product teams and their 28 designers, across eight time zones, which meant a few late nights and early mornings. Many of the teams had never met. We set up shared channels and meetings so every team could see our work.
Then we talked to every team and checked every system. Some teams had a few Figma components, some had static files, and a few had well-built design systems. Our audit found more than 1,000 button variants between them. Each team had built something useful for its own products, and we wanted to respect that. But no system was general enough to become the base for everyone.

Five of the teams’ own systems
I led a team of six, and every Pearson team had a named contact on it
My team was four designers, a developer and me. Each designer looked after a few Pearson teams and brought me any problem they couldn’t solve. That way I saw all ten teams before I made a call.
I ran our work with Pearson’s brand team myself, because they had to approve everything before it shipped, and that sign-off was the one thing that could hold us up. So I showed them where we’d got to every two weeks. I also looked after accessibility, and set the rules for which requests made it into the toolkit.
The toolkit team
Design lead
4 designers
1 developer
Nemo
ModernXL
Topaz
Mondly
Fredly
Console
Austin
Channels
eText
Evolution
Ten teams worked ten different ways, so each team chose how far to go
Asking ten teams to rebuild at once would have ruffled some feathers. So we recommended one central toolkit, and a way for each team to join it one level at a time.
At Level 1, a team pointed its own colour and type settings (tokens) at ours, so the new brand arrived without touching a component. Level 2 used our tokens directly and brought light and dark themes. Level 3 swapped in our buttons, inputs and type. Teams kept their freedom where their products were different, and shared components where they weren’t.
Adoption levels
Basic colours and fonts are connected to the toolkit’s core ones, without breaking the team’s token names.
Variables used to the full: theming, light and dark mode and breakpoints, with the same token names across Pearson’s systems.
The aim was for teams to spend their time on real flows and bigger components, instead of maintaining the basics of a design system.
Teams got on board once they could use it in their own files
Not every team was keen, which won’t shock anyone. Every designer had strong views on what a new system should look like, and early feedback came in dribs and drabs, because teams wanted the finished thing before they’d try it.
Our first token names kept tripping up even our own team, so two weeks in, we renamed them by what they do. We borrowed Material’s surface and on-surface pairs, so every background came with text colours that read well on it. One input border replaced 16 different ones, so teams had far fewer tokens to map, and they didn’t have to change how they worked.
Our breakthrough came when we sat with one team’s lead product designer. Once she understood the concepts, she stopped thinking about the system and started thinking about her users. Then the Fredly team mapped our tokens into their own theme layer and could switch between light and dark straight away. Some teams had never had dark mode, and some had no design system at all. Now they had both.
Going live took longer than we’d planned as well. We’d aimed for the end of May, but brand sign-off and moving the files into Pearson’s own Figma pushed it to 2 July, so we kept the demos and office hours going until then.
We recorded every update meeting, Q&A and office hours session, and filed them in Pearson’s design docs. Anyone could catch up in their own time. We also made seven how-to videos, a quick-start guide to adding and using the toolkit.


Every surface came with its own text colours, so light and dark came from the same names. Nemo got both straight away.
A few of the toolkit’s Figma documentation pages, at full length

Importing the Toolkit
How to import the Product Toolkit into your file, and ensure it stays connected to the master for all future updates.
Watch on SharePoint

Inserting Components
Adding components from the Product Toolkit into your design using the Assets and Action panels.
Watch on SharePoint

Component Properties
How to adjust properties and overrides within components once imported from the Product Toolkit.
Watch on SharePoint

Surfaces
An introduction to fill Surfaces, and how best to use the Toolkit variables to create a base layer for your interfaces.
Watch on SharePoint

Typography
An overview of the type styles available in the Product Toolkit, how to apply and dynamic sizing modes set on device breakpoints.
Watch on SharePoint

Buttons
Introduction to button styles, available properties and best practice for creating clear call to actions for the users.
Watch on SharePoint

Light and Dark Modes
A guide for setting up your design files to easily switch between light and dark modes, using the variables in-built into the Toolkit library.
Watch on SharePoint
The quick-start guides we recorded for Pearson’s designers
I only said yes to requests that could work for every team, so it stayed one toolkit
Saying yes to every request would have meant ten toolkits again, and by hand-over there were 72 on one board. My first rule was to solve a request for every team or not at all. Higher Education needed 12px text, so every team got 12px sizes. The first teams asked for a sepia theme, and the answer was a plain no. It served one or two products.
A new component joined the toolkit only when a second team needed it. I wrote these rules into a governance plan, so the calls wouldn’t depend on me.
Toolkit requests
72 requests
Done
Higher Education
Done
Nemo
Declined
Served one or two products
Done
Modern XL
Done
Austin
Done
Console
In progress
Nemo
Not started
YLD
8 of the 72 requests, at hand-over
Contrast was built into the colours, so no team had to check it
The brand had no in-between shades, so I added the missing steps between its colours and checked the contrast of every pair. We gave every background its own text colours, so a designer picks a surface and the text on it is already decided. Every surface and text pair was checked to WCAG 2.2 AA.
The palette kept changing in feedback rounds, so I coded a contrast checker to keep up. I later rebuilt it as Perception, a Figma plugin.
The first surfaces didn’t all pass. Review found some text and background pairs that failed, like an info alert that all but vanished on a low surface, so I rebuilt the ramps and rechecked them before hand-over.
Accent collection
Pass
Primary-on-surface
9.02:1 (AAA)
Primary-on-surface
11.89:1 (AAA)
Primary-on-surface
16.60:1 (AAA)
Secondary-on-surface
6.34:1 (AA)
Secondary-on-surface
5.61:1 (AA)
Secondary-on-surface
4.98:1 (AA)
My A11y Monitor widget, running inside the toolkit file, rechecking every pair each time the palette changed
8 of the 10 teams were integrating it before the project finished
It launched with 8 teams in the beta, and all 8 were integrating it into their daily work by hand-over: 4 at Level 3, 2 at Level 2 or higher, and 2 at Level 1.
Any level counted, because the goal was for teams to start aligning with everyone else and work up, without committing to a redesign of their whole product suite. Higher Education went all in on Level 3 and began merging its systems into one file.
The other two weren’t part of this rollout. Evolution was Pearson’s marketing design system, which my team had spent eight months building before the toolkit. And Mondly already had its own established brand, so moving it onto Pearson’s was a business decision, and a bigger job than switching design system.
Then we handed everything to Pearson’s own team, ready for them to carry on without us: the toolkit in their Figma, the requests on their Jira board, a change log every team could see, the governance plan, and every recording and how-to video.
- FredlyIntegrating, 100% confidence
- ModernXLIntegrating, 90% confidence
- ChannelsIntegrating, 90% confidence
- ConsoleIntegrating, 80% confidence
- AustinIntegrating, 80% confidence
- TopazIntegrating, 80% confidence
- eTextIntegrating, 40% confidence
- NemoIntegrating
- MondlyNot yet
- EvolutionMaybe never
Our team pulse check, just under 4 months after kickoff. It also recorded confidence for seven teams, from 40% to 100%


eText’s AI study tool, before and after the toolkit
What I learnt
Plan the hand-over from day one
An outside team’s work only lasts if the client can run it without you. That’s why the recordings, the videos, the named contacts and the rules for saying no were part of the plan from the start.
A brand is never done in one go
I told the teams it would be foolish to think you implement a brand once and you’re done. So we left them a request board, a governance plan and a change log, as well as the Figma file.
Get teams using it in their own files sooner
Feedback came in dribs and drabs until teams could try the toolkit in their own files. Next time I’d map one team’s tokens to ours in the first two weeks, and show the result to every team.



