Zusammenfassungen von Designsystemen sind meist nach Unternehmen organisiert, was die wenig hilfreichste Achse ist – man weiß bereits, wer Airbnb ist, aber diese Tatsache sagt nichts darüber aus, ob deren System hilfreich ist. Hier ist derselbe Satz an Systemen, organisiert nach den Fragen, die beantwortet werden sollen.

Im Folgenden werden die einzelnen Systeme durchgegangen, inklusive der verfügbaren Ressourcen und dessen, was es wert ist, übernommen zu werden.

Betrachtet man Carbon, Polaris und Lightning gemeinsam, ergibt sich ein Aspekt, der bei keinem der Systeme einzeln diskutiert wird. Alle drei wurden kürzlich restrukturiert – auf unterschiedliche Weise, aber auf derselben Prämisse: Der Code, der ein Designsystem konsumiert, wird zunehmend nicht mehr von einem Menschen geschrieben, der die Dokumentation liest.

Salesforce ist hier am explizitesten und beschreibt SLDS 2 als Grundlage für sein agentisches Designsystem und verweist auf dynamisch generierte User Experiences. IBMs angegebener Grund für den MCP-Server ist ein präziserer generierter Code. Shopifys Ansatz zielt darauf ab, dass Apps innerhalb des Admins nativ aussehen, aber der Effekt ist derselbe: Komponenten, die identisch gerendert werden, unabhängig davon, was sie zusammengesetzt hat.

Niemand hat dies koordiniert. Drei Unternehmen mit unterschiedlichen Produkten, unterschiedlichen Einschränkungen und ohne Grund für eine Abstimmung sind im selben Zeitraum zu kompatiblen Schlussfolgerungen gelangt – was meist ein Zeichen dafür ist, dass die zugrunde liegende Änderung real und nicht nur ein Trend ist.

Open Source, finanziert und entwickelt von IBM, basierend auf der IBM Design Language als separate Brand-Foundation-Schicht, mit Domain-Systemen (IBM Products, Cloud, IBM.com) über dem Kern. React, Web Components und Elements werden vom Carbon-Team gepflegt; Angular, Vue und Svelte werden von der Community gewartet, was in der Dokumentation offen kommuniziert wird – eine ehrliche Offenlegung, die die meisten Systeme auslassen.

Übernehmen: die Trennung in drei Schichten und die Praxis, offenzulegen, wer die jeweilige Implementierung wartet. Ignorieren: die vollständige Übernahme, falls eine visuelle Differenzierung für Ihr Produkt wichtig ist, da die Dichte und die Interaktionsmuster die Identität von IBM beibehalten, selbst wenn die Farben neu definiert werden. Vollständiger Artikel.

Foundations, Tokens, Komponenten und über 400 commerce-fokussierte Icons. Die React-Bibliothek ist nun als veraltet markiert; Web Components werden von einem Shopify-CDN geladen und automatisch durch das Shopify CLI hinzugefügt.

Übernehmen: das Commerce-Icon-Set, falls Sie in diesem Bereich entwickeln, den Ansatz zur Benennung der Tokens und die Begründung des Bereitstellungsmodells. Ignorieren: die Komponenten außerhalb einer Shopify-App – sie lassen Ihr Produkt wie Shopify aussehen. Vollständiger Artikel.

SLDS 1 startete 2015 als CSS-Framework mit fest integriertem Erscheinungsbild. SLDS 2 wurde um CSS Custom Properties herum neu aufgebaut, ergänzt um eine Figma-Bibliothek, deren Token-Namen exakt mit dem Code übereinstimmen, sowie Linting-Tools, die das Markup gegen die Regeln validieren.

Übernehmen: die Namensidentität zwischen Figma und Code sowie den Linter als Durchsetzungsmechanismus. Beides ist kopierbar, ohne eine einzige Zeile Salesforce-CSS zu übernehmen. Ignorieren: das Framework selbst, es sei denn, Sie entwickeln auf der Lightning Platform. Vollständiger Artikel.

Das stärkste Beispiel für ein System, das um eine Einschränkung herum gebaut wurde, die sonst niemand so ernst nimmt: Es muss für jeden funktionieren, einschließlich Menschen mit alten Geräten, schlechten Verbindungen, Screenreadern und unter Stress. Komponenten werden mit veröffentlichten Forschungsergebnissen geliefert, die belegen, wie sie getestet wurden und warum sie so aussehen, wie sie aussehen.

