Kontextbasierte Designsysteme in der Praxis - SmashingConf

Ich besuche die SmashingConf Freiburg als Mitarbeiter von Pax – vielen Dank an Pax für diese Möglichkeit. Ich habe mir Notizen zu den Talks gemacht und teile hier die Gedanken, die sie ausgelöst haben. Dies ist eine persönliche Konferenznotiz, kein Transkript und keine Aussage von Pax.

Dies ist der erste Beitrag in einer Reihe von Notizen zur SmashingConf Freiburg. Die Konferenz 2026 findet vom 7. bis 10. September in Freiburg statt. Hier ist das offizielle Programm.

TJ Pitres Talk, Context-Based Design Systems in Practice, begann mit einer praktischen Frage: Können Teams die passenden Patterns tatsächlich finden und ohne Rätselraten nutzen? Diese Frage ist seit Jahren relevant, und KI ändert daran nichts. TJ stellte das Framework Context-Based Design Systems (CBDS) vor: ein Modell, um Komponenten, Tokens und Dokumentation so zu strukturieren, dass sie unter realem Produktionsdruck nützlich bleiben.

Das Fundament bilden Benennung, Governance und die tatsächliche Nutzung im Team: Wie erkennen Teams das passende Pattern, wie entwickelt sich das System weiter, und können Menschen es im Alltag einsetzen? KI spielt eine unterstützende Rolle. Wenn diese Struktur steht, können KI-Tools denselben Kontext nutzen, um konsistentere Ergebnisse zu erzeugen, die zur Marke passen. Die folgenden Notizen beleuchten dieses Fundament und die Gedanken, die es bei mir zum Zusammenspiel von Design und Code ausgelöst hat.

Teams helfen, passende Patterns zu finden und zu nutzen

Eine Komponentenbibliothek ist dann nützlich, wenn ein Team erkennen kann, welche Komponente zu einer Anforderung passt und wie sie eingesetzt wird. Namen, Tokens und Dokumentation müssen neben dem Erscheinungsbild auch die Entscheidungen hinter einem Pattern erklären. Sonst müssen Menschen raten, nachfragen oder eine weitere Version von etwas erstellen, das bereits existiert.

Aus TJs CBDS-Ansatz nehme ich mit, dass dies ebenso eine organisatorische wie eine strukturelle Aufgabe ist. Namen helfen beim Finden eines Patterns, Dokumentation bei seiner Anwendung, und Governance schafft einen Weg, Änderungen vorzuschlagen und zu prüfen. Ob das zusammenspielt, zeigt sich daran, ob Teams das System im Alltag tatsächlich nutzen. Dieses Fundament hilft Designern und Entwicklern schon heute und gibt KI-Tools besseren Kontext, wenn Teams sie einsetzen möchten.

Drift ist ein Thema des gesamten Produktlebenszyklus

Design-Intent wandert nicht einmal sauber von Figma nach Code. Er verändert sich, wenn eine Anforderung konkreter wird, ein Sonderfall auftaucht, ein Produkt einen neuen Zustand braucht oder ein Entwickler entdeckt, was eine Plattform tatsächlich erlaubt. Das ist normale Produktarbeit.

Die Frage ist nicht, ob Drift entsteht. Entscheidend ist, ob er sichtbar und bewusst ist und wieder in das System zurückfliesst. Ohne diesen Loop werden eine Designbibliothek und eine Komponentenbibliothek nach und nach zu zwei unterschiedlichen Beschreibungen desselben Produkts.

Unvollständige Designinformationen zwingen Menschen, Lücken selbst zu füllen. Daraus können inkonsistente Implementierungen und doppelte Patterns entstehen. Ein KI-Agent steht vor derselben Unklarheit: Wenn er an einer Stelle einen fest eingetragenen 1px-Border und an anderer Stelle ein nicht damit verbundenes Token für die Border-Breite sieht, muss er raten, ob beides dasselbe bedeutet. Er kann eine plausible Wahl treffen – aber plausibel ist nicht gleich korrekt.

