Hundreds of tools. Dozens of teams. The same decisions, made again and again.
Inside CERN’s Business Computing group, with its five product groups and their teams, everyone kept solving the same interface problems from scratch. I helped them stop, and found the answer wasn’t the one I expected.
This grants the requester edit access. You can revoke it any time.
Every team was quietly solving the same problems, in different ways.
CERN’s Business Computing group runs 200+ internal applications: modern tools alongside systems under continuous development for 30+ years. Across five product groups and their teams, the same interface questions were answered independently, over and over, with no shared foundation to build on.
This doesn’t scale. Every new tool started from zero.
I wasn’t looking for components. I was looking for repeated decisions.
So I stopped looking at the interfaces and started taking them apart. Under every confirmation dialog, no matter how it looked, sat the same short list of decisions.
Recurring decisions scattered across CERN tools, clustered into the standards they became.
It was never about buttons. It was about decisions made too many times.
I realized consistency wasn’t the goal. Reducing repeated decision-making was.
This permanently removes all data. This can’t be undone.
A design system captures that decision once, and remembers it for every team that comes after.
This is what I was really building: a community that learns out loud.
Standards don’t hold because they’re written down. They hold because people trust them, and trust is built in the open. So I ran the system as a community of practice: a standing group where designers and engineers from every team decide together, critique together, and grow the same shared judgment instead of re-earning it alone.
Open critiques and shared rationale mean the reasoning travels with the answer, never siloed in one team's heads.
The system grows from the teams who use it. Real problems come in from the edges and get answered once, for everyone.
People pick up the why behind each rule, not just the rule, so the group gets sharper with every decision it makes.
Only now do tokens, components and patterns matter, as the implementation of the insight.
Three layers, each building on the one below, built on the tooling already used across BC, so it fit existing workflows instead of adding another layer to maintain.
Tokens snap together into a component. The component composes into a pattern.
Six shared decisions (colour, radius, spacing, type, states and focus) agreed once between design and code.
From isolated decisions to shared memory.
I used to think design systems were collections of reusable UI.
Design systems aren’t collections of components. They’re organizations deciding which problems deserve to be solved only once.