🪦 Design System-Friedhof Schweiz: Warum Millionen in gescheiterten Komponenten-Bibliotheken vergraben liegen

Stellen Sie sich vor: Ein Schweizer Versicherungskonzern investiert über drei Jahre hinweg mehrere Millionen Franken in eine firmeninterne Komponenten-Bibliothek. Ein spezielles Team wird gegründet, externe Berater engagiert, moderne Tools eingekauft. Das Versprechen: Konsistente User Interfaces, schnellere Entwicklung, geringere Wartungskosten. Das Ergebnis nach drei Jahren: Das Projekt wird stillschweigend eingestellt, das Team aufgelöst, die Komponenten landen im Git-Archiv. Ein Einzelfall? Keineswegs.
Nur wenige Kilometer entfernt investiert eine Grossbank Millionen in ihre Design System-Initiative. Die Komponenten sind technisch ausgereift, die Dokumentation vorbildlich – doch der interne Approval-Prozess für neue Features dauert Monate. Frustrierte Entwicklungsteams umgehen das System, bauen parallel eigene Lösungen. Am Ende existieren fünf verschiedene Button-Varianten, drei inkompatible Farbschemata und null Wiederverwendung. Auch hier: Millionen versenkt, Ziel verfehlt.

Willkommen auf dem Design System-Friedhof der Schweiz – einem Ort, wo gut gemeinte Millionen-Investitionen in gescheiterten Komponenten-Bibliotheken ruhen. Die Grabsteine tragen Namen wie "Enterprise UI Framework", "Corporate Design System" oder "Unified Component Library". Doch was steht wirklich hinter diesem systematischen Scheitern? Und vor allem: Wie lässt es sich verhindern?

Die vier Todesursachen: Archetypen des Scheiterns

Als Freelance Software Engineer hatte ich in den letzten zehn Jahren die Möglichkeit, hinter die Kulissen grosser Schweizer und deutscher Unternehmen zu blicken – von Versicherungskonzernen über Banken bis hin zu Technologie-Unternehmen. Dabei habe ich sowohl spektakuläre Erfolge als auch kostspielige Misserfolge bei Design System-Initiativen miterlebt. Aus diesen Erfahrungen lassen sich vier charakteristische Archetypen des Scheiterns ableiten – doch ebenso wichtig sind die Erkenntnisse darüber, unter welchen Umständen Design Systeme tatsächlich gedeihen und zum strategischen Vorteil werden. Die folgenden Pattern sind keine Schwarzmalerei, sondern eine ehrliche Analyse dessen, was funktioniert und was nicht – damit Sie die Fallen vermeiden und von den Erfolgsrezepten profitieren können.

☠️ Tod durch Service-Erstickung: Das "Komponenten-Service-Team" Antipattern

"Wir gründen ein zentrales Team, das alle UI-Komponenten für das gesamte Unternehmen entwickelt!" – Mit diesen hoffnungsvollen Worten startete ein börsennotiertes Unternehmen seine Design System-Initiative. Die Idee klang bestechend logisch: Fünf interne Entwickler plus zwei externe Berater sollten eine unternehmensweite Komponenten-Bibliothek aufbauen. Alle anderen Teams müssten nur noch Tickets öffnen: "Wir brauchen einen Select mit Type-Ahead für die Kundensuche", "Können wir ein Modal haben mit konfigurierbaren Action-Icons im Footer?", "Wo ist unser Datepicker mit explizit zugelassenen Kalendertagen für die Terminbuchung?"

Die Anfangseuphorie
Die ersten Monate liefen vielversprechend. Das "UI-Komponenten-Team" baute grundlegende Elemente: Buttons, Inputs, Cards. Die Qualität stimmte, die Dokumentation war vorbildlich, das Storybook beeindruckend. Andere Entwicklungsteams waren begeistert – endlich professionelle UI-Komponenten, ohne selbst CSS anfassen zu müssen.

Der schleichende Missbrauch
Doch dann kam der erste "besondere" Request: "Könntet ihr den Button auch mit Tooltip machen? Und mit Animation beim Hover? Ach, und dieser eine Button braucht ein Icon, aber nur manchmal..." Aus einfachen Komponenten-Requests wurden komplexe Feature-Anfragen. Das UI-Team mutierte vom Design System-Entwickler zum Custom-UI-Dienstleister.

