Design-Systeme: Warum die meisten scheitern und wie man eines baut, das funktioniert

Jedes Team, das eine bestimmte Größe erreicht, sagt irgendwann dasselbe: „Wir brauchen ein Design-System.“ Dann verbringen die meisten sechs Monate damit, eines zu entwickeln, das niemand nutzt, und ein Jahr später sind sie wieder bei der gleichen Inkonsistenz angelangt, mit der sie begonnen haben.

Das Problem sind nie die Komponenten. Das Problem ist, ein Design-System wie ein Projekt statt wie ein Produkt zu behandeln. Projekte enden. Produkte entwickeln sich weiter. Ein Design-System, das sich nicht weiterentwickelt, beginnt am Tag seiner Einführung zu sterben.

Was ein Design-System wirklich ist

Ein Design-System ist keine Komponentenbibliothek. Eine Komponentenbibliothek ist ein Ordner mit wiederverwendbaren UI-Elementen. Ein Design-System ist die vollständige Sammlung von Standards, Dokumentationen und Tools, die festlegen, wie ein Produkt entworfen und gebaut wird.

Es umfasst:

• Design-Tokens. Die atomaren Werte (Farben, Abstände, Typografie, Schatten), auf die sich alles andere bezieht.
• Komponenten. Wiederverwendbare UI-Elemente, die aus Tokens erstellt werden.
• Muster. Dokumentierte Lösungen für wiederkehrende Designprobleme (Formulare, Navigation, Fehlerzustände).
• Richtlinien. Die Regeln, wann und wie jedes Element zu verwenden ist.
• Governance. Wer das System besitzt, wie Änderungen vorgeschlagen werden und wie Entscheidungen getroffen werden.

Entfernen Sie eines dieser Elemente, und Sie haben ein Teilsystem. Teilsysteme führen zu teilweiser Akzeptanz. Teilweise Akzeptanz führt zu der gleichen Inkonsistenz, die Sie zu lösen versuchten.

Warum die meisten Design-Systeme scheitern

Fehler 1: Isoliert aufgebaut. Ein kleines Team verschwindet für drei Monate, baut ein schönes System und präsentiert es einer Organisation, die keinen Input hatte. Das System spiegelt die Annahmen der Ersteller wider, nicht die Realität der Benutzer. Die Akzeptanz ist anfangs höflich, wird dann aber stillschweigend aufgegeben.

Fehler 2: Zu früh zu starr. Das System wird mit strengen Regeln für jedes Szenario eingeführt. Designer und Ingenieure, die auf einen Fall stoßen, den das System nicht vorhergesehen hat, haben zwei Möglichkeiten: das System bekämpfen oder umgehen. Die meisten wählen die Umgehungslösung. Das System wird zu einer Referenz, die niemand referenziert.

Fehler 3: Keine dedizierte Verantwortlichkeit. Das System wurde während eines Sprints aufgebaut. Niemand ist für die Wartung zuständig. Tokens weichen vom Code ab. Komponenten bleiben hinter dem Produkt zurück. Die Dokumentation veraltet. Sechs Monate später ist das System eine Momentaufnahme dessen, wie das Produkt letztes Jahr aussah.

Fehler 4: Komponenten-zentriertes Denken. Das Team baut 47 Komponenten, bevor es einen einzigen Token definiert oder eine einzige Richtlinie schreibt. Die Komponenten funktionieren in der Figma-Datei, brechen aber in der Produktion, weil die zugrunde liegenden Werte nie systematisiert wurden.

Fehler 5: Perfektionslähmung. Das Team versucht, jeden Grenzfall zu lösen, bevor es etwas veröffentlicht. Das System wird nie ausgeliefert. Währenddessen wird das Produkt täglich ohne es ausgeliefert.

Was überlebende Systeme gemeinsam haben

Nach der Untersuchung der Systeme, die tatsächlich Bestand haben (Shopify Polaris, Atlassian Design System, IBM Carbon, GitHub Primer), zeigen sich drei Muster:

Sie begannen klein und wuchsen. Keines von ihnen wurde mit 200 Komponenten eingeführt. Sie wurden mit Tokens, einer Handvoll Kernkomponenten und einer klaren Dokumentation eingeführt. Dann expandierten sie basierend auf tatsächlichen Produktbedürfnissen, nicht auf theoretischer Vollständigkeit.

