Beginnen Sie beim Problem, nicht bei der Liste
Designsystem-Zusammenfassungen sind meist nach Unternehmen sortiert, was die am wenigsten nützliche Achse ist: Man weiß bereits, wer Airbnb ist, aber diese Tatsache sagt einem nicht, ob ihr System einem weiterhilft. Hier ist dieselbe Auswahl, sortiert nach dem, was man herausfinden möchte.
| Lesen | Weil | |
|---|---|---|
| „Wo kommen produktspezifische Komponenten hin?“ | Carbon, Encore | Beide haben es mit Layern gelöst: ein Fundament, das nicht überschrieben werden kann, und spezialisierte Subsysteme darüber |
| „Wie sorge ich dafür, dass die Leute es tatsächlich einhalten?“ | Stripe, SLDS 2 | Das eine entzieht die Möglichkeit zur Abweichung; das andere lintet dafür. Dokumentation ist die dritte Option und sie verliert |
| „Wie halte ich vier Plattformen konsistent?“ | Airbnb DLS | Komponenten, die durch Contracts statt durch Komposition definiert sind: das Einzige, was vier Implementierungen überlebt |
| „Wie erlaube ich den Kunden ein tiefgreifendes Theming?“ | SLDS 2, Stripe Elements | Entkopplung von Struktur und visuellem Stil sowie eine Hierarchie von Theme → Variablen → Regeln |
| „Warum sieht mein Produkt generisch aus?“ | Linear | Identität entsteht durch das, was ein System nicht tut – und Verzicht ist das, was die meisten Systeme auslassen |
| „Wie sollte ich es an die Endverbraucher ausliefern?“ | Polaris | Ob Sie oder Ihre Konsumenten die Version kontrollieren, ergibt sich daraus, wer für das Erscheinungsbild verantwortlich ist |
Der Rest dieses Artikels geht jede einzelne durch – mit dem, was verfügbar ist und dem, was es wert ist, übernommen zu werden.
Die drei, die sich in den letzten achtzehn Monaten verändert haben
Die gleichzeitige Betrachtung von Carbon, Polaris und Lightning offenbart etwas, das keines der Systeme einzeln thematisiert. Alle drei wurden kürzlich auf unterschiedliche Weise auf derselben Prämisse umstrukturiert: Der Code, der ein Designsystem konsumiert, wird zunehmend nicht mehr von einem Menschen geschrieben, der die Dokumentation liest.
| Was sich geändert hat | Das Wagnis | |
|---|---|---|
| IBM Carbon | Hat einen MCP-Server bereitgestellt, der Dokumentationen, Komponentencode-Beispiele, Diagramme und experimentelle Komponenten für Agenten bereitstellt | Agenten sollten das System zum Zeitpunkt der Generierung abrufen, anstatt es aus Trainingsdaten zu rekonstruieren |
| Salesforce Lightning | SLDS 2: CSS-Architektur entkoppelt vom Standard-Visual-Style, Styling-Hooks als Custom Properties, ein Linter zur Validierung des Markups | Struktur und Erscheinungsbild müssen getrennt sein, und Verstöße müssen mechanisch abgefangen werden |
| Shopify Polaris | React zugunsten von framework-agnostischen Web Components, die über ein CDN ausgeliefert werden, als veraltet (deprecated) eingestuft | Die Auslieferung darf keine Annahme darüber treffen, welches Framework die Seite generiert hat |
Salesforce ist hier am explizitesten und beschreibt SLDS 2 als Fundament für sein agentic Designsystem und bezieht sich auf dynamisch generierte Nutzererlebnisse. IBM nennt als Grund für den MCP-Server die Erzeugung von Code mit höherer Genauigkeit. Shopify fokussiert sich darauf, dass Apps im Admin-Bereich nativ aussehen, aber der Effekt ist derselbe: Komponenten, die identisch gerendert werden, unabhängig davon, was sie zusammengestellt hat.
Niemand hat dies koordiniert. Drei Unternehmen mit unterschiedlichen Produkten, unterschiedlichen Einschränkungen und ohne Grund zur Einigkeit kamen im selben Zeitraum zu kompatiblen Schlussfolgerungen, was normalerweise das Zeichen dafür ist, dass die zugrunde liegende Änderung real und nicht nur ein Trend ist.
Die offenen, installierbaren Systeme
IBM Carbon
Open Source, finanziert und entwickelt von IBM, aufgebaut auf der IBM Design Language als separate Brand-Foundation-Ebene, mit Domain-Systemen (IBM Products, Cloud, IBM.com) oberhalb des Kerns. React, Web Components und Elements werden vom Carbon-Team gepflegt; Angular, Vue und Svelte werden von der Community gepflegt, und die Dokumentation gibt dies offen zu – eine ehrliche Offenlegung, die die meisten Systeme überspringen.
Übernehmen: die dreistufige Trennung und die Praxis, offenzulegen, wer welche Implementierung pflegt. Überspringen: die vollständige Übernahme, falls visuelle Differenzierung für Ihr Produkt wichtig ist, da die Dichte und die Interaktions-Idiome die Identität von IBM auch dann noch tragen, wenn Sie die Farben umgestaltet haben. Vollständiger Artikel.
Shopify Polaris
Foundations, Tokens, Komponenten und über 400 e-Commerce-fokussierte Icons. Die React-Library ist nun als veraltet (deprecated) gekennzeichnet; Web Components werden von einem Shopify-CDN geladen und automatisch durch das Shopify CLI hinzugefügt.
Übernehmen: das E-Commerce-Icon-Set, falls Sie in diesem Bereich entwickeln, den Ansatz beim Token-Naming und die Logik des Auslieferungsmodells. Überspringen: die Komponenten außerhalb einer Shopify-App. Sie werden Ihr Produkt wie Shopify aussehen lassen. Vollständiger Artikel.
Salesforce Lightning
SLDS 1 wurde 2015 als CSS-Framework mit fest integriertem Erscheinungsbild eingeführt. SLDS 2 wurde um CSS Custom Properties herum neu aufgebaut, ergänzte eine Figma-Library, deren Token-Namen exakt mit dem Code übereinstimmen, und lieferte Linting-Tools aus, die das Markup gegen die Regeln validieren.
Übernehmen: die Namensgleichheit zwischen Figma und Code sowie den Linter als Durchsetzungsmechanismus. Beides lässt sich übernehmen, ohne eine einzige Zeile Salesforce-CSS zu implementieren. Überspringen: das Framework selbst, es sei denn, Sie entwickeln auf der Lightning Platform. Vollständiger Artikel.
GOV.UK Design System
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 dazu geliefert, 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 macht das, und es ist der Unterschied zwischen einem System, dem man folgt, und einem, mit dem man diskutiert. Überspringen: die Ästhetik, die bewusst institutionell gehalten ist.
Atlassian Design System
Langjährig, gründlich dokumentiert und ungewöhnlich stark bei der Content- und Voice-Guidance statt nur bei der visuellen Spezifikation: der Teil eines Designsystems, den die meisten Teams niemals schreiben.
Übernehmen: die Schreib- und Content-Standards. Wenn Ihr System keinen Abschnitt darüber hat, wie Dinge formuliert werden, ist dies das Vorbild. Überspringen: nichts Besonderes; es ist eine vernünftige allgemeine Referenz.
Die dokumentierten, aber privaten Systeme
Diese Kategorie verwirrt die Leute, daher ist es wichtig, es klar zu sagen: Mehrere der am häufigsten zitierten Designsysteme können nicht heruntergeladen werden. Was existiert, sind die veröffentlichten Texte des Teams über sie, die oft nützlicher sind, als es der Code wäre.
| Verfügbar | Die Erkenntnisse, die es wert sind | |
|---|---|---|
| Stripe | Zwei öffentliche Integrationssysteme (Apps UI toolkit, Elements Appearance API); das interne System ist nicht veröffentlicht | Die Ausrichtung folgt der Vertrauensgrenze: ein geschlossenes Vokabular auf der Oberfläche von Stripe, eine Anpassungsleiter auf der des Kunden |
| Airbnb DLS | Veröffentlichte Team-Accounts; kein Paket | Komponenten als in sich geschlossene Einheiten mit erklärten Elementen, unter expliziter Ablehnung atomarer Komposition |
| Spotify Encore | Veröffentlichte Texte des Design-Teams; kein Paket | Konzentrische Ebenen und das öffentliche Eingeständnis, dass die Flexibilität zu weit ging und eine neue Ebene zur Korrektur benötigt wurde |
| Linear | Keine First-Party-Ressourcen; Third-Party-Extraktionen von variierender Zuverlässigkeit | Die Identität wird durch Einschränkung getragen: ein enges Gewichtsspektrum, Hairlines statt Schatten, ein sparsam eingesetzter Akzent |
Vorsicht bei Third-Party-„Extraktionen“ privater Systeme. Ein ausgelesener Style-Report kann zwar sagen, dass eine Oberfläche ein bestimmtes Grau hat. Er kann jedoch nicht sagen, ob dieses Grau ein bewusster Schritt in einer Skala oder ein Zufall auf einer einzelnen Seite ist, und er erfasst niemals die Verbote – und genau das ist der Teil, der die Kopie funktionsfähig gemacht hätte.
In dieser Tabelle gibt es ein Muster, das bemerkenswert ist: 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, hat nichts davon, installierbar zu sein; und ein System, das darauf ausgelegt ist, von Tausenden von Teams übernommen zu werden, muss neutral genug sein, um das zu überstehen. Neutralität und Identität stehen in einem Trade-off.
Der Rest des Feldes, kurz gefasst
Die oben genannten Systeme sind diejenigen, die man genau studieren sollte. Diese hier ist es wert, dass man ihre Existenz kennt, zusammen mit dem einen Punkt, in dem sie tatsächlich gut sind.
Plattform-Systeme
| Lerneffekt | Vorsicht bei | |
|---|---|---|
| Material Design | Die gründlichste öffentliche Aufarbeitung von Motion- und State-Layern überhaupt. Das Modell für Elevation und Interaktionszustände ist lesenswert, selbst wenn man es nie einsetzt | Eine vollständige Übernahme lässt ein Webprodukt wie eine Android-App aussehen. Die Design-Entscheidungen sind stark und für Nutzer klar erkennbar |
| Apple Human Interface Guidelines | Die klarsten Texte darüber, *warum* eine Konvention existiert und nicht nur, was sie ist. Exzellent in Bezug auf Plattform-Idiome und Barrierefreiheit | Es handelt sich um Richtlinien, nicht um eine Komponentenbibliothek. Es gibt nichts zu installieren, und die Anwendung außerhalb der Plattform ist meist nicht übertragbar |
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.
Große Produkt-Systeme
| Empfehlenswert für | |
|---|---|
| GitHub Primer | Ungewöhnlich gute Dokumentation darüber, *wann eine Komponente nicht* verwendet werden sollte, sowie ein ausgereifter Ansatz für den Versand desselben Systems über Rails, React und statische Seiten |
| Microsoft Fluent | Der größte veröffentlichte Versuch eines einheitlichen Systems über Desktop, Web und Mobile mit tatsächlich unterschiedlichen nativen Shells. Vor allem instruktiv darin, wie schwierig dies ist |
| AWS Cloudscape | Das beste öffentliche Beispiel für ein System, das speziell für dichte, datenintensive Console-UIs entwickelt wurde: Tabellen, Filter, Ressourcenlisten. Selten und nützlich, wenn man diese Art von Produkt baut |
| Uber Base Web | Eine starke Theming-Architektur und ein Override-Modell, das es Konsumenten ermöglicht, strukturiert auf die Interna von Komponenten zuzugreifen |
Cloudscape ist der unterschätzte Teil. 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 Ihrem Problem als Material oder Polaris.
Primitives und Distribution
| Was es ist | Was es nicht ist | |
|---|---|---|
| Radix Primitives | Ungestyltes, barrierefreies Verhalten für komplexe Komponenten: Menüs, Dialoge, Comboboxen | Ein Designsystem. Es verzichtet bewusst auf eine Meinung dazu, wie etwas aussehen soll |
| shadcn/ui | Ein Distributionsmechanismus plus eine Token-Konvention: Komponenten werden in das eigene Repo kopiert, nicht als Abhängigkeit installiert | Ebenfalls kein Designsystem. Es legt die Namen der Tokens fest, nicht jedoch die Dichte, Komposition, Motive oder Verbote |
| Tailwind | Ein Constraint-System für Abstände, Farben und Typografie, das auf Klassenebene angewendet wird | Hat eine feste Meinung zu Ihrem Produkt. Die Standardwerte sind neutral und weit verbreitet, weshalb sie oft generisch wirken |
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 vollkommen austauschbaren Interfaces, die oft als „KI-generiert“ beschrieben werden. Die vollständige Unterscheidung.
Die Verzeichnisse und ihr Nutzen
Es gibt mehrere große Kataloge, die öffentliche Designsysteme indexieren. Sie beantworten eine spezifische Frage sehr gut: Hat jemand in meiner Branche dieses Problem bereits 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 den Überblick und gehen Sie zur Quelle für die Tiefe.
Wie ein System angewendet aussieht, statt nur dokumentiert
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 Beispiel 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.
Kit showcase · live surfaces
Verdant Finance
Live renderVerdant Finance rendered from its real tokens across 3 surfaces.
Die entscheidende Frage für jedes Beispiel
Nicht „Ist das attraktiv?“, sondern „Könnte ich den nächsten Screen vorhersagen?“. Ein echtes System macht den zwölften Screen basierend auf den ersten drei vorhersehbar. Wenn man nach dem Studium der Landingpage und des Dashboards nicht erraten kann, wie ein Modal aussehen würde, ist das System lediglich ein Stil – und ein Stil überlebt weder einen zweiten Designer noch einen Agenten.
Ein eigener Teardown
Die wertvollste Version dieser Übung ist eine, die niemand veröffentlicht hat – an einem Produkt aus Ihrer eigenen Branche. Der Zeitaufwand beträgt etwa eine Stunde.
- 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
Berechnete Werte auslesen, nicht schätzen
Öffnen Sie die Dev-Tools und notieren Sie font-weight, letter-spacing, border-width, border-radius und padding. „Enger Zeichenabstand“ ist ein Eindruck; -0.022em bei 48px ist eine Regel.
- 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 lediglich Stichproben.
- 4
Notieren, was fehlt
Keine Schatten. Keine Verläufe. 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
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.
Auf Schritt vier ist besonders zu bestehen. Wir haben 299 DESIGN.md-Dateien analysiert, die KI-Agenten Design-Richtlinien geben sollten, und festgestellt, dass 76 % keinerlei Verbote enthalten. Zudem gaben 86 % Farben als reine Hex-Werte ohne semantische Rolle an und 57 % definierten keine markanten Motive. Diese Dateien beschreiben eine Palette. Die Identität, die sie erfassen wollten, lag in den Abwesenheiten.
Drei Viertel aller Design-Richtlinien in der Praxis verbieten nichts. Doch Identität entsteht durch Verzicht, und eine kopierte Palette lässt diese Verbote hinter sich.
Der zu vermeidende Fehler
Es gibt eine Art, Designsysteme zu studieren, die ein schlechteres Ergebnis liefert, als wenn man bei Null anfangen würde. Das passiert, wenn die Übung rein akquisitiv wird: Wer die besten Teile aus neun Systemen zusammenstellt, erhält ein kompetentes Interface, hinter dem jedoch keine gestalterische Argumentation steht.
Jedes der oben genannten Systeme resultiert aus einer Entscheidung über die Zielgruppe. Die Dichte von Linear ist ein Argument dafür, dass Power-User, die ein Tool den ganzen Tag nutzen, Ruhe und Informationen benötigen. Die Schlichtheit von GOV.UK ist ein Argument dafür, 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 ein Argument dafür, dass Tausende von Teams das System übernehmen werden und keines davon das Brand-Team von IBM ist.
Nutzen Sie diese Beispiele, um die 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 bezüglich Ihrer Zielgruppe ab und lassen Sie die Regeln daraus folgen.
Die Design-Kits von Identity Forge sind in diesem Sinne vollständige Systeme: semantische Farbrollen für Light- und Dark-Mode, Typografie- und Spacing-Skalen, Motive sowie explizite Do's und Don'ts, serialisiert in einer DESIGN.md, die ein Coding-Agent ausführen kann. Kits durchstöbern oder lesen Sie, was eine DESIGN.md-Datei ist.
Welche Designsystem-Beispiele eignen sich am besten zum Lernen?
Das hängt von der Fragestellung ab. Carbon und Spotify's Encore für Layering, Stripe und SLDS 2 für Enforcement und Theming, Airbnb's DLS für plattformübergreifende Verträge, Polaris für Delivery, Linear für die Frage, wie Constraints Identität schaffen, und GOV.UK für die Veröffentlichung der Forschung hinter jeder Komponente.
Welche großen Designsysteme kann ich tatsächlich herunterladen?
Carbon, Polaris, Lightning, GOV.UK und Atlassian sind öffentlich zugänglich. Das interne System von Stripe, das DLS von Airbnb, Spotify's Encore und das System von Linear sind es nicht: Was hier existiert, sind die veröffentlichten Texte der Teams, welche ohnehin oft das nützlichere Artefakt darstellen.
Sollte ich ein Designsystem kopieren, das ich bewundere?
Kopieren Sie die Strenge, nicht den Inhalt. Jedes gute System ist eine Reihe von Antworten auf Fragen zu einer spezifischen Zielgruppe. Wer die Antworten ohne die Fragen übernimmt, erhält ein Interface, das für das Produkt eines anderen optimiert ist. Nutzen Sie Teardowns, um zu kalibrieren, wie spezifisch Ihre eigenen Regeln sein sollten.
Warum veröffentlichen so wenige Unternehmen ihre Designsysteme?
Weil ein System, das darauf ausgelegt ist, ein Produkt unverwechselbar zu machen, nichts davon hat, installierbar zu sein. Ein System hingegen, das für eine breite Adoption entwickelt wurde, muss neutral genug sein, um für Tausende nicht verwandter Produkte zu funktionieren. Eine Veröffentlichung drängt ein System in Richtung Neutralität – das Gegenteil dessen, was eine starke Marke anstrebt.
Lohnt es sich, Designsystem-Verzeichnisse zu nutzen?
Für den Überblick, ja. Sie eignen sich gut, um viele Implementierungen derselben Komponente nebeneinander zu sehen, bevor man die eigene entwirft. Für die Tiefe, nein. Ein Verzeichniseintrag ist ein Link und ein Screenshot; die Herleitungen, die ein System studierenswert machen, finden sich in den Texten des jeweiligen Teams.