Das Ticket-System, ursprünglich für "Standard-Komponenten" gedacht, füllte sich mit Anfragen wie: "Modal mit drei verschiedenen Footer-Layouts", "Tabelle mit 15 konfigurierbaren Spalten-Typen", "Accordion das auch als Tabs funktioniert". Jeder Request schien logisch – schliesslich sollte ja "alles wiederverwendbar" sein.

Das Budget-Chaos
Und dann kam die Kostenfrage: Wer zahlt für all diese Custom-Features? Team A braucht den komplexen Datepicker, Team B soll die Entwicklungskosten mit übernehmen? Das Projektmanagement versank in endlosen Diskussionen über interne Kostenumlage. Manche Teams warteten monatelang auf ihr angefragtes Feature, weil das Budget nicht geklärt war.

Gleichzeitig rechnete das UI-Team interne Stunden ab wie eine externe Agentur. Ein simpler Button kostete plötzlich 2.000 CHF "Entwicklungsaufwand" – inklusive Design Review, Testing, Documentation und Storybook-Integration. Für manche Teamleiter war es günstiger, das Feature schnell selbst zu bauen.

Der Todesstoss: Feature-Request-Flut
Nach 18 Monaten ertrank das UI-Team in einem Meer aus widersprüchlichen Anforderungen. 47 offene Tickets, 12 "urgent" Requests, 3 verschiedene Button-Varianten in der Pipeline. Die ursprüngliche Vision eines konsistenten Design Systems war zur Custom-Development-Hölle mutiert.

Die Ironie: Während das zentrale Team an "Enterprise-Accordion-Komponente Version 3.2" arbeitete, bauten andere Teams längst eigene, simple Lösungen. Am Ende existierten mehr UI-Varianten als vor dem Design System – nur mit 3x höheren Kosten.

Das unvermeidliche Ende
Nach drei Jahren und mehreren Millionen Franken wurde das Projekt stillschweigend eingestellt. Die Begründung: "Veränderte strategische Prioritäten." Die Realität: Ein gut gemeintes Design System war zur kostspieligen Service-Hölle geworden, die niemand mehr nutzen wollte.

Das UI-Team wurde aufgelöst, die Komponenten-Bibliothek archiviert. Zurück blieb ein teurer Lerneffekt: Design Systeme kann man nicht "servicen" – sie müssen adoptiert werden.

☠️ Tod durch Prozess-Paralyse: Das "Approval-Hell" Pattern

Ein anderes börsennotiertes Unternehmen wählte einen völlig anderen Ansatz: Statt einem internen "Service-Team" wurde die Komponenten-Bibliothek nach Osteuropa ausgelagert. Ein erfahrenes Entwicklungsteam in Polen sollte hochwertige, wiederverwendbare UI-Komponenten entwickeln. Die technische Qualität? Hervorragend. Die Dokumentation? Vorbildlich. Das Problem? Der Weg von der Idee zur Implementierung.

Die perfekte Komponenten-Bibliothek
Nach 18 Monaten Entwicklung war das Ergebnis beeindruckend: 50+ professionell entwickelte React-Komponenten, vollständig getestet, mit TypeScript-Definitionen und detaillierter Storybook-Dokumentation. Jede Komponente war ein kleines Kunstwerk – sauber kodiert, performant, wiederverwendbar.

Die hauseigenen Entwicklungsteams waren zunächst begeistert. Endlich professionelle UI-Komponenten, die ihren Quality Gates standhielten. Buttons mit konsistenten Hover-States, Modals mit Accessibility-Support, Formulare mit eingebauter Validierung.

Der Genehmigungsstau
Doch dann kam die Realität: Um eine neue Komponente in die Bibliothek aufzunehmen oder ein bestehendes Feature zu erweitern, musste ein formeller Request durchlaufen werden. Schritt eins: Technical Requirements Document erstellen. Schritt zwei: Architecture Review Board. Schritt drei: Security Assessment. Schritt vier: Budget-Freigabe für das Outsourcing-Team.

Was bei einem einfachen "Button mit Icon-Support" begann, entwickelte sich zu einem drei-monatigen Approval-Marathon. Das polnische Team wartete auf Spezifikationen, das Architecture Board diskutierte über API-Design, das Security-Team prüfte potenzielle XSS-Vulnerabilities in Icon-Rendering.

