Ihr Designsystem lebt nicht in Figma als Markdown

Das Portfolio als strukturierter Text zum Lesen, Teilen oder als Kontext für einen KI-Assistenten.

_DESIGN SYSTEMS_

# Ihr Designsystem lebt nicht in Figma

Jahrelang galt Figma als maßgebliche Quelle und der Code als ihre Kopie. Seit KI-Agenten Oberflächen schreiben, trägt dieses Modell nicht mehr. Dies ist die Alternative, die ich umgesetzt und getestet habe: ein Headless-Designsystem.

Javier González · 11. Nov. 2026 · 7 Min. Lesezeit

## Das Problem: zwei Systeme, die sich ähneln

In fast jedem Team, mit dem ich gearbeitet habe, gibt es in Wahrheit zwei Designsysteme. Das eine liegt in Figma: Bibliotheken, Variablen, Komponenten mit ihren Varianten. Das andere liegt im Code: Tokens, React-Komponenten, Storybook-Stories. Sie sehen sich sehr ähnlich, aber niemand kann garantieren, dass sie dasselbe sind.

Die Lücke dazwischen wird von Hand geschlossen. Die Designerin übergibt einen Bildschirm, der Entwickler interpretiert ihn, und dabei wird noch einmal entschieden, was längst entschieden war: welche Variante, welcher Abstand, was passiert, wenn der Text nicht passt. Jede Übergabe ist eine Übersetzung, und jede Übersetzung bringt kleine Abweichungen mit sich.

Solange nur Menschen arbeiteten, ließ sich das im Gespräch auffangen. Ein Entwickler mit Zweifeln fragt nach. Ein KI-Agent fragt nicht: Er füllt die Lücke mit dem Wahrscheinlichsten. Steht die Regel nirgends, wo er sie lesen kann, erfindet er eine.

## Die Idee: Das System ist die Spezifikation, nicht die Datei

Ein Headless-Designsystem trennt die Entscheidungen von den Werkzeugen, in denen sie sichtbar werden. Die Entscheidungen liegen in einem Repository, als Text, mit Änderungshistorie und Review. Figma, React, Storybook, das CMS und die Agenten sind Abnehmer dieser Entscheidungen. Keines davon ist das Original.

„Von Figma entkoppelt“ heißt nicht „ohne Figma“. Designer gestalten weiterhin dort, mit echten Komponenten und Variablen. Was sich ändert, ist die Richtung der Autorität: Weichen Figma und Repository voneinander ab, gibt es eine klare Regel, was gilt, und einen Mechanismus, der es meldet.

## Die drei Bausteine im Repository

### 1. Tokens

Die grundlegenden visuellen Entscheidungen: Farbe, Typografie, Abstände, Radien, Schatten. Sie werden in einem standardisierten Design-Token-Format gespeichert und in das umgewandelt, was jeder Abnehmer braucht: Figma-Variablen auf der einen Seite, CSS-Eigenschaften auf der anderen.

Heikel ist die Synchronisierung. Tokens und Figma-Variablen müssen in beide Richtungen verbunden sein, aber nur eine Richtung ist maßgeblich. Ändert jemand eine Variable in Figma, ist das ein Änderungsvorschlag für das Repository, keine Änderung am System.

### 2. Komponentenspezifikationen

Das ist der Baustein, den fast kein System hat und der das Ergebnis am stärksten verändert. Eine Spezifikation beschreibt eine Komponente so, dass ein Mensch und eine Maschine sie gleich verstehen.

Klassische Dokumentation erklärt die Komponente. Die Spezifikation grenzt sie ab: Sie sagt, was erlaubt ist, und macht damit automatisch prüfbar, ob ein Entwurf oder ein Stück Code sie einhält.

### 3. Die Zuordnung zwischen Design und Code

Jede Figma-Komponente muss ihr Gegenstück im Code kennen und umgekehrt. Ohne diese Zuordnung sieht ein Agent, der einen Bildschirm erhält, Rechtecke und Text. Mit ihr sieht er „einen primären Button in einer Produktkarte“, samt Eigenschaften.

## Mit Figma verbunden: prüfen und übergeben

Mit diesen drei Bausteinen ändert sich die Arbeit in Figma an zwei Stellen.