Übernehmen: die Praxis, die Belege hinter jeder Komponente zu veröffentlichen. Fast niemand tut dies, und es ist der Unterschied zwischen einem System, dem man folgt, und einem, über das man streitet. Ignorieren: die Ästhetik, die bewusst institutionell ist.

Langjährig etabliert, gründlich dokumentiert und ungewöhnlich stark bei Content- und Voice-Guidelines statt nur bei visuellen Spezifikationen – der Teil eines Designsystems, den die meisten Teams nie schreiben.

Übernehmen: die Schreib- und Content-Standards. Wenn Ihr System keinen Abschnitt darüber hat, wie Dinge formuliert werden, ist dies das Vorbild. Ignorieren: nichts Besonderes; es ist eine vernünftige allgemeine Referenz.

Diese Kategorie verwirrt oft, daher ist es wichtig, dies klar zu sagen: Einige der am häufigsten zitierten Designsysteme können nicht heruntergeladen werden. Was existiert, sind die veröffentlichten Texte der Teams darüber, welche oft nützlicher sind, als der Code es gewesen wäre.

In dieser Tabelle gibt es ein Muster, das beachtet werden sollte: Die Systeme mit den stärksten visuellen Identitäten veröffentlichen am wenigsten. Das ist kein Zufall und kein Wettbewerbsgeheimnis. Ein System, das existiert, damit sich ein Produkt wie es selbst anfühlt, gewinnt nichts davon, installierbar zu sein. Ein System hingegen, das für die Nutzung durch Tausende von Teams konzipiert ist, muss neutral genug sein, um dies zu überstehen. Neutralität und Identität stehen in einem Trade-off.

Die oben genannten Systeme sind diejenigen, die man genau studieren sollte. Die folgenden sind es wert, bekannt zu sein – jeweils mit dem einen Punkt, in dem sie tatsächlich gut sind.

Beide sind aus einem Grund wichtig, der leicht übersehen wird: Sie setzen die Konventionen, die Ihre Nutzer bereits gelernt haben. Selbst wenn man nichts damit baut, definieren sie, was „der Zurück-Button verhält sich normal“ bedeutet. Airbnbs DLS zog die Grenze der Plattform-Divergenz genau dort, wo diese beiden die Hoheit haben.

Cloudscape ist der unterschätzte Favorit. Die meisten veröffentlichten Systeme sind für Marketing und allgemeine Application-UIs optimiert; nur sehr wenige nehmen dichte operative Interfaces ernst, und diejenigen, die es tun, veröffentlichen sie selten. Wenn Sie Admin- oder Console-Software entwickeln, liegt es näher an Ihrer Problemstellung als Material oder Polaris.

Diese Zeile verdient besondere Beachtung, da sie den Ist-Zustand der meisten Teams beschreibt. Die Kombination aus Radix, shadcn und Tailwind bietet exzellentes barrierefreies Verhalten, eine Token-Ebene und eine Distributionsstrategie – jedoch keine Entscheidungen zu Dichte, Komposition, Motiven oder Verboten. Diese Kombination erzeugt die konsistenten, kompetenten und vollständig austauschbaren Interfaces, die oft als „KI-generiert“ beschrieben werden. Die vollständige Unterscheidung.

Es gibt mehrere große Kataloge, die öffentliche Designsysteme indexieren. Sie beantworten eine spezifische Frage gut: Hat jemand in meiner Branche dieses Problem gelöst und wie wurde es benannt? Eine Komponenten-Galerie ist tatsächlich nützlich, um elf verschiedene Ansätze für einen Date-Picker nebeneinander zu sehen, bevor man einen zwölften entwirft.

Was sie nicht tun, ist aufzuzeigen, welches System es wert ist, studiert zu werden. Ein Verzeichniseintrag besteht aus einem Link und einem Screenshot; die Herleitung findet sich in den Texten des Teams, nicht im Katalog. Nutzen Sie Kataloge für die Breite und gehen Sie zur Quelle für die Tiefe.