Die Kostenfalle
Dazu kam die interne Buchhaltung: Jede Änderung an der Komponenten-Bibliothek wurde als "externe Entwicklungskosten" verrechnet. Ein neuer Prop für eine bestehende Komponente? 800 CHF für Analyse, Implementation und Testing. Ein zusätzlicher Button-Variant? 1'200 CHF inklusive Dokumentation-Update.

Für Team-Manager wurde schnell klar: Ein Feature selbst zu bauen dauert zwei Tage und kostet intern 1'000 CHF. Die "offizielle" Komponente erweitern zu lassen dauert drei Monate und kostet 1'200 CHF externe Rechnung plus interne Koordinationsaufwände.

Der schleichende Exodus
Die Folge war vorhersehbar: Teams begannen, das offizielle Design System zu umgehen. "Wir nehmen den Standard-Button für 80% der Fälle und bauen die Sonderfälle schnell selbst", wurde zur gängigen Praxis. Plötzlich existierten wieder fünf verschiedene Varianten je Komponente – vier inoffizielle und eine "approved".

Die verlorene Schlacht
Die Ironie: Je besser die offizielle Komponenten-Bibliothek wurde, desto weniger wurde sie genutzt. Teams griffen nur noch auf das "bare minimum" zurück und entwickelten alles andere parallel. Das frustrierte sowohl die lokalen Entwickler ("Warum kann ich Komponente X nicht einfach erweitern?") als auch das polnische Team ("Niemand nutzt unsere neuen Features"). Als die ideale vorbildliche Komponente aus Polen letztendlich ankam, war kein Budget mehr da die "temporäre" Eigenlösung durch die professionelle abgenommene Komponente auszutauschen. Die App lief ja bereits und unter Entwicklern weiss man: "Never change a running system".

☠️ Tod durch Quereinsteiger: Das „Wie schwer kann das schon sein?“-Syndrom

In vielen Schweizer Unternehmen übernehmen ausschliesslich Backend-Entwickler die Frontend-Architektur – nach dem Motto „Ein bisschen HTML und CSS kriege ich auch hin“. Frontend-Only-Expertise ist rar, denn es gibt kaum dedizierte Frontend-Hires. Die Folge: Design System-Initiativen werden parallel zum Tagesgeschäft von Quereinsteigern umgesetzt, die ihr Wissen überwiegend aus Blogartikeln und YouTube-Tutorials gezogen haben. (Prämisse: Dieser Blog war nicht dabei)

Das Kernproblem ist das fehlende Verständnis für die Komplexität moderner UI-Engineering-Aufgaben. Komponentenschnittstellen müssen typsicher, gut dokumentiert und performant sein. State-Management, serverseitiges Rendering, Accessibility und Testing sind essenziell – und all das erfordert spezialisierte Kenntnisse und Erfahrungen, die ein Backend-Entwickler ohne einer vorhandenen Affinität zum Frontend kaum in kurzer Zeit erwerben kann.

Ergebnis: Die Initiative verkommt zur „Learning-by-Doing“-Plattform. Anforderungen werden nicht optimal umgesetzt, Architektur-Entscheidungen sind inkonsistent, und die Bibliothek kann weder hohe Qualität noch echte Wiederverwendbarkeit liefern. Design Systeme brauchen Ingenieursdisziplin – kein Freund aus der Nachtschicht, der sich mal eben mit React beschäftigt hat.

☠️ Tod durch Dorfältesten-Blockade: Das "Not-Invented-Here" Syndrom

Bei einem dritten Unternehmen startete die Design System-Initiative mit den besten Absichten: Ein erfahrenes Entwicklungsteam sollte eine moderne, zukunftssichere Komponenten-Bibliothek aufbauen. Das Problem war nicht das Budget oder der Prozess – sondern Stefan.

Der Dorfälteste
Stefan (Name geändert) war seit 19 Jahren im Unternehmen, kannte jeden Legacy-Code persönlich und hatte starke Meinungen über "die richtige Art, Frontend zu entwickeln". Als die Design System-Initiative startete, meldete er sich sofort freiwillig als Technical Lead.