Sie haben dedizierte Teams. Nicht eine Person. Ein Team. Design-Systeme in großem Maßstab erfordern mindestens einen Designer, einen Ingenieur, einen Dokumentationsautor und einen Produktverantwortlichen. Shopify hat Dutzende von Mitarbeitern, die an Polaris arbeiten. Sie brauchen keine Dutzende, aber Sie brauchen mehr als null.

Sie behandeln Beiträge als Feature. Die besten Systeme erleichtern es Produktteams, Ergänzungen vorzuschlagen, Probleme zu melden und Komponenten beizusteuern. Das System wächst von den Rändern, nicht nur vom Zentrum aus. Ein System, das nur durch die Entscheidungen eines Teams wächst, wird immer hinter dem Produkt zurückbleiben.

Design-Tokens sind die wahre Grundlage

Tokens sind die primitiven Werte, von denen alles andere erbt. Ändern Sie einen Token, und jede Komponente, die ihn referenziert, wird automatisch aktualisiert. Das ist es, was ein System zu einem System macht und nicht zu einer Sammlung.

Token-Ebenen:

| Ebene | Beispiel | Zweck | |---| | Global | color-blue-500: #3B82F6 | Rohe Palettenwerte | | Semantisch | color-primary: {color-blue-500} | Bedeutungsbasierte Aliase | | Komponente | button-bg: {color-primary} | Komponentenspezifische Bindungen |

Globale Tokens definieren die Rohwerte. Semantische Tokens weisen Bedeutungen zu (primär, Gefahr, Oberfläche). Komponenten-Tokens binden diese Bedeutungen an spezifische UI-Elemente. Diese dreischichtige Struktur bedeutet, dass Sie ein Rebranding durchführen können, indem Sie semantische Tokens ändern, ohne eine einzige Komponente zu berühren.

Zuerst zu definierende Token-Typen:

• Farben (Hintergrund, Text, Rahmen, interaktive Zustände)
• Abstände (4px-Raster: 4, 8, 12, 16, 24, 32, 48, 64)
• Typografie (Schriftfamilie, Schriftgrößenskala, Schriftstärke, Zeilenhöhe)
• Border-Radius (keiner, klein, mittel, groß, voll)
• Schatten (Ebenen der Erhebung)
• Bewegung (Dauer, Easing-Kurven)

Wenn Sie nichts anderes definieren, definieren Sie diese. Sie decken 90 % der visuellen Entscheidungen ab, die Ihr Team täglich trifft.

Komponenten bauen, die Bestand haben

Komponenten, die auf Tokens basieren, sind von Natur aus widerstandsfähiger als Komponenten, die auf fest codierten Werten basieren. Aber selbst Token-basierte Komponenten scheitern, wenn sie falsch aufgebaut sind.

Regeln für Komponenten, die überleben:

Komposition statt Konfiguration. Ein Button mit 14 Props ist nicht flexibel. Er ist zerbrechlich. Anstatt eine Mega-Komponente zu bauen, die jede Variante über Props handhabt, bauen Sie kleine, zusammensetzbare Teile, die sich zu Mustern kombinieren lassen. Eine Karte ist keine einzelne Komponente. Sie ist ein Karten-Container, ein Karten-Header, ein Karten-Body und ein Karten-Footer, die sich zusammensetzen.

Zustände sind nicht optional. Jede interaktive Komponente benötigt: Standard-, Hover-, Aktiv-, Fokus-, Deaktiviert-, Lade- und Fehlerzustände. Eine Komponente ohne alle sieben Zustände auszuliefern bedeutet, dass jemand diese Zustände ad hoc erstellen wird, und sie werden nicht übereinstimmen.

Dokumentieren Sie das „Wann“, nicht nur das „Was“. Ihre Button-Dokumentation sollte nicht nur zeigen, wie er aussieht. Sie sollte angeben, wann ein primärer Button gegenüber einem sekundären Button oder einem Ghost-Button zu verwenden ist. Der Entscheidungsrahmen ist wichtiger als die visuelle Referenz.