Die Entscheidungen im System explizit machen

Eine Demonstration im Talk war FigmaLint, ein Figma-Plugin, das Komponenten auf Designsystem-Konformität, Barrierefreiheit und Entwicklungsreife untersucht. In meinen Notizen kommt ein Alignment-Score wie 87 % vor. Ich verstehe diesen Wert nicht als ästhetische Bewertung, sondern als Signal dafür, wie viel des Designs in einer strukturierten, wiederverwendbaren Form vorliegt, mit der ein Entwickler – oder ein Agent – arbeiten kann.

Der Unterschied zwischen einem einmalig eingetragenen 1px-Wert und einer benannten Standardvariable für die Border-Breite ist ein kleines, aber aussagekräftiges Beispiel. Das Ziel ist eine explizite, wiederverwendbare Entscheidung: Ein Entwickler soll den vorgesehenen Wert erkennen und verstehen können, wo er gilt. Ein KI-Tool kann anschliessend dieselbe Information nutzen, statt kritische Werte aus Pixeln oder benachbarten Beispielen abzuleiten.

Ein gut strukturiertes Design gibt Teams eine gemeinsame Referenz für Variablen, Komponenten, Varianten, Zustände und Regeln. Es gibt auch einem Agenten eine solidere Grundlage, um Code zu erzeugen, der dem System folgt. Ein Score von 100 % kann ein sinnvolles Ziel für die geprüften Regeln sein. Er beweist für sich allein aber weder, dass Menschen das passende Pattern finden, noch dass das System genutzt wird oder eine gute Produkterfahrung entsteht.

Deshalb sollte ein Figma-Frame auch nicht allein zur Source of Truth werden. Figma kann eine ausgezeichnete Oberfläche für eine Spezifikation sein, aber eine Oberfläche ist nicht die gesamte Spezifikation.

Tools können Kontext transportieren, aber keinen Vertrag ersetzen

Auf diesem Fundament können Tools den Kontext für KI-Assistenten zugänglich machen. Figmas offizieller MCP-Server kann kompatiblen KI-Clients Designkontext wie Variablen, Komponenten und Layout-Daten bereitstellen. Figma dokumentiert ausserdem Code Connect als Möglichkeit, generierten Code zu den Komponenten einer angebundenen Codebasis zu führen.

TJ verwies auch auf Tools seines Unternehmens Southleft, darunter Figma Console MCP. Dieses Tool verbindet KI-Assistenten mit Figma für Extraktion, Erstellung und Debugging. Solche Tools erleichtern es, Designkontext in einen agentischen Workflow zu bringen. Sie entscheiden jedoch nicht, was eine Komponente bedeutet, wann eine neue Variante in die Bibliothek gehört oder wer eine Änderung freigibt. Das bleibt die Arbeit des Systems rund um das Tool.

Eine besonders interessante Idee aus dem Talk ist ein Component Contract. Das ist mehr als eine visuelle Komponentenbeschreibung: Er kann Anatomie, Varianten, Zustände, Tokens, Verhalten und Regeln zur Barrierefreiheit maschinenlesbar festhalten. Der Component-Contract-Proof-of-Concept von Southleft beschreibt sich als Kandidat für eine herstellerneutrale Spezifikation, nicht als fertigen Standard. Die zentrale Idee überzeugt: Ein Contract liegt zwischen Design und Code, Änderungen fliessen in ihn zurück und beide Oberflächen werden gegen ihn geprüft.

Diese Richtung finde ich besonders sinnvoll. Sie schafft einen Ort für Entscheidungen, die nicht zweimal manuell gepflegt werden sollten. Als Softwareentwickler kennen wir diese Disziplin aus API-Spezifikationen: Ein gemeinsamer Vertrag definiert, worauf sich Beteiligte verlassen können, und daraus kann Code erzeugt werden. Ein Component Contract wendet dieselbe Idee auf die Grenze des Designsystems an.

Mein Fazit: erst spezifizieren, dann generieren