**Vor der Übergabe wird geprüft.**: Ein Plugin vergleicht den Entwurf mit den Spezifikationen: Komponenten, die nicht aus dem System stammen, lose Werte, wo ein Token stehen sollte, Varianten, die es nicht gibt, fehlende Zustände. Das sieht man beim Gestalten, nicht drei Wochen später im Code-Review.

**Übergeben wird Struktur, kein Bild.**: Statt Screenshots mit Maßen ist die Übergabe eine Beschreibung des Bildschirms: aus welchen Komponenten er besteht, mit welchen Eigenschaften und welchem Inhalt. Daraus entstehen direkt React-Pakete, Storybook-Stories oder das JSON, das das CMS braucht.

## Was „bereit für KI“ wirklich bedeutet

Ein Agent braucht dasselbe wie ein neuer Entwickler am ersten Tag, nur schriftlich und eindeutig:
- **Kontext, den er lesen kann.**: Tokens und Spezifikationen als strukturierter Text, nicht als Ebenen einer Designdatei.
- **Regeln, die er prüfen kann.**: Sagt die Spezifikation, dass ein primärer Button nur einmal pro Ansicht vorkommt, lässt sich das überprüfen.
- **Beispiele.**: Ein korrektes und ein Grenzfall lehren mehr als drei Absätze Beschreibung.

Damit hört der Agent auf zu raten. Er baut mit den Komponenten des Systems, nicht an ihnen vorbei, und sein Ergebnis kann dieselbe Prüfung durchlaufen wie die Arbeit eines Menschen.

Für KI braucht es kein eigenes System. Das System für Agenten vorzubereiten und die Zusammenarbeit zwischen Design und Frontend zu ordnen, ist dieselbe Arbeit.

## Was sich für das Team ändert

- **Für das Design:**: weniger Freiheit, Werte zu improvisieren, und mehr Gewissheit, dass das Gestaltete baubar ist. Die Prüfung kommt während der Arbeit.
- **Für das Frontend:**: Die Übergabe ist keine Interpretation mehr. Es kommt Struktur an, und Zweifel klärt die Spezifikation, nicht ein Nachrichtenverlauf.
- **Für das Produkt:**: Entscheidungen sind festgehalten und versioniert. Man sieht, wann sich eine Regel geändert hat und warum.

Unverändert bleibt, wer entscheidet. KI erkundet, baut und prüft; Menschen prüfen und entscheiden.

## Was noch nicht gelöst ist

Es wäre unehrlich, das als fertig darzustellen.
- **Spezifikationen müssen gepflegt werden.**: Eine veraltete Spezifikation ist schlimmer als keine, denn jetzt gehorcht ihr eine Maschine.
- **Governance wird wichtiger, nicht unwichtiger.**: Es muss geklärt sein, wer eine Änderung freigibt und wie sie aus Figma heraus vorgeschlagen wird.
- **Ein Pilot ist kein Produktivbetrieb.**: Was ich hier beschreibe, ist mit einem Design-Team und einem Frontend-Team umgesetzt und getestet. Es auf eine ganze Organisation auszuweiten, ist eine andere Aufgabe.

## Womit anfangen

Beginnen Sie nicht mit dem ganzen System.
- **Wählen Sie eine Komponente,**: die auf vielen Bildschirmen vorkommt.
- **Schreiben Sie ihre Spezifikation**: mit der Vorlage zu diesem Artikel.
- **Verbinden Sie sie:**: die Figma-Komponente mit ihrem Gegenstück im Code, ihre Werte mit Tokens.
- **Lassen Sie einen Agenten sie verwenden,**: in einem echten Ablauf, und beobachten Sie, wo er etwas entscheidet, das die Spezifikation offenlässt.
- **Korrigieren Sie die Spezifikation,**: nicht das Ergebnis. Dann folgt die nächste Komponente.

Ist die Übergabe zwischen Design und Frontend nach fünf Komponenten nicht kürzer, liegt das Problem woanders, und das herauszufinden hat wenig gekostet.

Markdown

### Vorlage für eine Komponentenspezifikation

Eine Markdown-Datei für Ihre erste Spezifikation: Eigenschaften, Zustände, Tokens, Barrierefreiheit, prüfbare Regeln, ein Beispiel und ein Grenzfall.

Vorlage herunterladen (https://baguelus.com/recursos/plantilla-contrato-componente-de.md)