Hundreds of tools. Dozens of teams. The same decisions, made again and again.
Inside CERN’s Business Computing group — 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.
At a glance
- Client
- CERN — Business Computing group: 200+ internal applications, from modern tools to systems in continuous development for 30+ years
- Role
- Architect for Design Coherence. Mine: the system’s architecture, the pattern methodology, the contribution workflow, and the community of practice. Together with CERN’s design and engineering teams, a system architect, and BC management.
- Timeline
- Oct 2024 — end of 2025
- The problem
- The same interface questions, answered independently by every team, with no shared foundation. Every new tool started from zero.
- The decision
- Don’t ship a component library and hope. Reduce repeated decision-making — and make the standard something the teams own, not something they’re handed.
- The outcome
- 112 tokens · 84 components · 41 patterns · one community of practice. Within a year it ran without me. The system — including its MCP server — is part of CERN’s official tech stack.
All artefacts on this page are re-implemented for publication. Internal tooling stays internal — the decisions it encodes are what travel.
Act I — Chaos
Every team was quietly solving the same problems, in different ways.
CERN’s Business Computing group runs 200+ internal applications covering finance, procurement, HR and logistics. Across the group, the same interface questions were answered independently, over and over. Then coherence became a strategic objective — the how was open, and mine to answer.
Here is what that looked like on the ground. One action, three products:
Delete this?
A one-liner. No named object, no stated consequence, no way back.
Same action, three design languages — and the one standard that replaced them.
This doesn’t scale. Every new tool started from zero — and every user re-learned the same action, tool by tool.
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: what to name, what to warn about, which verb goes on which button, what happens on escape. The dialects differed. The decisions didn’t.
Recurring decisions scattered across CERN tools, clustered into the standards they became — two families shown of many; the 41 is real.
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.
Flip the demo above to The standard: three answers become one. 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.
Six shared decisions — agreed once between design and code.
Foundations, component, pattern — the same decisions, compounding upward.
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 is part of CERN’s official tech stack.
And because the system ships as an MCP server, its newest consumers aren’t people: every AI assistant working in the BC stack inherits the same 41 decisions as the teams. Standards that survive the shift to agentic development weren’t an afterthought here — they were the design.
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.
Are your teams solving the same problems again and again?
I run a 2–3 week coherence audit: we map the decisions your teams keep re-making, agree which ones deserve to be solved once, and you keep the standards — and the operating model that keeps them alive without me. Tangible, while it’s still cheap to change.