CERNEnterprise UX · Design systems · Design leadership

Designing coherence across 200+ enterprise applications.

How I helped establish a shared design foundation — and the operating model that keeps it alive — for CERN’s Business Computing ecosystem.

Organization: CERN — Business Computing group, Geneva
Project: Design Coherence — a shared design system for BC
Period: Oct 2024 – Dec 2025
Role: UX Designer
Worked with: Designers and engineers across five product groups, a system architect, BC management
Methods: Cross-product interface analysis · Pattern definition · Open critique · Workshops and training

The CERN Business Computing design system open on a laptop, a particle detector in the hall behind it.

Apart from the Design System Hub poster, every artefact on this page is re-created for publication — the interfaces re-implemented, the scenes rendered. Internal tooling stays internal; the decisions it encodes are what travel.

At a glance

The problem: The same interface questions, answered independently by every team, with no shared foundation. Every new tool started from zero.
The approach: Don’t ship a component library and hope. Start with a real product — a pilot on EDH — extract what works into the shared system, and make the standard something the teams own, not something they are handed.
The outcome: 112 tokens, 84 components, 41 patterns and a community of practice that ran without me within a year. The system is part of CERN’s official technology stack.

Who did what

Mine: the system’s architecture, the pattern methodology, the contribution workflow, the community of practice, and the workshops that brought teams into it. The system itself was built together with CERN’s design and engineering teams.

01Context

Hundreds of applications. Many teams. No shared interaction language.

CERN’s Business Computing group supports a large ecosystem of internal software: more than 200 applications serving finance, procurement, human resources, logistics and the other processes that keep a research organization running. Some are recent. Others have been in continuous development for more than thirty years.

Internal applications in the Business Computing group: 200+
Product groups, each with its own teams: 5
Years — the age of the oldest systems still evolving: 30+

The CERN design system laid out as one canvas: foundations, tokens, components and patterns around a live product screen. — The system laid out as one canvas: foundations, tokens, components and patterns around a live product screen.

Across the five product groups, teams worked from different technical foundations, product histories and design conventions. Similar interactions were designed and built independently, application by application — the same problems solved again and again, often with different outcomes. Then coherence became a strategic objective. The how was open.

02Challenge

The problem wasn’t inconsistent interfaces. It was fragmented decision-making.

At first glance the challenge looked visual. Buttons looked different, dialogs behaved differently, common workflows used different words. Here is what that meant on the ground — one action, three products:

InteractiveOne destructive action, three design languagesReconstructed for this portfolio

Switch between the three products, then open the standard.

Product A asks a one-line question with no named object and no stated consequence. Product B answers with Yes / No, so the reader has to work out which button deletes. Product C asks nothing at all. The standard names the object, states the consequence, and labels the buttons with the verbs they perform.

Looking past the visual layer showed something more fundamental. Each team was making the same interaction decisions on its own:

How should a destructive action be confirmed?
How should filtering behave?
How should validation errors be communicated?
What does someone need to know before committing an action?

Without shared answers, every application was another opportunity for inconsistency — and every user re-learned the same action, tool by tool. The objective was not to standardize screens. It was to create a sustainable way of making shared design decisions, and keeping them.

03My role

Establishing the architecture and the operating model.

As a UX designer in the Business Computing group, I worked on the Design Coherence initiative: the principles, guidelines and processes meant to harmonize interface decisions across the group. My part of it:

The architecture of the design system — how foundations, components and patterns relate.
The methodology for defining reusable interaction patterns.
The contribution workflow that lets teams propose and evolve standards.
A cross-team community of practice, and the workshops and training sessions that brought designers and developers into it.

I worked alongside CERN’s designers and engineers, a system architect and Business Computing management, and supported product teams in taking UX improvements from problem definition to implemented solution. The work needed product design and organizational collaboration in equal measure: a design system only succeeds if it works inside the existing technical environment and the teams using it actively want it.

04Discovery

Looking for repeated decisions beneath different interfaces.

Rather than start with a component library, I took the recurring interactions apart. The important observation was that visually different interfaces often contained the same underlying decisions. A confirmation dialog, whatever it looks like, has to answer the same short list of questions:

What action is being performed?
Which object is affected?
What are the consequences?
Can it be undone?
How does someone confirm — and how do they back out?

These questions are reusable. Their answers can become shared interaction standards. That moved the system’s focus from visual uniformity to reusable product decisions — the dialects differed, the decisions didn’t.

DiagramFrom scattered decisions to shared standardsReconstructed for this portfolio

Recurring decisions scattered across tools are grouped into pattern families — confirmation and filtering are two of many — and become a numbered ledger of 41 standardized patterns. A new tool starts from that ledger instead of from zero.

05The pilot

Start with a product, not a library.