Muster lösen, was Komponenten nicht können

Eine Dropdown-Komponente sagt Ihnen, wie ein Dropdown aussieht. Sie sagt Ihnen nicht, wann Sie ein Dropdown gegenüber einer Radiogruppe oder einem Segmented Control verwenden sollen. Diese Entscheidung ist ein Muster.

Frühzeitig zu dokumentierende Muster:

• Formular-Layouts. Platzierung von Labels, Fehleranzeige, Kennzeichnung von Pflichtfeldern, mehrstufige Abläufe.
• Navigation. Wann Tabs gegenüber einer Seitenleiste oder Breadcrumbs zu verwenden sind. Verhalten des Zusammenklappens der mobilen Navigation.
• Leere Zustände. Was angezeigt wird, wenn keine Daten vorhanden sind. Illustration? CTA? Bildungsinhalte?
• Ladezustände. Skeleton-Screens versus Spinner versus progressives Laden. Wann jedes davon angemessen ist.
• Fehlerbehandlung. Inline-Validierung versus Toast-Benachrichtigungen versus Fehlerzustände auf ganzer Seite.

Diese Muster verhindern das Problem „Wir haben dasselbe Formular auf fünf verschiedene Arten gebaut“, das Teams ohne System plagt.

Governance entscheidet über Erfolg oder Misserfolg der Akzeptanz

Ein Design-System ohne Governance ist ein Vorschlag. Governance beantwortet drei Fragen:

1. Wer entscheidet? Gibt es ein Prüfungsgremium? Einen einzelnen Eigentümer? Eine demokratische Abstimmung? Was auch immer Sie wählen, machen Sie es explizit.
2. Wie erfolgen Änderungen? RFC-Prozess? GitHub-Issue? Slack-Thread? Definieren Sie den Weg von „Ich glaube, wir brauchen eine neue Komponente“ zu „Sie ist im System.“
3. Was ist die Versionierungsstrategie? Semantische Versionierung für das Token-Paket? Changelog pro Release? Richtlinie für Breaking Changes?

Teams, die auf Governance verzichten, enden mit einem System, das sich verzweigt. Design verwendet Version 2.3. Engineering verwendet Version 1.8. Die Marketing-Website verwendet Version 2.0 mit lokalen Überschreibungen. An diesem Punkt haben Sie drei Design-Systeme und null Konsistenz.

FAQ

Wie lange dauert es, ein Design-System aufzubauen?

Die anfängliche Grundlage (Tokens, 10-15 Kernkomponenten, grundlegende Dokumentation) dauert mit einem dedizierten Team 2-4 Monate. Aber ein Design-System ist niemals „fertig“. Planen Sie eine kontinuierliche Investition von 15-25 % der Kapazität eines Design-Engineering-Teams ein.

Brauchen kleine Teams ein Design-System?

Ja, aber ein proportionales. Ein 3-Personen-Team braucht kein Polaris. Sie brauchen eine gemeinsame Figma-Bibliothek mit Tokens, 8-10 Kernkomponenten und einen einseitigen Entscheidungsleitfaden. Beginnen Sie mit dem, was am meisten schmerzt (normalerweise inkonsistente Abstände und Farbverwendung) und entwickeln Sie sich von dort aus weiter.

Was ist der Unterschied zwischen einem Design-System und einer Komponentenbibliothek?

Eine Komponentenbibliothek ist eine Sammlung wiederverwendbarer UI-Elemente. Ein Design-System umfasst die Komponentenbibliothek plus Design-Tokens, Nutzungsrichtlinien, Muster, Dokumentation und Governance. Die Bibliothek ist eine Ebene des Systems.

Beginnen Sie mit dem Schmerz, nicht mit der Ambition

Bauen Sie kein Design-System, weil es professionell klingt. Bauen Sie eines, weil Ihr Team Zeit damit verschwendet, immer wieder dieselben Probleme zu lösen. Beginnen Sie mit den drei Dingen, die derzeit die größte Inkonsistenz verursachen. Systematisieren Sie diese. Liefern Sie sie aus. Erweitern Sie dann basierend auf dem, was das Team als Nächstes anfordert, nicht auf dem, was in einer Fallstudie beeindruckend aussieht.