Damit ein Team eine Komponente sicher auswählen und verwenden kann, brauchen wir eine klare Komponentenstruktur. Dieselben Informationen können auch einen Agenten leiten. Meine praktische Checkliste würde mindestens explizit machen:

• ihren Zweck und ihre semantische Rolle;
• ihre Anatomie: welche Teile sie hat und welche optional sind;
• Eigenschaften, Varianten und Zustände, einschliesslich ungültiger und Ladezustände;
• Tokens und visuelle Regeln statt beliebiger Werte;
• Interaktions-, Inhalts- und Barrierefreiheitsanforderungen; und
• Beispiele für Kontexte, in denen sie verwendet werden soll – und nicht verwendet werden soll.

Figma kann dafür eine starke Basis sein, weil dort viele Teams bereits über Komponenten sprechen. Wissen darf aber nicht im Kopf des Designers oder nur in einem Kommentar neben einem Frame bleiben. Wenn es wichtig genug ist, um einen Entwickler zu leiten, muss es explizit genug werden, um auch einen Agenten zu leiten.

Das verändert die Rolle von UI/UX-Designern auf produktive Weise. Sie übernehmen einen Teil der Komponenten-Definitionsarbeit, die oft erst nach dem Handoff stattfindet. Im Gegenzug müssen Entwickler design- und UX-bewusster werden. Dieser Wandel zeigt sich bereits bei KI-gestützter Arbeit: Wenn sich Implementierung leichter generieren lässt, werden Urteilsvermögen über die richtige Komponente und die richtige Erfahrung wertvoller. Diesen Wandel haben wir in KI-Entwicklerwandel: Vom Code-Schreiber zum Qualitätswächter beleuchtet.

Storybook gehört in den Feedback-Loop

Für meine eigene Arbeit weitergedacht, würde ich Storybook in das Zentrum des Feedback-Loops zwischen Design und Entwicklung stellen. Es stellt eine gerenderte, überprüfbare Version der tatsächlichen Komponenten bereit – nicht nur eine Design-Intention und nicht nur Source Code. Damit eignet es sich für viele Produkte und Projekte: Ein gemeinsames Storybook gibt Designern und Entwicklern dieselbe gerenderte Referenz, auch wenn Komponenten in verschiedenen Anwendungen wiederverwendet werden. Agents können diese Referenz ebenfalls nutzen.

Auf dieser gemeinsamen Referenz aufbauend, würde ich den folgenden automatisierten Loop erproben. Das ist mein Vorschlag zur Anwendung der Ideen, keine Wiedergabe von TJs Talk:

1. Ein Agent liest den Component Contract und den relevanten Figma-Kontext.
2. Er implementiert oder verändert eine Komponente.
3. Storybook rendert die relevanten Zustände und Varianten.
4. Ein Browser-Check, zum Beispiel mit Playwright, prüft diese Darstellungen gegen vereinbarte Regeln oder freigegebene Referenzen.
5. Das Ergebnis geht an einen Menschen, wenn die Differenz mehrdeutig, produktspezifisch oder wesentlich ist.

Tools wie Story UI weisen ebenfalls in diese Richtung: Sie können Storybook-Kontext nutzen, um Component Stories zu erzeugen, und ihre Dokumentation empfiehlt Playwright, um generierte Arbeit zu rendern und zu prüfen. Entscheidend ist nicht ein einzelnes Tool. Entscheidend ist, dass der Loop eine ausführbare Produktoberfläche und einen bewussten menschlichen Entscheidungspunkt enthält.

Ein Pixelvergleich ist nützlich, aber kein endgültiger Richter. Eine kleine visuelle Differenz kann harmlos sein; eine perfekt passende Komponente kann dennoch einen verwirrenden Flow erzeugen. Jemand muss Komponenten weiterhin im Produkt und in ihren tatsächlichen Kombinationen und Varianten prüfen – nicht nur isoliert.

Feedback muss zurückfliessen

Für mich führt das zurück zur Governance: Was passiert, wenn die Implementierung einen neuen Bedarf entdeckt?