A component library designed in the abstract asks teams to trust decisions nobody has tested. So we started with a pilot: EDH, CERN’s workflow system for creating, tracking and approving administrative and technical requests — one of the applications in continuous development since 1992.

Designing a real product first meant every component and pattern was proven against a real workflow before it became a standard. What worked in EDH was extracted and abstracted into the shared library. The next product was built from that library, and whatever it added went back in. Then the cycle repeats — each product strengthens the system, and the system speeds up each product.

DiagramProduct first, then the systemReconstructed for this portfolio

Make a product — the EDH pilot. Extract and abstract its components into a shared library. Make the next product with them. Then repeat.

A design system should earn its standards in a real product before it asks anyone to adopt them.

06Design strategy

Three layers of shared understanding.

The system is structured as three connected layers, each building on the one below, so that it addresses interaction quality as well as visual consistency.

Foundations
Shared design decisions — colour, typography, spacing, state — expressed as design tokens and agreed once between design and code.
Components
Reusable interface elements that implement the foundations the same way wherever they appear.
Patterns
Reusable answers to recurring interaction problems, with their behaviour, context and rationale written down.

InteractiveFoundations, component, patternReconstructed for this portfolio

Step through the three layers. On the last one, use the button.

Six tokens — action colour, radius, spacing, label type, hover state and focus ring — combine into one primary button. The same button then drops into a confirmation pattern unchanged: a reused decision, not a new one.

A component defines how something is built. A pattern explains how a recurring problem should be solved.

07Design leadership

A design system only scales when teams participate.

A central library on its own would not have changed how decisions were made. Teams needed a way to bring in new problems, weigh alternatives, and understand the reasoning behind a standard — so I ran the system as a community of practice: a standing group where designers and engineers from every team discuss recurring problems, critique proposed solutions in the open, and agree shared conventions. Mandated from above as strategy, owned from below by the people it binds.

Make decisions visible
Every decision is made where everyone can see it. The rationale travels with the answer instead of staying in one team’s heads.
Enable contribution
Anyone can propose a pattern. Real problems come in from the teams who meet them, and get answered once, for everyone.
Preserve knowledge
Newcomers join a running conversation and learn why a pattern exists, not only what it specifies.

DiagramHow a standard comes into beingReconstructed for this portfolio

ProposalA team meets a recurring problem and proposes a pattern.
CritiqueDesigners and engineers from every team review it in the community of practice.In the open
DecisionThe agreed answer is documented with its rationale.
ReleaseIt ships in the system: components, guidance, and the MCP server.
ReuseEvery team — and every AI assistant in the stack — inherits it.

The next recurring problem starts the loop again — from any team.

A team meets a recurring problem and proposes a pattern. The community of practice critiques it in the open. The agreed answer is documented with its rationale and published in the system — as components, guidance and the MCP server. Teams reuse it, and the next recurring problem starts the loop again.

The aim was a system that keeps evolving without depending on one person — which is the test it later passed.

08Implementation

Fitting shared standards into the existing stack.

The system was built on the tooling teams across Business Computing already used — its patterns and UI standards are based on Material Design and MUI — so adopting it meant fewer new things to learn and maintain, not another layer on top. The foundations, components and patterns became part of the group’s technical ecosystem rather than a separate design artefact.

The design system’s home page on a laptop: 112 tokens, 84 components, 41 patterns, one community. — The system as teams meet it — foundations, components and patterns in one place, with the way to contribute on the same page.

The system also ships as an MCP server, so AI assistants working in the Business Computing stack draw on the same 41 decisions as the teams do. Standards that hold up as development becomes increasingly AI-assisted were part of the design, not an afterthought.

09Outcomes

From repeated decisions to shared infrastructure.

Design tokens defined: 112
Components documented: 84
Patterns standardized: 41
Cross-team community of practice: 1

Before: Confirmations, solved per team.After: One confirmation pattern.
Before: Filtering, rebuilt per tool.After: Filtering that behaves predictably everywhere.
Before: Knowledge lived in teams.After: Knowledge lives in the system.

A new tool now starts from 41 solved problems instead of zero. Within a year, the community of practice ran without my direct involvement, and the design system is part of CERN’s official technology stack. The most important outcome isn’t the number of components — it’s shared knowledge that teams reuse and keep evolving.

Original artefactThe Design System Hub — where teams across the Organization find the system’s styles, components and design patterns. In its own words: a shared foundation for interfaces that are coherent, efficient and accessible.

10Reflection

Design systems are organizational systems.

I used to think of design systems as collections of reusable UI. This project changed that. Their value doesn’t come primarily from drawing an interface faster; it comes from helping an organization make good decisions consistently.

The strongest design system isn’t the one with the largest library. It’s the one that lets teams solve recurring problems together — and keep those solutions for whoever comes next.

Next case study

PwCDesigning trust into enterprise AI.

← All selected work Get in touch →