Hunderte Tools. Dutzende Teams. Immer wieder dieselben Entscheidungen.
In der Business-Computing-Gruppe am CERN — fünf Produktgruppen mit ihren Teams — löste jedes Team dieselben Interface-Probleme immer wieder neu. Ich half ihnen, damit aufzuhören — und stieß dabei auf eine andere Antwort, als ich erwartet hatte.
Auf einen Blick
- Auftraggeber
- CERN — Business-Computing-Gruppe: über 200 interne Anwendungen, von modernen Tools bis zu Systemen, die seit mehr als 30 Jahren durchgehend weiterentwickelt werden
- Rolle
- Architekt für Designkohärenz. Mein Part: die Architektur des Systems, die Mustermethodik, der Beitragsprozess und die Community of Practice. Gemeinsam mit den Design- und Engineering-Teams am CERN, einem Systemarchitekten und dem BC-Management.
- Zeitraum
- Okt. 2024 – Ende 2025
- Das Problem
- Dieselben Interface-Fragen, von jedem Team unabhängig beantwortet, ohne gemeinsames Fundament. Jedes neue Tool begann bei null.
- Die Entscheidung
- Keine Komponentenbibliothek ausliefern und hoffen. Wiederholtes Entscheiden reduzieren — und den Standard zu etwas machen, das den Teams gehört, nicht zu etwas, das man ihnen übergibt.
- Das Ergebnis
- 112 Tokens · 84 Komponenten · 41 Muster · eine Community of Practice. Binnen eines Jahres lief es ohne mich. Das System — samt MCP-Server — ist Teil von CERNs offiziellem Tech-Stack.
Alle Artefakte auf dieser Seite wurden für die Veröffentlichung neu umgesetzt. Internes Tooling bleibt intern — übertragbar sind ohnehin nur die Entscheidungen, die es festhält.
Akt I — Chaos
Jedes Team löste im Stillen dieselben Probleme — auf jeweils andere Weise.
Die Business-Computing-Gruppe am CERN betreibt über 200 interne Anwendungen für Finanzen, Beschaffung, HR und Logistik. Überall in der Gruppe wurden dieselben Interface-Fragen unabhängig voneinander beantwortet, wieder und wieder. Dann wurde Kohärenz zum strategischen Ziel — das Wie war offen, und es lag an mir, es zu beantworten.
So sah das konkret aus. Eine Aktion, drei Produkte:
Das hier löschen?
Ein Einzeiler. Kein benanntes Objekt, keine genannte Konsequenz, kein Weg zurück.
Dieselbe Aktion, drei Designsprachen — und der eine Standard, der sie ablöste.
Das skaliert nicht. Jedes neue Tool begann bei null — und die Menschen lernten dieselbe Aktion immer wieder neu, Tool für Tool.
Akt II — Entdeckung
Ich suchte nicht nach Komponenten. Ich suchte nach wiederkehrenden Entscheidungen.
Also hörte ich auf, die Oberflächen anzusehen, und begann, sie auseinanderzunehmen. Unter jedem Bestätigungsdialog lag — ganz gleich, wie er aussah — dieselbe kurze Liste von Entscheidungen: was benannt wird, wovor gewarnt wird, welches Verb auf welchen Button gehört, was bei Escape passiert. Die Dialekte unterschieden sich. Die Entscheidungen nicht.
Wiederkehrende Entscheidungen, verstreut über die CERN-Tools — gebündelt zu den Standards, die aus ihnen wurden. Zwei Familien von vielen; die 41 stimmt.
Akt III — Die Erkenntnis
Es ging nie um Buttons. Es ging um Entscheidungen, die zu oft getroffen wurden.
Mir wurde klar: Nicht Konsistenz war das Ziel, sondern weniger wiederholtes Entscheiden.
Wechseln Sie oben in der Demo auf den Reiter Der Standard: Aus drei Antworten wird eine. Ein Designsystem hält diese Entscheidung einmal fest — und merkt sie sich für jedes Team, das danach kommt.
Die Community of Practice
Das war es, was ich wirklich baute: eine Gemeinschaft, die offen lernt.
Standards halten nicht, weil sie aufgeschrieben sind. Sie halten, weil Menschen ihnen vertrauen — und Vertrauen entsteht nur dort, wo offen entschieden wird. Deshalb führte ich das System als Community of Practice: eine feste Gruppe, in der Designer und Entwickler aus jedem Team gemeinsam entscheiden, gemeinsam Entwürfe kritisch prüfen und ein gemeinsames Urteilsvermögen entwickeln, statt es sich allein immer wieder neu zu erarbeiten — von oben als Strategie vorgegeben, von unten getragen: von denen, die sich daran binden.
Jede Entscheidung fällt dort, wo alle sie sehen.
Offene Kritik an Entwürfen und offengelegte Begründungen sorgen dafür, dass das Warum bei der Antwort bleibt — statt in den Köpfen eines einzelnen Teams zu verschwinden.
Jeder kann ein Muster vorschlagen.
Das System wächst aus den Teams, die es nutzen. Echte Probleme kommen von der Basis — und werden einmal gelöst, für alle.
Wer neu dazukommt, steigt in ein laufendes Gespräch ein.
Man versteht das Warum hinter jeder Regel, nicht nur die Regel — so wird das Urteil der Gruppe mit jeder Entscheidung schärfer.
Akt IV — Die Infrastruktur bauen
Erst jetzt zählen Tokens, Komponenten und Muster — als Umsetzung der Erkenntnis.
Drei Ebenen, die aufeinander aufbauen — umgesetzt mit dem Tooling, das in BC ohnehin genutzt wird. So fügte sich alles in bestehende Abläufe ein, statt eine weitere Ebene zu schaffen, die gepflegt werden muss.
Sechs gemeinsame Entscheidungen — einmal zwischen Design und Code vereinbart.
Grundlagen, Komponente, Muster — dieselben Entscheidungen, aufeinander aufbauend.
Ergebnisse
Von isolierten Entscheidungen zu gemeinsamem Gedächtnis.
Ein neues Tool beginnt heute mit 41 gelösten Problemen statt bei null. Binnen eines Jahres kam die Community ohne mich aus — und heute ist das Designsystem Teil von CERNs offiziellem Tech-Stack.
Und weil das System als MCP-Server ausgeliefert wird, sind seine jüngsten Nutzer keine Menschen: Jeder KI-Assistent im BC-Stack erbt dieselben 41 Entscheidungen wie die Teams. Standards, die den Wandel zu agentischer Entwicklung überstehen, waren hier kein nachträglicher Einfall — sie waren von Anfang an der Plan.
Rückblick
Früher dachte ich, Designsysteme seien Sammlungen wiederverwendbarer UI-Bausteine.
Designsysteme sind keine Sammlungen von Komponenten. Sie sind Organisationen, die entscheiden, welche Probleme es verdienen, nur einmal gelöst zu werden.
Lösen Ihre Teams immer wieder dieselben Probleme?
Ich führe ein zwei- bis dreiwöchiges Kohärenz-Audit durch: Wir machen die Entscheidungen sichtbar, die Ihre Teams immer wieder neu treffen, und legen gemeinsam fest, welche davon nur einmal gelöst werden sollten — Sie behalten die Standards samt dem Betriebsmodell, das sie ohne mich am Leben hält. Greifbar, solange Änderungen noch günstig sind.