Work — Design Systems
Building the design system that teams actually used
1,000+
active users
15,000
component inserts
2,300
weekly NPM downloads
The ask: create one system for 80 teams who have no shared standard
80 teams across multiple organisations, all building on different foundations, with nothing shared between them.
Same problems solved different ways. The accessibility was inconsistent, security decisions varied by team, and organisations duplicated work they should have been sharing.
This work was delivered under NDA, so what follows stays high-level by design.
Adoption was the goal
You can’t force 80 teams onto a system. They had to want it, which meant it had to be better than what they were already using, not just mandated on top.
We supported migrations directly rather than handing over docs and hoping they implemented the system correctly. Ran roundtables so teams could raise problems in front of each other instead of one by one. And embedded with individual teams for a couple of sprints, training them up until they didn’t need us.
Embedding is the expensive option. It’s also the only one that gets a team past the first hard month, which is where adoption usually falters.
Agree the functionality before anyone designs
I brought in Agile ways of working and a Definition of Design Ready. Design started only once a story cleared it.
The gate was simple. The whole team shared an understanding of the story, it was sized to fit one sprint, and it stood on its own rather than tangling with other work. If a story was too big it got split. If it overlapped another, they merged.
Process for its own sake, it sounds like. But it removed the back and forth that was eating into every sprint and instead let designers get on with the craft.
Here’s how that held together, from sprint rhythm down to a single ticket.
A two-weekly cadence kept every team’s sprint planning, refinement and retro in sync, ending in a combined playback.
Work moved through refinement, development and testing against a shared Definition of Ready, before release to the live Figma library and microsite.
Every ticket’s status was visible in Jira, gated at Accepted by the Definition of Ready before it could enter a development sprint.
A single ticket’s path: raised by the community, designed, signed off, built, then tested and documented before it closed.
The workflow that kept 80 teams moving in step
Every component shipped with its documentation
Not documented later. Shipped together on the microsite.
Usage guidance, accessibility, clear standards teams could follow without asking anyone.
Not every request made it in
Teams asked for components that were easier to ship than to use, or that didn’t meet our accessibility bar. I said no to those, and instead worked with them to identify the correct way forward.
A design system is only worth adopting if teams can trust it by default. The moment you let something inaccessible or awkward in, every team has to start checking again, and you’ve lost the one thing the system was for.
Two testing tracks
Design ran UI testing, development ran automated testing, and weekly user sessions kept both aligned.
Accessibility problems surfaced while they were still cheap to fix and not widely published.
2,300 weekly NPM downloads proves teams are using it
That’s teams installing the components straight into what they’re building.
1,000+ active users. 15,000 component inserts.