Besonders leidenschaftlich wurde Stefan bei seinem Lieblings-Thema: "Web Components sind die Zukunft! Framework-agnostisch, standardbasiert, zukunftssicher!" Dass Web Components seit 2015 "die Zukunft" waren, aber sich in Enterprise-Umgebungen nie durchgesetzt hatten, störte ihn nicht. Grundsätzlich ein durchaus sinnvoller Ansatz – Web Components haben ihre Berechtigung und werden von Big Tech Unternehmen wie Google erfolgreich eingesetzt. Das Problem: Während andere Teams bereits produktiv mit React arbeiteten, würde ein Web Components-Ansatz das Team in unbekanntes Terrain führen und die Time-to-Market erheblich verlängern.

Die Perfection Paralysis
Stefans Anspruch an Perfektion lähmte das Team. Ein einfacher Button durchlief drei Wochen Design-Diskussionen: "Sollen wir die Grössen fest codieren oder ein mathematisches Scaling-System entwickeln?", "Brauchen wir eine Abstract Factory für Button-Variants?", "Wie stellen wir sicher, dass der Button in 5 Jahren noch maintainable ist?".

Während andere Teams längst mit Material-UI oder TailwindCSS produktiv arbeiteten, grübelte Stefans Team über die "enterprise-ready Button-Architektur der Zukunft". Nach sechs Monaten hatten sie einen technisch brillanten, vollständig konfigurierbaren, Web Component-basierten Button – den niemand verwenden wollte.

Das Not-Invented-Here-Syndrom
Externe Dependencies wurden grundsätzlich kritisch betrachtet. "Material-UI? Was passiert, wenn Google das Projekt in drei Jahren einstellt?" "Ant Design? Zu viele externe Dependencies – haben wir da wirklich Kontrolle drüber?" "TailwindCSS? Eine Modeerscheinung, die heute hip ist und morgen verschwunden. Wer garantiert uns, dass das in zehn Jahren noch weiterentwickelt wird?"

Stefans Hauptargument war die langfristige Kontrolle: "Wir können nicht unsere gesamte UI-Architektur auf externe Bibliotheken aufbauen, über deren Zukunft wir keine Kontrolle haben. Was ist, wenn die Maintainer das Interesse verlieren? Was ist, wenn sich die Roadmap ändert? Wir brauchen Lösungen, die wir selbst in der Hand haben."

Während Stefan vor "unstabilen" Dependencies wie TailwindCSS warnte (das von Millionen von Entwicklern verwendet wird), baute sein Team Custom-Solutions, die von genau einer Person – ihm selbst – maintained wurden. Die Wahrscheinlichkeit, dass Stefan in drei Jahren das Unternehmen verlässt, schien höher als die, dass TailwindCSS eingestellt wird.

Die vier Erfolgsprinzipien: Wie Design Systeme wirklich funktionieren

Diese vier Archetypen des Scheiterns haben eine Gemeinsamkeit: Sie alle hätten vermieden werden können. Aus zehn Jahren Projekterfahrung lassen sich vier fundamentale Erfolgsprinzipien ableiten, die den Unterschied zwischen Millionen-Grab und strategischem Vorteil ausmachen.

🦋 Hierarchie-Unterstützung: Das Management muss mitspielen

Design Systeme scheitern nicht auf der technischen, sondern auf der organisatorischen Ebene. Die Initiative muss ein bis zwei Ebenen höher in der Hierarchie thematisiert und gemeinsam mitgetragen werden.

Der misverstandene Investitionsverlauf
Ein kritischer Erfolgsfaktor ist das Management-Verständnis für die Nicht-Linearität von Design System-Entwicklung. Viele Manager denken linear: "In PI 1 investieren wir X CHF und bekommen Y Komponenten, in PI 2 die gleiche Summe für die gleiche Anzahl." Diese Erwartung führt unweigerlich zu Enttäuschungen.

Die Realität folgt einem Hockey-Stick-Muster: Zu Beginn liegt der Fokus auf dem Schmieden der Baublöcke – Fundamentkomponenten, Designtokens, Build-Pipeline, Testing-Infrastruktur. Man kann noch nicht das Haus bauen, solange die individuellen Baublöcke nicht stehen. Diese Phase wirkt langsam und wenig produktiv für Business-Stakeholder.

