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.
Act I — Chaos
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 the group, the same interface questions were answered independently, over and over, with no shared foundation to build on. Then coherence became a strategic objective — the how was open, and mine to answer.
Delete this?
Are you sure you want to remove this permanently?
> rm item_2041
Same action. Three interfaces — three design languages.
This doesn’t scale. Every new tool started from zero.
Act II — Discovery
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.
Act III — The insight
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.
Delete environment?
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.
The community of practice
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 — mandated from above as strategy, owned from below by the people it binds.
Every decision is made where everyone can see it.
Open critiques and shared rationale mean the reasoning travels with the answer, never siloed in one team’s heads.
Anyone can propose a pattern.
The system grows from the teams who use it. Real problems come in from the edges and get answered once, for everyone.
Newcomers join a running conversation.
People pick up the why behind each rule, not just the rule, so the group gets sharper with every decision it makes.
Act IV — Building the infrastructure
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.
↓ assemble into one component
Approve request →color · radius · spacing | type · states · focus
↓ compose into a reusable pattern — same component, reused
Approve access request?
This grants the requester edit access. You can revoke it any time.
Results
From isolated decisions to shared memory.
A new tool now starts from 41 solved problems instead of zero. Within a year, the community ran without me — and today the design system, including its MCP server, is part of CERN’s official tech stack. Every AI assistant inherits the same decisions as the teams.
Reflection
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.