Jedes obige Beispiel ist Dokumentation zum Lesen. Das ist die systemimmanente Einschränkung dieses Formats: Ein Designsystem lässt sich erst beurteilen, wenn dieselben Entscheidungen über Screens hinweg konsistent umgesetzt werden, die nichts miteinander zu tun haben. Eine Landingpage beweist, dass ein System einmal gut aussehen kann. Eine Landingpage, ein Dashboard und ein Komponentenblatt, die aus demselben Token-Set erstellt wurden, beweisen, dass es Bestand hat.

Dies sind live gerenderte, vollständige Systeme, keine Screenshots. Jedes zeigt ein Token-Set, das auf drei nicht zusammenhängenden Oberflächen angewendet wird. Es geht also nicht darum, ob Ihnen die Farben gefallen, sondern ob die *gleichen* Entscheidungen sowohl in einem Marketing-Hero als auch in einer komplexen Tabelle überleben.

Die wertvollste Version dieser Übung ist eine, die niemand veröffentlicht hat – an einem Produkt aus Ihrem eigenen Sektor. Zeitaufwand: etwa eine Stunde.

1. 1

   Drei Screens erfassen, nicht nur einen

   Ein Screen zeigt die Palette. Drei Screens zeigen, welche Entscheidungen sich wiederholen – und Wiederholung ist das, was ein System von einer einzelnen Seite unterscheidet.

2. 2

   Computed Values auslesen, nicht schätzen

   Öffnen Sie die Entwicklertools und notieren Sie font-weight, letter-spacing, border-width, border-radius und padding. „Enger Zeichenabstand“ ist ein subjektiver Eindruck; -0.022em bei 48px ist eine Regel.

3. 3

   Nach dem Bereich suchen, nicht nach dem Einzelwert

   Das Ergebnis ist selten eine einzelne Zahl. Es ist die Erkenntnis, dass jedes Gewicht zwischen 400 und 510 liegt oder dass der Radius immer nur 6 oder 12 beträgt. Bereiche sind Regeln; Einzelwerte sind Stichproben.

4. 4

   Notieren, was fehlt

   Keine Schatten. Keine Gradienten. Kein zweiter Akzent. Kein Gewicht über 510. Abwesenheiten sind das wertvollste Ergebnis eines Teardowns und das Erste, was bei einer automatisierten Extraktion verloren geht.

5. 5

   Jede Beobachtung in eine Anweisung umwandeln

   „Elevation ist eine Oberflächenstufe plus ein 1px-Rahmen, niemals ein box-shadow“ ist ausführbar. „Minimal und präzise“ ist es nicht. In diesem Schritt wird aus einem Teardown ein Designsystem.

Schritt vier ist der entscheidende. Wir haben 299 DESIGN.md-Dateien analysiert, die KI-Agenten Design-Richtlinien geben sollten, und festgestellt, dass 76 % keinerlei Verbote enthalten, während 86 % Farben als reine Hex-Werte ohne semantische Rolle angeben und 57 % keine markanten Motive definieren. Diese Dateien beschreiben eine Palette. Die Identität, die sie einfangen wollten, lag in den Abwesenheiten.

Es gibt eine Art, Designsysteme zu studieren, die ein schlechteres Ergebnis liefert, als bei Null anzufangen. Das passiert, wenn die Übung rein akquisitiv wird: Wer die besten Teile aus neun Systemen zusammenstellt, erhält ein kompetentes Interface ohne konzeptionelle Grundlage.

Jedes der oben genannten Systeme resultiert aus einer Entscheidung über die Zielgruppe. Die Informationsdichte von Linear ist das Argument, dass Power-User, die ein Tool den ganzen Tag nutzen, Ruhe und Informationen benötigen. Die Schlichtheit von GOV.UK ist das Argument, dass die Lesenden gestresst sein könnten, eine schlechte Verbindung haben und man nicht davon ausgehen kann, dass sie über bestimmte Voraussetzungen verfügen. Die Neutralität von Carbon ist das Argument, dass Tausende von Teams das System übernehmen werden und keines davon das Brand-Team von IBM ist.

Nutzen Sie diese Beispiele, um den Grad der Strenge zu kalibrieren – wie spezifisch die Zahlen sind, wie viele Dinge untersagt werden und wie eng die Bereiche gefasst sind. Leiten Sie dann Ihre eigenen Argumente basierend auf Ihrer Zielgruppe ab und lassen Sie die Regeln daraus folgen.