Stellen wir uns vor, ein Team braucht für ein Feature eine rote Variante eines Buttons. Wird daraus eine Komponentenvariante? Eine lokale Ausnahme? Ein semantisches Token? Oder zeigt der Anwendungsfall, dass das Statusmodell des Produkts unvollständig ist?

Die falsche Antwort ist, jede Änderung automatisch in eine globale Bibliothek zu übernehmen. Globale Komponentenbibliotheken werden schwerer verständlich, wenn jede einmalige Anforderung zu einer kanonischen Variante wird. Genauso falsch ist es, jede neue Entscheidung im Produktcode zu verstecken.

Teams brauchen eine Regel für diese Aufnahme. Eine Änderung kann einen Platz im gemeinsamen Contract verdienen, wenn sie mehr als einen echten Anwendungsfall hat, eine klare semantische Bedeutung besitzt, Anforderungen an die Barrierefreiheit erfüllt und einen Owner hat, der sie pflegt. Andernfalls kann sie eine dokumentierte lokale Komposition bleiben. Es geht nicht um Bürokratie, sondern darum, die Entscheidung sichtbar und reversibel zu machen.

Das ist besonders relevant für Organisationen mit mehreren Produkten. Eine gemeinsame Spezifikation für UI-Prinzipien, Tokens, Verhalten und Barrierefreiheit kann Teams Orientierung geben, während jedes Produkt seine eigene Komponentenbibliothek und lokale Kompositionen behält. KI könnte helfen, diese Struktur zu pflegen und zu prüfen. Die gemeinsame Ebene gibt Teams und Agents denselben Kontext, während die Produktbibliotheken die Patterns bewahren, die zu den Anforderungen des jeweiligen Produkts passen.

Präzision im UI ist keine Vollständigkeit im UX

Die Diskussion kann bis zu einer Definition einer Border-Breite von einem Pixel gehen. Diese Präzision ist wichtig. Sie muss aber aus der Höhe des gesamten Produkts betrachtet werden.

UI lässt sich oft sehr präzise kodieren: Werte, Zustände, Komponenten und visuelle Regeln können in Design Tokens und Code abgebildet werden. UX ist mehr als das. Sie entsteht aus dem Zusammenspiel von Komponenten, Copy, Informationsarchitektur, Timing, Fehlerbehandlung und dem tatsächlichen Ziel des Nutzers.

Meine Notizen konzentrieren sich stark auf UI-Details. Daraus ergibt sich für mich eine weiterführende UX-Frage: Wie präzise kann ein System die Erfahrung beschreiben, nicht nur das Erscheinungsbild? Diese Frage nehme ich über den Talk hinaus mit. Ein Agent kann Tokens und Varianten zuverlässig validieren, wenn die Regeln existieren. Er kann nicht allein aus einem Komponenten-Katalog entscheiden, ob ein Nutzerweg verständlich ist oder ein neuer Flow ein echtes Problem löst.

Design und Code zusammenzuhalten war schon immer schwierig. TJs CBDS-Ansatz führt mich zurück zu der Arbeit, die ein System belastbar macht: klare Namen, verknüpfte Komponenten und Tokens, nutzbare Dokumentation und Verantwortung für Änderungen. Das ist relevant, ob ein Team KI einsetzt oder nicht. Wenn dieses Fundament steht, kann KI bei den mühsamen Teilen helfen: Kontext extrahieren, Unterschiede finden, Zustände rendern, Regeln prüfen und die Evidenz nah an der Änderung halten.

Der wichtigste Loop ist deshalb nicht Figma zu Code. Es ist ein breiterer Loop zwischen Designern, Entwicklern und den Menschen, die das Produkt nutzen. Code sollte die Spezifikation informieren, Nutzer sollten die Erfahrung informieren und beides braucht einen Weg zurück in das Designsystem.

Wenn Sie eine App entwickeln oder weiterentwickeln und diesen Feedback-Loop belastbarer machen möchten, unterstützen wir Sie bei Entwicklung und langfristiger Wartung. Oder kontaktieren Sie uns, um Erfahrungen auszutauschen.