Der exponenzielle Wendepunkt
Doch sobald die Blueprints etabliert sind, nimmt die Geschwindigkeit schlagartig zu. Plötzlich geht es nur noch darum, hochwertige Komponenten zu kombinieren – nicht mehr sie zu entwickeln. Neue User Interfaces entstehen in Tagen statt Wochen, Features werden konsistent und wartbar ausgeliefert.

Manager, die diesen feinen aber entscheidenden Unterschied verstehen, sind optimal aufgestellt: Sie investieren geduldig in die Foundation-Phase und ernten exponentiellen Nutzen in der Assembly-Phase. Budget und Abrechnungsdetails müssen entsprechend gestaltet werden – keine negativen Anreize schaffen, sondern den langfristigen Wert fördern.

🦋 Technologie-Konvergenz: Ein Stack für alle (oder strukturiertes Oligopol)

Das Team einigt sich auf einen Tech Stack – beispielsweise React, TailwindCSS, react-hook-form, zod, framer-motion. Bei Grosskonzernen ist durchaus ein Oligopol-Modell vorstellbar: Mehrere Portfolio-Teams bauen gemeinsam eine Komponenten-Bibliothek mit Stack A, während andere Teams mit völlig anderen Anforderungen eine separate Bibliothek mit Stack B entwickeln.

Wenn beide Bibliotheken gut sind, setzen sich beide durch – Teams können je nach Projekt entscheiden. Das Oligopol-Modell hat Vorteile: Es ermöglicht Innovation und den Einsatz neuester Technologien. Für kleinere Unternehmen überwiegen jedoch die Vorteile der Konvergenz: Gemeinsam am Tisch sitzen, an einem Strang ziehen, Budget bündeln.

Was definitiv zu vermeiden ist: Das Polypol – jedes Team macht sein eigenes Ding, jedes Team erfindet das Rad neu.

🦋 Echte Frontend-Expertise: Keine Lernprojekte auf Firmenkosten

Ein kritischer Punkt, der oft unterschätzt wird: Frontend-Entwicklung und Komponenten-Bibliotheken sind echte Engineering-Arbeit – nicht etwas, was ein Java-Entwickler nach ein paar YouTube-Tutorials nebenbei mitmachen kann. Firmeninterne Corporate Libraries als Lernprojekt anzugehen ist ein Rezept für Disaster.

Es braucht Leute, die sich intensiv mit React-Patterns, TypeScript-APIs, CSS-Architekturen und Build-Systemen auskennen. Die verstehen, wann Server-Side Rendering funktioniert und wann nicht. Die wissen, wie man APIs designt, die sowohl für Junior- als auch Senior-Entwickler intuitiv sind.

Der Quereinsteiger-Faktor ist einer der häufigsten Killer für Design System-Projekte – und einer der besten Argumente für externe Expertise.

🦋 Community Ownership: Das Team besitzt den Code

Das Gegenteil von zentralem Service-Team oder externem Outsourcing: Die Teams besitzen kollektiv die Komponenten-Bibliothek. Beispielsweise gibt es in jedem Team einen Vertreter, der in der Frontend-Gilde die Interessen seines Teams vertritt.

Gemeinsam wird ein System ausgearbeitet, wie neue Feature-Requests gemerged werden können: Minor Changes benötigen zwei Approvals aus anderen Teams, Major oder Breaking Changes brauchen fünf Approvals von Senior-Entwicklern. So entstehen Ownership und Verantwortung – ohne Service-Hölle oder Approval-Paralyse.

Fazit: Von Friedhof zu Erfolg: Die Erfolgsfaktoren im Überblick

Design System-Erfolg ist planbar. Die Erfolgsfaktoren sind bekannt und bewährt: Hierarchische Unterstützung, technologische Konvergenz, echte Frontend-Expertise und Community Ownership. Teams, die diese vier Prinzipien konsequent anwenden, bauen erfolgreiche Komponenten-Bibliotheken – ohne Millionen-Gräber und ohne jahrelange Irrwege.

Der Schlüssel liegt in der strategischen Herangehensweise: Hoch genug ansetzen, die richtigen Entscheidungsträger überzeugen, Budget intelligent planen und das Frontend-Engineering ernst nehmen. Mit diesem Fundament wird aus der gefürchteten "Design System-Initiative" ein strategischer Wettbewerbsvorteil.