KI verändert rasant, wie Design und Entwicklung zusammenarbeiten. Für viele Unternehmen und Team-Leads stellt sich daher die Frage, was mit einem Design-Tool wie Figma und einem KI-Agenten heute überhaupt möglich ist und welche Voraussetzungen dafür geschaffen werden müssen. Wir geben einen Überblick.

Das Design System als Ausgangspunkt

Grob lassen sich verschiedene Anwendungsfälle unterscheiden. Im ersten sollen Design-Teams innerhalb von Figma durch KI unterstützt und beschleunigt werden. Im zweiten soll das, was in Figma entstanden ist, möglichst schnell und zuverlässig mittels KI in produktionsreifen Code überführt werden.

Egal welchen Weg ihr einschlagt, im Zentrum steht mindestens eine gut gepflegte Figma-Komponenten-Bibliothek, im besten Fall ein echtes Design System, das Design-Komponenten, Code Komponenten, sowie zahlreiche Regeln zur Verwendung der Elemente inkl. Sprachregelungen usw. umfasst. Ein solches System ist der Ort, an dem das gesammelte Wissen des Teams verschriftlicht ist. Je vollständiger und sauberer, desto besser sind die Ergebnisse, die eine KI daraus ableiten kann.

Eine Figma- oder Code-Bibliothek existiert in vielen Unternehmen bereits oder wird gerade aufgebaut. In der Praxis liegt sie allerdings häufig nicht in der Qualität vor, die für KI-Workflows nötig ist. Das betrifft weniger die visuelle Seite als die inhaltlichen und konzeptionellen Aspekte. Oft fehlt zum Beispiel eine saubere Beschreibung des Zwecks einer Komponente, ihrer Einsatzsituationen und ihrer Rahmenbedingungen. Genau dieses Wissen aber braucht die KI, um sinnvolle Entscheidungen treffen zu können.

KI als Unterstützung im Design

Design-Teams, die bereits in Figma arbeiten, können durch KI direkt in Figma unterstützt werden. Es gibt dafür z.B. in Figma integrierte kleinere KI-Funktionen zum Aufräumen der Datei oder zum Erzeugen und Bearbeiten von Bildern. Ihr Zweck ist es in erster Linie, das Team im Arbeitsablauf zu beschleunigen, wiederkehrende Aufgaben abzunehmen, für Konsistenz zu sorgen und Fehler zu vermeiden.

Auch Agenten können für solche Aufgaben eingesetzt werden, doch normalerweise kommen Agenten für komplexere und größere Aufgaben zum Einsatz. Daher gehen wir auf die integrierten KI Mini-Tools hier nicht im Detail ein.

Von der Idee zum Design

Interessant wird es, wenn Konzeption und Prototyping selbst weitgehend selbstständig, also agentisch, erledigt werden sollen. Ziel ist das Erstellen von Screens in einem professionellen, markentreuen und konsistenten Look; möglicherweise sollen sogar klickbare Prototypen entstehen. Dafür braucht es zwingend eine Bibliothek mit allen benötigten Komponenten. Und diese Komponenten müssen nicht nur existieren, sondern vor allem inhaltlich gut beschrieben und organisiert sein.

Das bedeutet konkret: Jede Komponente hat einen Namen und eine ausführliche Beschreibung. Diese Beschreibung erklärt den Zweck der Komponente, in welchen Situationen sie eingesetzt wird, was vermieden werden sollte und welche Rahmenbedingungen gelten. Alles, was einem Design-Team konzeptionell im Kopf schlummert, muss verschriftlicht werden. Dokumentiert wird dies z.B. in der Beschreibung der Komponenten oder, noch feiner, in der Beschreibung einzelner Varianten.

Ist das erfüllt, könnt ihr euch den Ablauf so vorstellen: Ihr nutzt den Agenten in Figma (Design Agent) oder verbindet ein externes KI-Tool eurer Wahl mit eurer Datei via MCP. Anschließend formuliert ihr euren Konzeptionswunsch als Prompt, zum Beispiel sinngemäß »Erstelle eine neue Landingpage mit folgenden Zielen …« oder »Entwirf eine Smartphone-App für die Steuerung unsere Maschine XY mit folgenden Funktionen …«. Weil die Bibliothek alle nötigen Informationen bereithält, entstehen daraus Entwürfe in sehr guter Qualität, etwa ein klickbarer Prototyp oder einzelne Screens.

Von Design zu Code

Der zweite große Anwendungsfall ist die Überführung des Designs in Code. Einerseits sollen so native Prototypen hergestellt werden, die im Browser laufen und leicht im Code angepasst werden können, andererseits soll tatsächlich der produktionsreife Code einer Website oder Applikation entstehen.

In beiden Fällen ist es enorm wichtig, dass die Ergebnisse erwartbar und konsistent sind. Die KI darf sich bei der Umsetzung eines Buttons nicht beim ersten Mal so und beim nächsten Mal anders entscheiden. Produktionsreif bedeutet vor allem, dass die Qualität den Anforderungen entspricht.

Die Code-Bibliothek soll neu aufgebaut werden

Wenn bereits eine Design-Bibliothek in Figma existiert, und die passende Code-Bibliothek daraus abgeleitet aufgebaut werden soll, muss die Vorlage nahezu perfekt sein. Sie muss alle Figma-Standardanforderungen an Bibliotheken erfüllen wie z.B. ein konsequent verwendetes Auto-Layout, Variablen für alles und eine saubere Organisation nach Atomic Design mit Komponenten und Varianten. Verschiedene Tools und Linter helfen dabei, Fehler zu erkennen und zu beheben.

Der Anspruch muss sehr hoch sein. Besonders bei den Design Tokens, also den Figma-Variablen, muss die Umsetzung exakt stimmen, damit am Ende sauberer Code in der gewünschten Syntax herauskommt. Wenn, wie zuvor bereits beschrieben, alle Komponenten mit detaillierten Beschreibungen ausgestattet sind, können auch Entscheidungen zur Barrierefreiheit besser getroffen werden. Denn dann geht es nicht nur darum, wie ein Element aussieht, sondern darum, wie und wofür es verwendet wird. Die KI kann folglich semantische Entscheidungen deutlich besser treffen.

Technisch verbindet ihr Figma über den MCP-Server mit eurem KI-Tool. Anschließend solltet ihr schrittweise vorgehen. Vermeidet es, die gesamte Figma-Datei in einem einzigen Prompt zu referenzieren, sondern arbeitet strukturiert und schrittweise. Zuerst werden die Variablen ausgelesen und die Variablen-Struktur angelegt, idealerweise abstrahiert über ein offenes, JSON-basiertes Token-Format. Anschließend arbeitet ihr euch entlang des Atomic Design-Ansatz von klein nach groß durch die Bibliothek: erst die einzelnen Atome, dann die daraus zusammengesetzten Moleküle, dann die Organismen, also größere Elemente wie wiederkehrende Sinnabschnitte (Pattern, Module). Im letzten Schritt folgen Templates und schließlich vielleicht sogar Flows. Dieses schrittweise, aufeinander aufbauende Vorgehen spart euch viele Tokens, führt zu konsistenteren Ergebnissen und ergibt ein sauber strukturiertes System.

Es gibt bereits eine Code-Bibliothek

Wenn neben der Figma-Bibliothek bereits eine Code-Bibliothek existiert, deren Komponenten in einem Repository o.ä, liegen, kommt das Figma-Feature »Code Connect« ins Spiel. Mittels Code Connect verknüpft ihr eine Komponente aus der Figma-Bibliothek mit ihrem Gegenstück im Code.

Die Vorteile dieses Vorgehens sind deutlich spürbar. Setzt ein KI-Agent eine Ansicht um und stößt auf verknüpfte Komponenten, erfindet er deren Code nicht neu, sondern greift auf die bestehende Codebasis zu. Das spart Tokens und sorgt für noch konsistentere Ergebnisse. Diese Konstellation Figma-Bibliothek plus verknüpfte Code-Bibliothek, ist der Idealfall.

Code Connect ist Teil der höheren Figma-Lizenzmodelle und lässt sich auf zwei Arten nutzen. Die einfache Variante ist die Verwendung über die Figma-Benutzeroberfläche (Code Connect UI). Hier verbindet ihr Komponenten per Klick und könnt der Verbindung zusätzliche Notizen für die KI mitgeben. Die zweite Variante läuft über die Kommandozeile und integriert Code Connect direkt in die Codebasis (Code Connect CLI). Neben den eigentlichen Code-Dateien liegen dann zusätzliche Dateien, die festhalten, welche Figma-Komponente zu welcher Code-Komponente gehört. Dabei lässt sich sehr differenziert abbilden, welche Eigenschaften und States im Code welchen Varianten im Design entsprechen. Das ist aufwendig, weshalb Figma für diesen Fall unter anderem einen Skill für die KI bereitstellt.

Wenn ihr eine gut verknüpfte Code-Bibliothek hat, könnte ihr theoretisch Qualität in der Figma-Datei einsparen, weil der Agent die Details dort im Idealfall gar nicht mehr interpretieren muss. Als Empfehlung möchten wir das aber nicht verstanden wissen, denn eine saubere Design-Bibliothek zahlt an vielen anderen Stellen auf die Qualität ein.

Die Design-Bibliothek soll aus dem Code abgeleitet werden

Seltener, in der Praxis aber durchaus sinnvoll, ist die umgekehrte Richtung. Frontend-affine Teams haben häufig bereits eine Code-Bibliothek in sehr guter Qualität, aber noch keine gepflegte Figma-Bibliothek. Um diese automatisch zu erzeugen, kann der Code über den MCP-Server ausgelesen und daraus die Design-Bibliothek in Figma abgeleitet werden. Variablen und Komponenten werden dann in Figma automatisiert erzeugt.

Weil der Code oft die verlässlichere und höherwertige Quelle ist, entsteht so eine Design-Bibliothek, die sauber zum bestehenden Code passt. Wir haben das in mehreren Projekten umgesetzt, unter anderem bei unserem eigenen Design System für WordPress-Projekte.

Auch bei diesem Setup sollte schrittweise vorgegangen werden: Zunächst die Variablen, dann der Rest nach Atomic Design. Da im Browser mitunter CSS-Features verwendet wurden, die Figma nicht abbilden kann, müssen kleinere Abstriche in Kauf genommen werden.

Die strategische Frage: Wo liegt das Original?

Sobald Bibliotheken in Design und Code existieren, stellt sich die klassische Frage: Wo liegt die sog. »Single Source of Truth« – also das Original? Habt ihr eine Komponente erst im Design entworfen und den Code daraus abgeleitet, oder umgekehrt? Und wenn ihr etwas ändert, an welcher Stelle macht ihr das zuerst, und wo muss es nachgezogen werden? Dieselbe Frage betrifft die Design Tokens, also ob die Variablen in Figma oder im Code das Original sind, und ebenso die Dokumentation, ob ihr sie in Markdown-Dateien im Repository oder in den Figma-Komponenten pflegt.

Durch KI können sogenannte bidirektionale Workflows eingerichtet werden, wodurch diese Frage an Schärfe verliert. Änderungen lassen sich so synchronisieren, dass sie an einer Stelle vorgenommen und automatisch an allen anderen nachgezogen werden. Ändert ihr eine Variable im Code, erkennt der Agent das und trägt sie in Figma nach. Ändert ihr sie in Figma, geschieht dasselbe umgekehrt. Aus einem einzigen Original wird ein Netz aus synchronisierten Originalen in verschiedenen Umgebungen.

Trotzdem haben wir eine klare Empfehlung, die wir auch selbst beherzigen. Versucht, möglichst wenige Abhängigkeiten zu einzelnen Plattformen aufzubauen. Praktisch bedeutet das, die Variablen im Standard für Design Tokens zu definieren, die Komponenten-Beschreibungen in Markdown-Dateien im eigenen Projekt zu dokumentieren und Code Connect über die Kommandozeile direkt ins Repository zu integrieren. So habt ihr versionierbare Dateien in Standardformaten, auf die ihr jederzeit zugreifen könnt und die euch niemand wegnehmen kann.

Der scheinbare Nachteil, dass Beschreibungen in Markdown-Dateien in Figma zunächst nicht sichtbar sind, lässt sich mit KI leicht auflösen. Ihr weist den Agenten an, das Komponenten-Verzeichnis zu lesen und die Beschreibungen über die MCP-Schnittstelle in die passenden Figma-Komponenten einzutragen. Auch das lässt sich bidirektional einrichten, sodass Beschreibungen immer aktuell sind.

Wo die Anweisungen hinterlegt werden

Egal ob aus einer Idee ein Prototyp oder aus einem fertigen Design sauberer Code entstehen soll, ihr müsst entscheiden, wo ihr die Anweisungen hinterlegen möchtet, die den Prozess steuern und für konsistente Ergebnisse sorgen. Was genau ihr mit Figma, Code und KI macht ist dabei zweitrangig. Entscheidend ist, dass die KI bei gleicher Aufgabe immer vergleichbar arbeiten muss.

Ihr könnt Vorgaben auf verschiedenen Ebenen festlegen, zum Beispiel zentral für die gesamte Organisation, pro Projekt oder individuell pro User.

Dafür habt ihr zwei Wege. Entweder legt ihr die Vorgaben direkt beim KI-Anbieter fest, etwa über das Web-Interface. Oder ihr steuert sie auf Dateiebene, meist im Markdown-Format, über Instruktionsdateien wie eine claude.md oder über sogenannte Skills. Auch diese Dateien könnt ihr flexibel platzieren, zum Beispiel auf dem eigenen Rechner, im Repository eines Projekts oder verbindlich für die ganze Organisation.

Welcher Weg der beste ist, hängt davon ab, wie das Team arbeitet und womit es die verlässlichsten Ergebnisse erzielt. Unsere Empfehlung geht in dieselbe Richtung wie zuvor bei der Dokumentation der Komponenten. Wir möchten möglichst geringe Abhängigkeit von einzelnen Plattformanbietern. In der Praxis bedeutet das, Anweisungen liegen eher in Markdown-Dateien und Skills. So lassen sie sich bei Bedarf zu einem anderen LLM-Anbieter umziehen.

Fazit

Die einzelnen Bausteine greifen ineinander. Am Zentrum steht in fast allen Szenarien eine saubere, gut beschriebene Komponenten-Bibliothek. Auf ihr baut die KI-Unterstützung im Design auf, auf ihr baut die Überführung in produktionsreifen Code auf, und sie ist auch die Grundlage dafür, Design und Code dauerhaft synchron zu halten. Die eigentliche Investition liegt weniger in Tools und Anbietern als in der Qualität und Dokumentation des Design Systems. Wenn ihr hier sauber arbeitet und die eigenen Daten in offenen Standards definiert, schafft ihr eine nachhaltige Grundlage für schnelle, konsistente und verlässliche Workflows, ohne euch von einer einzelnen Plattform abhängig zu machen. Selbst ohne KI hat diese Dokumentation einen großen Mehrwert.

Der Beitrag Figma und KI-Agenten: Automatisierte Workflows von der Idee bis zum Code erschien zuerst auf Agentur kulturbanause.

Design Tokens systematisieren die Charakteristika eines Designs. Entscheidungen zu Farben, Formen, Abständen, Schriftgrößen oder Animationen werden mittels Tokens dokumentiert und an zentraler Stelle organisiert. Menschen und Maschinen können sie schnell finden, auslesen und die korrekte Verwendung verstehen, was die Konsistenz eines Produkts verbessert und die Umsetzungsgeschwindigkeit erhöht.

Design Tokens bilden das Fundament eines Design Systems und zählen neben Konzepten wie Mobile First, Atomic Design und Progressive Enhancement zu zentralen Konzepten bei der Gestaltung digitaler Produkte. Seit Oktober 2025 existiert ein W3C-Community-Standard, der bereits von zahlreichen Design-Tools unterstützt wird.

Was sind Design Tokens?

In einem digitalen Design-Projekt wie einer Website oder Applikation müssen viele Entscheidungen getroffen werden und die meisten werden aus Gestaltgesetzen abgeleitet und folgen einer visuellen Hierarchie: Größere Elemente sind wichtiger als kleine; kräftigere Farben werden stärker wahrgenommen als blasse; geringe Abstände zwischen Elementen erzeugen Zusammengehörigkeit, größere Abstände schaffen inhaltlich Distanz.

Innerhalb des Projekts wiederholen sich diese Entscheidungen: Welche Farbe hat ein bestimmter Button? Wie groß ist der Abstand zwischen zwei Buttons? Welche Abrundung hat der Button und welche Abrundung das Objekt in dem der Button platziert ist?

Design Tokens geben diesen Werten einen Namen. Statt beispielsweise den Farb-Code #007c86 (petrol) direkt zu verwenden, referenziert ihr einen Token wie button-primary-bg. Der konkrete Wert wird zentral gepflegt und kann sich ändern, ohne dass jede Verwendungsstelle einzeln angepasst werden muss.

Typische Token-Kategorien

Welche Tokens notwendig sind, hängt vom Projekt ab. Die folgenden Kategorien werden am häufigsten verwendet:

• Farben (Colors)
• Schrift (Fonts)
• Abstände (Spacing)
• Abrundungen (Radius)
• Schatten (Shadows / Elevation)
• Animationen (Timing)
• …

Organisation von Design Tokens

Die Token-Struktur sollte in erster Linie zum Projekt und dem Team passen, das am Projekt arbeitet. Teams mit überschaubarem Know-how und kleine Projekte profitieren möglicherweise nicht (zumindest nicht wirtschaftlich) von zu komplex geplanten Strukturen.

Nichtsdestotrotz haben sich bei der Organisation und Benennung von Design Tokens mittlerweile klare Industriestandards entwickelt. Die folgende Vorgehensweise ist sehr verbreitet.

Abstraktionsebenen von Design Tokens

Design Tokens werden in verschiedenen Ebenen (auch Gruppen, Collections) organisiert. Diese Ebenen beziehen sich aufeinander und abstrahieren Tokens dadurch. In der Praxis haben sich folgende Ebenen etabliert:

• Primitive Tokens (auch Base Tokens) definieren die reine Palette. Die Benennung der Tokens orientiert sich am jeweiligen Wert. Z.B. blue-600, radius-8, spacing-16. Die primitiven Tokens beschreiben was ein Wert ist, nicht wofür er eingesetzt wird.
• Semantic Tokens (auch Alias Tokens) geben einem primitiven Wert eine Bedeutung. Sie beschreiben wofür ein Wert verwendet wird: color-background, color-action, font-size-heading.
• Component Tokens verbinden einen semantischen Wert mit dem konkreten UI-Element. Sie beschreiben wo genau ein Wert zum Einsatz kommt: button-background, card-padding.

Die Ebenen referenzieren einander: blue-600 → color-action → button-background. Das wirkt zunächst nach Overhead, hat aber entscheidende Vorteile. Ändert sich im zuvor beschriebenen Beispiel z.B. der blaue Farbton des gesamten Systems, wird nur ein einziger primitiver Token angepasst (blue-600) und die Änderung vererbt sich durch alle Ebenen. Wenn die generelle Farbe für interaktive Elemente (Action Elemente) verändert werden soll, reicht die Anpassung des semantischen Tokens color-action. Soll hingegen nur der Button eine andere Farbe bekommen, wird nur dessen Component Token button-background geändert.

Die Ebene der semantischen Tokens wird nicht zwingend verwendet oder nur in Teilen. In solchen Fällen werden Primitives direkt auf Component Tokens »gemapped«. Semantische Tokens sollten vor allem dort verwendet werden, wo sog. »Modes« Sinn machen.

Modes (auch Kontext / Themes)
Ab der 2. Abstraktionsebene kommen die sog. Modes ins Spiel. Ein Mode wird dann relevant, wenn der Wert eines Tokens sich in verschiedenen Situationen ändern soll. Farben unterscheiden sich beispielsweise zwischen Light Mode und Dark Mode. Abstände und Schriftgrößen ändern sich häufig in Abhängigkeit zur Viewport-Größe. Im CSS-Code werden die Modes häufig mit Media Queries realisiert.

Benennung

Für die Benennung von Design Tokens gibt es keinen formalen Standard, aber eine gängige Praxis. Der Name eines Tokens setzt sich aus mehreren Segmenten zusammen, die von allgemein nach spezifisch angeordnet werden. Nicht jedes Segment kommt in jedem Token vor und die Reihenfolge weicht je nach System leicht ab.

• Namespace (optional): Ein Präfix für Systeme, Marken oder Themes
• Kategorie: die Art des Wertes, z.B. color, spacing, font
• Komponente: das konkrete UI-Element, z.B. button, card
• Variante: die Ausprägung, z.B. primary, danger, subtle
• Eigenschaft: wofür der Wert steht, z.B. background, text, border
• Zustand: der Interaktionszustand, z.B. hover, focus, disabled
• Skala: die Abstufung, z.B. 100 bis 900 oder sm / md / lg

Die Ordnung von allgemein nach spezifisch ist sinnvoll, da zusammengehörige Tokens so beieinander stehen und Ordnerstrukturen bei der Organisation von Tokens (z.B. in Figma) problemlos überführt werden können. In der Praxis werden dann beispielsweise folgende Namen verwendet:

• Primitive Tokens: color-red-500
• Semantic Tokens: color-danger
• Component Tokens: button-danger-background-hover, card-padding

Typische Fehler im Zusammenhang mit Design Tokens

Ein häufiger Fehler ist, visuelle Eigenschaften im Namen von nicht-primitiven Tokens zu kodieren. Ein Token wie button-red macht Ärger, sobald der Button nicht mehr rot ist.

Auch plattformspezifische Einheiten in Namen wie spacing-16px sollten vermieden werden. Der Wert 16px gehört in die Token-Definition, nicht in den Namen, da im Code z.B. nicht mit Pixeln, sondern mit der Einheit em gearbeitet wird. Namen müssen Bedeutung kommunizieren, keine Implementierungsdetails.

Lästig wird es auch, wenn die Benennung zu wenig Freiraum für Skalierung bietet. font-tiny oder font-largest machen es schwierig noch sinnvolle Namen oberhalb oder unterhalb der Liste zu finden.

Zuletzt müssen die Ebenen (Collections) so organisiert sein, dass die Tokens, die auf gleiche Modes reagieren, gruppiert sind. Nicht sinnvoll ist es beispielsweise, Farben und Abstände in einer Sammlung zusammenzufassen, da Farben i.d.R. nicht auf Modes wie »small« und »large« reagieren und Abstände nicht auf »Light Mode« und »Dark Mode«.

Beispiel: Eine Card in Light und Dark Mode

Schauen wir uns eine einfache Card mit Überschrift, Text und Button an. Die »Primitive Tokens« bilden die Palette, die »Semantic Tokens« ordnen die Werte einem Kontext zu.

Primitive Tokens (nur für das Beispiel relevante Angaben)

Semantic Tokens inkl. Modes

Component Tokens

Die Card- und Button-Komponente referenzieren jeweils nur *-surface, *-text und padding. Beim Wechsel zwischen Light und Dark Mode wird kein einziger Wert in der Komponente geändert, sondern nur die Zuordnung der Semantic Tokens zu den Primitives getauscht. Die Spacing-Tokens werden in der semantischen Palette übersprungen, da unser Beispiel keinen Mode für Spacings hat.

Wo »leben« Design Tokens?

In der Praxis kommen Design Tokens an verschiedenen Stellen zum Einsatz. Beispielsweise im Design-Tool und im Code. Daher ist es von zentraler Bedeutung, dass Tokens so organisiert sind, dass die verschiedenen Einsatzbereiche kompatibel sind und leicht aktualisiert werden können. In einem Design-Tool wie Figma werden Tokens beispielsweise als Variablen definiert. Im CSS-Code als CSS-Variablen. Als universelles Austausch-Format ist JSON etabliert und im Webstandard definiert.

Auch stellt sich die Frage nach der Single Source Of Truth (SSOT). Wo werden die Tokens zentral dokumentiert und wer »liest« die Tokens nur aus? In direktem Zusammenhang stehen auch Fragen zu Workflow und Verantwortung im Team: Wird im Design-Tool begonnen, im Code oder gar parallel?

Design First-Workflow

In den meisten Projekten ist das Design-Dokument die zentrale Stelle (SSOT) und definiert alle Variablen. Wenn das Projekt technisch umgesetzt wird, lesen Developer oder KI-Agenten die Variablen aus und übertragen sie auf die Code-Basis. Dieser Prozess ist weitestgehend automatisiert. Die Verantwortung liegt vorrangig im Design-Team.

Code First-Workflow

In Teams, die eine starke Frontend-Affinität aufweisen, ist oft der Code die SSOT. Die Tokens sind folglich im CSS oder JSON definiert und werden dort gepflegt. Wenn sie im Design-Tool benötigt werden, importiert man sie mittels Plugin oder KI (MCP).

Bidirektionaler Workflow (synced)

KI-gestützte und automatisierte Projekte erlauben auch das parallele Arbeiten und sog. bidirektionale Workflows. Sobald ein Token in Code oder Design verändert, gelöscht oder hinzugefügt wird, aktualisieren sich die jeweils andere Stellen automatisch.

Design Tokens im Web

Im Web werden Design Tokens typischerweise als CSS Custom Properties (CSS-Variablen) oder als Sass-Variablen umgesetzt. Das funktioniert Framework-unabhängig und eignet sich damit für kleine wie große Projekte gleichermaßen.

Der CSS-Code des zuvor gezeigten Card-Beispiels:

/* Primitive Tokens */
:root {
  --color-black: #000000;
  --color-white: #FFFFFF;
  --color-gray-100: #eeeeee;
  --color-gray-900: #1A1A2E;
  --color-blue-400: #6699FF;
  --color-blue-600: #0055FF;
  --spacing-2: 0.5em;
  --spacing-4: 1em;
}

/* Semantic Tokens – Light Mode (Default) */
:root {
  --background: var(--color-white);
  --color-surface: var(--color-gray-100);
  --color-on-surface: var(--color-gray-900);
  --color-action: var(--color-blue-600);
  --color-on-action: var(--color-white);
}

/* Semantic Tokens – Dark Mode */
@media (prefers-color-scheme: dark) {
  :root {
    --background: var(--color-black);
    --color-surface: var(--color-gray-900);
    --color-on-surface: var(--color-white);
    --color-action: var(--color-blue-400);
    --color-on-action: var(--color-white);
  }
}

/* Component Tokens */
:root {
  --body: var(--background);
  --card-bg: var(--color-surface);
  --card-text: var(--color-on-surface);
  --card-padding: var(--spacing-4);
  --button-bg: var(--color-action);
  --button-text: var(--color-on-action);
  --button-padding-x: var(--spacing-4);
  --button-padding-y: var(--spacing-2);
}

/* Components */
body {
  background: var(--body);
}

.button {
  background: var(--button-bg);
  color: var(--button-text);
  padding: var(--button-padding-y) var(--button-padding-x);
}

.card {
  background: var(--card-bg);
  color: var(--card-text);
  padding: var(--card-padding);
}

Die Komponenten erhalten keinen einzigen konkreten Styling-Wert. Alles wird über Variablen gesteuert. Beim Wechsel in den Dark Mode tauscht der Browser automatisch die Werte.

Design Tokens als W3C-Standard

Das Problem ohne Standard

Bis 2025 gab es kein einheitliches Format, in dem Design Tokens zwischen Tools ausgetauscht werden konnten. In der Praxis sah das so aus: Designer definierten Tokens in Figma oder einem anderen Design-Tool, Developer konvertierten sie in CSS Variablen. Bei Änderungen wurde der Prozess wiederholt.

Bei kleinen Projekten funktioniert das noch. Es wird aber schnell fehleranfällig, sobald mehrere Plattformen, Themes oder Marken im Spiel sind. Änderungen müssen in jedem Tool einzeln nachgezogen werden, und es gibt keine Garantie, dass die Werte überall identisch sind. Plugins und KI-Agenten haben den Prozess zwar deutlich vereinfacht, aber erst der Webstandard sorgt für einheitliche Prozesse.

Der W3C-Community-Standard

Im Oktober 2025 hat die Design Tokens Community Group (DTCG) die erste stabile Version eines offenen, herstellerneutralen Formats veröffentlicht. Die Spezifikation definiert ein JSON-basiertes Austauschformat, mit dem Tokens zwischen unterschiedlichen Tools kompatibel sind. Zu den ab Start beteiligten Organisationen gehören unter anderem Adobe, Google, Microsoft, Salesforce und Figma.

Ein einfaches Beispiel im W3C-Format (DTCG Standard):

{
  "colors": {
    "blue-600": {
      "$type": "color",
      "$value": {
        "colorSpace": "srgb",
        "components": [0, 0.33, 1],
        "hex": "#0055FF"
      }
    }
  },
  "color-action": {
    "$type": "color",
    "$value": "{colors.blue-600}",
    "$description": "Primary interactive color"
  }
}

Jeder Token hat einen $type (z.B. color, fontFamily, shadow), einen $value und optionale Metadaten wie $description. Tokens können über die Alias-Syntax {token-name} auf andere Tokens verweisen, was dem Prinzip der zuvor beschriebenen Abstraktionsebenen entspricht.

Die Spezifikation besteht aus drei Modulen: Das »Format Module« definiert die Grundstruktur für alle Token-Typen. Das »Color Module« definiert ein differenziertes Farbformat mit Unterstützung moderner Farbräume wie OKLCH und Display P3. Das »Resolver Module« beschreibt, wie kontextabhängige Varianten (Light/Dark, Marken, Gerätegrößen) organisiert werden, ohne Tokens zu duplizieren.

Konvertierung der W3C Tokens in das Ziel-Format

Tools wie Style Dictionary oder Terrazzo lesen Token-Dateien im W3C-Format (DTCG Standard) ein und generieren daraus den gewünschten plattformspezifischen Output. Im Ergebnis stehen dann z.B. CSS-Variablen für das Web oder Swift-Code für iOS zur Verfügung.

Design Tokens in gängigen Tools und Systemen

Die folgenden Systeme gehen Design Tokens unterschiedlich an, weil sie an verschiedenen Stellen des zuvor beschriebenen Workflows zum Einsatz kommen. Figma und Penpot sind Design-Tools, Tailwind CSS und Open Props liegen auf der CSS-Ebene. WordPress bringt als Plattform ein eigenes, vereinfachtes System mit. Anhand von Material Design zeigen wir abschließend, wie ein vollständiges Design System Tokens durchgängig organisiert.

Design Tokens in Figma

Figma hat mit »Variables« ein eigenes Token-System integriert. Variables können in sog. »Collections« organisiert werden und unterstützen pro Collection unterschiedliche »Modes« – also kontextabhängige Varianten wie Light und Dark. Die Variablen verschiedener Collections können sich auch gegenseitig referenzieren, wodurch die zuvor beschriebenen Abstraktionsebenen möglich sind.

Figma unterstützt nativ den Export und Import von Design Tokens im W3C-Format. Über Plugins, die Figma API oder den Figma MCP können Variablen in verschiedenen Formaten exportiert und in die Entwicklungs-Umgebung integriert werden. Auch der umgekehrte Weg ist möglich – wiederum über Plugins oder Schnittstellen. Figma bietet sich somit für unterschiedliche Workflows an: Design First, Code First oder bidirektional.

Gruppierte Tokens (Composite Tokens), die der Webstandard unterstützt, werden in Figma mittels »Styles« abgebildet. Da Styles allerdings nicht zusammen mit Variablen organisiert sind und folglich anders exportiert werden, ist dieses Feature suboptimal umgesetzt.

Design Tokens in Penpot

Penpot, die Open-Source-Alternative zu Figma, ist sehr Frontend-affin und hat Design Tokens tief im Tool verankert und W3C-konform umgesetzt. Anders als bei Figma wird direkt der Standard genutzt und nicht über eine Zwischenebene aus proprietären Variables oder Styles hergestellt, die dann beim Export konvertiert werden.

Ihr könnt in Penpot alle Abstraktionsebenen und zusammengefasste Tokens abbilden und in sog. »Sets« (Collections) sowie »Themes« (Modes) organisieren. Der Export erfolgt als natives W3C-JSON.

Design Tokens in Tailwind CSS

Tailwind CSS ist ein Token-ähnliches System, das in CSS-Variablen und Utility-Klassen überführt wird. Das Framework stellt eine sehr große Anzahl an primitiven Tokens zur Verfügung, deren Werte überschrieben werden können, um individuelle Anpassungen zu erlauben. Neben reinen Tokens wird allerdings auch das Layout-Verhalten auf gleiche Weise gesteuert, was die Organisation verwässert.

Eine vollwertige semantische Ebene mit Modes (z. B. Light/Dark) bietet Tailwind nicht. Einfache Alias-Tokens lassen sich per Referenzierung anlegen, komplexere Setups können durch Custom Code ergänzt werden. Im Markup werden Light-/Dark-Mode, Breakpoint-abhängige Schriftgrößen etc. über sog. »Variants« (dark:, md: …) angesprochen.

Design Tokens in Open Props

Open Props folgt dem Tokens-Prinzip, allerdings nur auf der Ebene der Primitive Tokens. Die CSS-Bibliothek liefert euch eine fertige Sammlung an CSS-Variablen für Farben, Abstände, Schriftgrößen, Schatten oder Animationen, organisiert in Skalen wie --blue-0 bis --blue-12. Eine Semantic- oder Component-Ebene bringt Open Props nicht mit, diese muss selbst gebaut werden.

Open Props-Tokens können im W3C-Format, als Figma-kompatible JSON-Datei und als Style-Dictionary-Tokens exportiert werden, sodass sich die primitive Ebene direkt in andere Tools übernehmen lässt.

Design Tokens in WordPress

WordPress nutzt bei sog. Block Themes ein Token-ähnliches, vereinfachtes System, das in der theme.json organisiert wird. In dieser zentralen Konfigurationsdatei werden Farben, Schriftgrößen und Abstände definiert, die WordPress automatisch in CSS-Variablen konvertiert. WordPress generiert z.B. Variablen wie --wp--preset--color--blue-400, die im Editor auswählbar und im Code referenzierbar sind.

Die theme.json ist kein vollständiges Äquivalent zum W3C-Standard. Es gibt z.B. keine eingebauten Abstraktionsebenen oder Modes. Ob die Tokens in der theme.json eher als Primitive Tokens oder als Semantic Tokens organisiert werden, ist den Theme-Entwicklern freigestellt. Wir haben uns in unserem Design System für WordPress für primitive Tokens entschieden und abstrahieren diese über »Styled Sections« oder »Blocks«.

Design Tokens in populären Designsystemen

Auch öffentlich dokumentierte Designsysteme sind eine gute Quelle, um die zuvor beschriebenen Konzepte an echten Beispielen nachzuvollziehen und zu vergleichen, wie Dinge im Code und im Design gelöst wurden.

• Material Design von Google zeigt die drei Abstraktionsebenen so sauber wie kaum ein anderes System.
• Atlassian hat viel Arbeit in die Benennung von Tokens gesteckt und die Anatomie eines Token-Namens ausführlich dokumentiert. Der Token Picker bietet einen guten Zugang in ein sehr komplexes System.

Fazit

Design Tokens sind das Fundament, auf dem Konsistenz und Wartbarkeit eines digitalen Produkts aufbauen. In kleinen Projekten funktioniert vieles noch ohne durchdachte Struktur. Die Probleme tauchen erst mit steigender Skalierung auf, wenn mehrere Personen zusammenarbeiten müssen, Komponenten, Modes oder Produkte hinzukommen und jede nachträgliche Korrektur teuer wird. Daher empfehlen wir, die Überlegungen zu Abstraktionsebenen, Benennung und Modes früh anzustellen.

Positiv ist die Entwicklung in zwei Bereichen: Mit dem W3C-Standard existiert erstmals ein herstellerneutrales Austauschformat, und KI-Agenten bzw. Automatismen übernehmen zunehmend die Übersetzung zwischen Design-Tool und Code. Beides zusammen wird den Weg von der Design-Entscheidung bis zum fertigen Code in Zukunft deutlich verkürzen.

Die konzeptionellen Entscheidungen, welche Tokens es gibt und wie diese sinnvoll organisiert sind, nimmt euch niemand ab. Und die Verantwortung für Tokens liegt zukünftig wahrscheinlich stärker beim gesamten Team und nicht nur bei einem Gewerk.

Der Beitrag Design Tokens erschien zuerst auf Agentur kulturbanause.

Wir werden regelmäßig gefragt, ob wir Accessibility-Overlays für Websites einsetzen können oder die Nutzung empfehlen. Unsere Antwort ist klar: Nein. Warum wir hierzu eine so klare Haltung haben, fassen wir im Folgenden zusammen.

Was sind Accessibility Overlays und warum werden sie angeboten?

Ein Accessibility Overlay (auch Overlay Tool) ist ein JavaScript-Snippet, das nachträglich auf eine bestehende Website aufgesetzt wird und verspricht, diese automatisch barrierefrei oder zumindest barrierefreier zu machen. In der Regel erscheint ein Icon am Seitenrand, das per Klick einen Dialog öffnet, in dem Anpassungen wie Textgröße, Kontrast oder Animationen gesteuert werden können.

Echte Barrierefreiheit ist aufwändig und der rechtliche Druck wächst. Auf den ersten Blick klingt das Tool eines solchen Anbieters daher verlockend: Es ist schnell eingebunden, soll die Website WCAG-konform machen, rechtliche Risiken minimieren und Menschen mit Behinderungen helfen.

Leider ist das ist nicht der Fall.

Warum wir Overlays nicht einsetzen und davon abraten

Sie bieten keinen gleichwertigen Zugang

Beginnen wir mit einem Punkt, der uns persönlich wichtig ist, auch wenn er nicht direkt in den Anforderungskatalogen abgebildet ist: Wir möchten für alle Menschen einen möglichst gleichwertigen Zugang zu Informationen und Funktionen schaffen. Ein Button, der per Klick Barrieren deaktiviert und nur von den Personen geklickt werden muss, die ohnehin bereits mit höherem Aufwand konfrontiert sind, wird diesem Anspruch nicht gerecht.

Overlays funktionieren technisch nicht zuverlässig

Overlays können fundamentale Barrierefreiheitsprobleme nicht lösen. Fehlerhafte ARIA-Auszeichnung oder schlechte Tastaturnavigation lassen sich nicht per nachträglichem Script heilen. Litz Digital zeigt, dass viele WCAG-Kriterien schlicht nicht automatisiert prüfbar sind.

Sie verschlechtern die Nutzererfahrung für betroffene Menschen

Menschen, die auf Hilfstechnologien angewiesen sind, haben ihren Browser und ihr Gerät bereits individuell konfiguriert. Ein Overlay, das diese Einstellungen überschreibt oder mit ihnen konkurriert, hilft nicht, es schadet. Hinzu kommt ein Performance-Problem: Das zusätzliche JavaScript belastet schwächere Geräte überproportional. Menschen mit Behinderungen sind laut A11y Project statistisch häufiger von wirtschaftlicher Benachteiligung betroffen, nutzen also öfter günstigere Hardware.

Sie bieten keinen rechtlichen Schutz

Overlays werden häufig mit dem Versprechen des Rechtsschutzes verkauft. Worin das begründet sein soll, erschließt sich uns nicht, denn offizielle Stellen raten explizit von der Nutzung ab (s.u.). Laut Litz Digital haben Klagen gegen Websites mit Overlays sogar zugenommen.

Sie sind datenschutzrechtlich problematisch

Das Overlay Fact Sheet weist darauf hin, dass einige Overlays den Einsatz von Hilfstechnologien erkennen und damit den Behinderungsstatus von Menschen ohne deren Einwilligung offenlegen. Manche Anbieter speichern diese Daten sogar seitenübergreifend mittels Cookies.

Sie sind ein Sicherheitsrisiko

Overlays sind Drittanbieter-Scripte mit weitreichendem Zugriff auf die Website. Das A11y Project weist auf ein konkretes Beispiel hin: Das BrowseAloud-Overlay wurde gehackt und missbraucht, um auf tausenden Websites Kryptowährungen zu schürfen. Manche Overlay-Scripte erkennen und deaktivieren außerdem Accessibility-Prüfwerkzeuge wie Axe oder WAVE, was eine unabhängige Qualitätsprüfung aktiv erschwert.

Barrierefreiheit ist ein Prozess

Echte Barrierefreiheit entsteht durch sorgfältige Konzeption, semantisch korrekten Code, kontinuierliche Prüfung und das Einbeziehen von betroffenen Personen. Sie muss von Anfang an mitgedacht und stetig optimiert werden. Sie lässt sich nicht im Nachhinein überbügeln.

Was sagen Fachleute?

Die Einschätzung von Expertinnen, Experten und Prüforganisationen zum Thema »Accessibility Overlay« ist eindeutig:

BIK BITV-Test: Kein Prüfsiegel für Overlay-Seiten

Der BIK BITV-Test – die zentrale deutsche Prüfinstanz für Web-Barrierefreiheit – hat seine Testmethodik angepasst: Websites mit Overlay-Tools erhalten kein BIK-Prüfsiegel. In einem ausführliche Blogbeitrag stellt BIK fest: 

In keinem Fall war ein Overlay in der Lage, eine nicht barrierefreie Seite quasi automatisch WCAG- bzw. BITV-konform zu machen.

BFIT-Bund: Keine Rechtskonformität

Auch die Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik ist unmissverständlich: Overlay-Tools machen eine nicht barrierefreie Website nicht automatisch gesetzeskonform. Der Ausschuss für barrierefreie Informationstechnik stellt fest, dass nur ein kleiner Teil der über 100 Barrierefreiheits-Anforderungen automatisiert prüfbar ist – und noch weniger automatisiert behebbar.

Der Ausschuss weist darauf hin, dass Webauftritte öffentlicher Stellen nur barrierefrei sind, wenn sie die sich aus der Richtlinie (EU) 2016/2102 ergebenden Anforderungen zur Barrierefreiheit auch ohne die Verwendung von Overlay-Tools erfüllen.

EU-Kommission: Overlays sind keine angemessene Lösung

Die Europäische Kommission hat auf ihrer offiziellen Seite zur Web-Barrierefreiheit einen eigenen Abschnitt zu Overlay Tools veröffentlicht und schreibt: 

Overlays, or any other tools which do not ensure the website itself meets the detailed criteria of the standard, are not an appropriate solution. […] It is best to fix accessibility issues at their source.

Das Europäische Behinderungsforum sowie Menschen mit Behinderungen und Accessibility-Fachleute haben demnach ausdrücklich Bedenken gegenüber dem Einsatz von Overlays geäußert.

Die internationale Fachgemeinschaft

Eine WebAIM-Umfrage ergab, dass 67 % der Accessibility-Fachleute Overlays als »gar nicht« oder »kaum« effektiv beurteilen. Unter Menschen mit Behinderungen steigt dieser Wert auf 72 %.

Das Overlay Fact Sheet – unterzeichnet von über 1000 Accessibility-Profis weltweit – bringt es auf den Punkt:

Es ist ein Irrtum zu glauben, dass die vom Overlay-Widget bereitgestellten Funktionen einen nennenswerten Zusatznutzen liefern, denn wenn diese Funktionen notwendig für die Nutzung der Website wären, würden sie für alle Websites benötigt, mit denen der Nutzer interagiert. Stattdessen ist das Widget – bestenfalls – eine redundante Funktionalität zu dem, was der Benutzer bereits hat.

Der Beitrag Accessibility Overlays & Overlay Tools – unsere Haltung dazu bei kulturbanause erschien zuerst auf Agentur kulturbanause.

Ab WordPress 7.0 lassen sich eigene Blöcke vollständig in PHP entwickeln. Bisher war dafür zwingend JavaScript notwendig. Mit der neuen Option autoRegister entfällt das. WordPress übernimmt die Editor-Integration automatisch.

Was ist »autoRegister«?

autoRegister ist eine neue Option im supports-Array, die mit WordPress 7.0 eingeführt wurde. Das supports-Array ist Bestandteil von register_block_type() und legt fest, welche Editor-Funktionen ein Block unterstützt, wie z.B. Farb- oder Abstandsoptionen. Ist autoRegister aktiv, registriert WordPress den Block selbstständig im Editor.

Block erstellen: Schritt für Schritt

Ein PHP-only Block kann folgendermaßen aufgebaut werden:

1. Block-CSS mit wp_register_style() registrieren
2. Block via register_block_type() registrieren und Titel, Beschreibung, Kategorie, Attribute und Supports direkt als PHP-Array übergeben
3. Im supports-Array autoRegister auf true setzen
4. Einen render_callback schreiben (eine PHP-Funktion, die das HTML des Blocks für das Frontend erzeugt)
5. get_block_wrapper_attributes() verwenden (eine WordPress-Funktion, die alle notwendigen HTML-Attribute wie Klassen und Inline-Styles aus den Block Supports automatisch generiert)

In folgendem Beispiel erzeugen wir einen einfachen PHP-Block als Plugin. Der Block heißt »Info-Block« und gibt einen kurzen Text im Frontend aus. Über die Sidebar des Block-Editors lässt sich der Text bearbeiten sowie Schrift- und Hintergrundfarbe anpassen – alles ohne eine einzige Zeile JavaScript.

<?php
/*
Plugin Name: Info-Block (PHP-Only Block)
Description: Integration des PHP-Only Info-Blocks ab WordPress 7.0
*/

function kb_info_block_register_block() {

    // Schritt 1: CSS registrieren
    wp_register_style(
        'kb-info-block-style',
        plugin_dir_url( __FILE__ ) . 'style.css'
    );

    // Schritte 2 & 3: Block registrieren und autoRegister aktivieren
    register_block_type( 'pluginname/info-block', [
        'title'    => 'Info-Block',
        'category' => 'text',
        'style'    => 'kb-info-block-style',
        'attributes' => [
            'text' => [
                'type'    => 'string',
                'label'   => 'Text',
                'default' => '',
            ],
        ],
        'supports' => [
            'autoRegister' => true,
            'color' => [
                'text'       => true,
                'background' => true,
            ],
        ],
        'render_callback' => 'kb_info_block_render_block',
    ] );
}
add_action( 'init', 'kb_info_block_register_block' );

// Schritte 4 & 5: render_callback mit get_block_wrapper_attributes()
function kb_info_block_render_block( $attributes ) {
    $wrapper = get_block_wrapper_attributes();
    $text    = esc_html( $attributes['text'] ?? '' );

    return "<div {$wrapper}>{$text}</div>";
}

Das Plugin besteht aus zwei Dateien: der PHP-Hauptdatei (z. B. info-block.php) mit der Block-Registrierung und einer style.css im selben Ordner für das Styling. Der Plugin-Ordner wird wie üblich unter wp-content/plugins/ abgelegt.

Einstellungen (Block Controls) für PHP-Blöcke festlegen

WordPress generiert automatisch die passenden Eingabefelder und Styling-Optionen in der rechten Seitenleiste, sobald bestimmte Attribute korrekt definiert sind. Eigene, JavaScript-basierte, Eingabefelder (Inspector Controls) lassen sich mit PHP-only Blöcken nicht umsetzen. Für viele Anwendungsfälle wird das auch nicht benötigt.

Input-Typen über Attribute steuern

Erhält ein Attribut einen label-Key, erzeugt WordPress daraus selbstständig ein passendes Eingabefeld in der Sidebar. Der Typ des Attributs bestimmt dabei, welches Control erscheint:

• string → Texteingabe (TextControl)
• integer oder number → Zahleneingabe (NumberControl)
• boolean → Umschalter (ToggleControl)
• string kombiniert mit enum → Auswahlmenü (SelectControl)

Styling-Optionen mittels Block Supports steuern

Block Supports sind vordefinierte WordPress-Funktionen wie Farb-, Abstands- oder Typografie-Optionen. Sie lassen sich direkt im supports-Array aktivieren, wodurch WordPress die entsprechenden Sidebar-Panels automatisch rendert.

Wann sind PHP-only Blöcke sinnvoll?

PHP-only Blöcke eignen sich besonders für einfache Ausgabe-Blöcke ohne komplexe Interaktion im WordPress-Editor. Sobald ein Block aufwändige Editor-Interaktion benötigt, z.B. verschachtelte Blöcke Media-Uploads oder eine eigene Live-Vorschau, kommt man um JavaScript nicht herum. Für alle anderen Fälle ist der PHP-Block oft die schlankere und wartungsärmere Lösung.

PHP-Blöcke mit Claude Code entwickeln

Claude Code lässt sich durch Skills erweitern. Der folgende Skill php-block (nicht offiziell von WordPress) versorgt Claude mit den Konventionen des Projekts, sodass generierter Code den Standards entspricht. Eine Einführung in das Thema bietet dieses Video-Tutorial.

Der Beitrag WordPress: PHP-only Blöcke mit autoRegister erschien zuerst auf Agentur kulturbanause.

Video

Vom Wasserfall zum iterativen Prozess

Jahrelang war der typische Weg zwischen Design und Code eine Einbahnstraße: Im Design-Tool entstand ein Entwurf, Entwicklerinnen und Entwickler übertrugen ihn in Code. MCP-Integrationen haben diesen Transfer zuletzt automatisiert – aber die Richtung blieb meist dieselbe – wenn es auch bereits seit Jahren Gegentrends gab. Mit »Code to Canvas« dreht Figma diesen Prozess nun konsequent um. Eine fertig umgesetzte Benutzeroberfläche im Browser, bestehend aus HTML, CSS und JavaScript, wird dabei automatisch auf die Figma-Arbeitsoberfläche übertragen.

Ein Figma-Plugin für Claude Code

Im Zuge einer Kooperation zwischen Figma und Anthropic, dem Hersteller von Claude, ist ein offizielles Plugin entstanden, das die Integration deutlich vereinfacht. Statt den Figma-MCP-Server manuell einzurichten und Skills separat herunterzuladen, liefert das Plugin beides als Bundle. Die Installation erfolgt über das Terminal im jeweiligen Projektordner mit einem einzigen Befehl.

Nach der Installation und einem Neustart von Claude Code erscheint das Figma-Plugin als »Built-in MCP«. Wer bereits die klassischen Figma-MCP-Integration eingerichtet hat, kann diese weiternutzen.

Vom Browser in die Figma-Datei

Der Transfer vom Browser in den Code läuft über einen Prompt in Claude Code. Dieser enthält zwei Informationen: die localhost-URL der laufenden Web-App und den Link zur Zieldatei in Figma. Ein einfacher Satz wie »Implementiere dieses Design (localhost-URL) in diese Figma-Datei (Figma-URL)« genügt.

Claude Code greift automatisch auf den passenden Figma-Skill zurück und analysiert die Figma-Datei und die HTML-Quelle. Für den Prozess wird ein kleines JavaScript-Snippet temporär in die HTML-Datei eingefügt. Dieses Script ermöglicht Figma, einen visuellen Snapshot der Seite zu erstellen, und aktiviert zusätzlich eine interaktive Toolbar im Browser, mit der ihr auch einzelne Elemente zur selektiven Übertragung auswählen könnt.

Das Ergebnis in Figma ist überzeugend: Die Elemente erscheinen mit korrekten Abmessungen und Auto-Layout-Interpretation so, wie sie im Code definiert wurden.

Bidirektional: Änderungen aus Figma zurück in den Code

Der wirklich interessante Teil des Features liegt im bidirektionalen Workflow. Figma verfolgt das Ziel, die strikte Trennlinie zwischen Design und Entwicklung aufzuweichen. Änderungen sollen nicht nur von Design zu Code fließen, sondern auch in die umgekehrte Richtung.

In der Praxis funktioniert das so: Ein Element in Figma wird bearbeitet, anschließend genügt ein kurzer Prompt wie »Ziehe die Designänderungen im Code nach«, damit der Agent die Figma-Datei ausliest, die Änderung identifiziert und den Code aktualisiert. Das Resultat ist unmittelbar im Browser sichtbar.

Der Grundstein ist gelegt

Code to Canvas ist ein wichtiger und überzeugender erster Schritt. Was in vielen Fällen Drittanbieter-Plugins wie HTML to Design ermöglichten, ist jetzt zumindest in Anfängen nativ in Figma verfügbar und tief mit KI-gestützten Coding-Tools wie Claude Code verzahnt.

Der bidirektionale Ansatz beschreibt allerdings letztlich einen Workflow, den Designer mit Coding-Kenntnissen schon immer intuitiv genutzt haben. Das dauerhafte Wechseln zwischen Design-Tool und Code-Editor um Änderungen in beide Richtungen zu übertragen. Neu ist, dass diese Übergänge jetzt durch KI und MCP-Integrationen automatisiert werden und somit auch für Teams ohne tiefes Coding-Wissen zugänglich werden.

Der Beitrag Figma »Code to Canvas« und bidirektionale Workflows mit Claude erschien zuerst auf Agentur kulturbanause.

Video

Video anschauen

Was der Dev Mode an Layout-Informationen ausgibt

Wer im Dev Mode ein Element anklickt, das sauber mit Auto Layout aufgebaut wurde, erhält auf einen Blick alle relevanten CSS-Eigenschaften: Padding-Werte, Gap zwischen den Kind-Elementen sowie das grundlegende Layout-Verhalten – also ob es sich um eine Flexbox oder ein Grid handelt.

Ein Beispiel: Ein Header-Element mit Logo links und Button rechts zeigt im Dev Mode justify-content: space-between und align-items: center – genau das, was der Abstand »Auto« im Design-Mode bedeutet. Padding-Werte erscheinen farblich hervorgehoben (blau für Padding, rot schraffiert für Gap), was die Übersicht weiter erleichtert.

Diese Ausgabe funktioniert aber nur, wenn das Element im Design-Mode tatsächlich mit Auto Layout gebaut wurde. Ohne diese Vorbereitung liefert Dev Mode keine Layout-Eigenschaften – nur feste Breiten- und Höhenangaben.

Auto Layout: Die Abstraktion von Flexbox und Grid

Auto Layout ist Figmas abstrahierte Umsetzung von CSS-Layoutmechanismen wie Flexbox und Grid. Es erlaubt Designerinnen und Designern, Elemente so zu strukturieren, dass sie ähnlich wie im Browser reagieren – responsiv, abstandsbasiert, hierarchisch verschachtelt.

Der Unterschied zu einem klassischen Design-Tool wie Illustrator: Dort werden Elemente einfach positioniert – ein Rechteck hier, ein Text daneben. In Figma mit Auto Layout dagegen definiert man Innenabstände (Padding) und Abstände zwischen Elementen (Gap) explizit, und die Breite eines Elements ergibt sich automatisch aus Inhalt plus Padding. Das entspricht dem intrinsischen Verhalten im Web.

Sobald mehrere Elemente gemeinsam reagieren sollen – etwa zwei Buttons nebeneinander – werden sie in ein Eltern-Element verpackt, das ebenfalls Auto Layout erhält. So entsteht eine verschachtelte Hierarchie, die der DOM-Struktur im Browser sehr ähnelt.

Ohne Auto Layout fehlt etwas

Wird ein Element ohne Auto Layout gebaut – also nur als gezeichnetes Rechteck mit Text darüber –, sieht man im Dev Mode kein Padding, keinen Gap, keine Flexbox-Eigenschaften. Entwicklerinnen und Entwickler müssen sich die Abstände dann manuell ablesen oder schätzen.

Das ist nicht nur ineffizient, es führt auch zu Fehlern und Missverständnissen im Handoff. Eine Datei, die so aufgebaut ist, hat klaren Nachbesserungsbedarf. Die Mindestanforderung sollte sein: einheitliche Abstände, eine Spacing-Hierarchie, und konsequente Nutzung von Auto Layout für alle strukturierten Elemente.

Layout-Variablen für konsistente Abstands-Tokens

Noch aussagekräftiger wird der Dev Mode, wenn Layout-Informationen nicht als fester Wert, sondern als Variablen vergeben werden. Dazu legt man in Figma eine eigene Variable-Collection für Layout an – etwa mit Zahlenwerten wie »size-1 = 8px« und »size-2 = 12px«.

Diese Variablen werden dann bei Padding- und Gap-Werten der Elemente eingesetzt. Im Dev Mode erscheinen anschließend nicht mehr nur Pixelwerte, sondern die zugehörigen Token-Namen – also zum Beispiel »space-4« statt »24px«. Das ermöglicht es, Design-Tokens direkt im Code mit Komponentenwerten zu verknüpfen, was den Handoff erheblich beschleunigt.

In gut organisierten Design-Systemen gibt es dafür eine eigene Spacing- oder Responsive-Collection, in der alle Abstandswerte zentral definiert und von dort aus im gesamten Design referenziert werden.

Flexbox mit Wrap und Grid in Figma

Auto Layout unterstützt nicht nur einfache horizontale oder vertikale Flexbox-Layouts. Wird die Option »Wrap« aktiviert, erhält das Layout sowohl einen horizontalen als auch einen vertikalen Gap – und der Dev Mode gibt entsprechend flex-wrap: wrap aus.

Für Grid-Layouts gibt es in Figma (aktuell noch in der Beta) eine eigene Grid-Option in Auto Layout. Dort lässt sich die Spalten- und Zeilenstruktur definieren, Elemente können frei im Raster positioniert werden, und einzelne Spalten können feste oder dynamische Breiten erhalten – etwa »1fr« oder »200px«.

Im Dev Mode erscheint dann kein Flexbox-Code, sondern ein CSS Grid mit grid-template-columns und den entsprechenden Zeilendefinitionen.

Min- und Max-Breiten für responsives Verhalten

Responsives Design bedeutet mehr als nur flexible Breiten. Oft benötigt man Mindest- und Höchstbreiten, damit ein Element nicht zu klein oder zu groß wird. In Figma lassen sich bei der Breitendefinition eines Elements zusätzlich min-width und max-width festlegen – zum Beispiel »minimal 320px« (Smartphone-Breite) und »maximal 500px«.

Wurden diese Werte im Design-Mode hinterlegt, erscheinen sie auch im Dev Mode – umgerechnet in rem-Werte (sofern so konfiguriert) und direkt als min-width und max-width ausgewiesen. Das macht die Umsetzung im CSS deutlich eindeutiger und reduziert Rückfragen zwischen Design und Entwicklung.

Der Beitrag Figma Dev Mode: Layout Informationen auslesen – von Auto Layout zu Flexbox und Grid erschien zuerst auf Agentur kulturbanause.

Video

Video anschauen

Das Problem: Interpretation statt Production Code

Wenn Entwickler im Figma Dev Mode eine Komponente inspizieren, zeigt Figma eine Code-Interpretation an – einen automatisch generierten Vorschlag, wie die Komponente umgesetzt werden könnte. Dasselbe passiert beim agentischen Coden: Die KI erfindet den Code jedes Mal neu, basierend auf der visuellen Darstellung.

In vielen Organisationen existiert jedoch bereits eine getestete, produktionsreife Code-Bibliothek mit fertigen Komponenten. Der automatisch generierte Code von Figma ist in solchen Fällen bestenfalls ein Näherungswert – im schlimmsten Fall führt er zu Inkonsistenzen und Mehraufwand.

Code Connect: Die Brücke zwischen Design und Code

Figma bietet mit »Code Connect« ein Feature, das genau dieses Problem löst. Es stellt eine direkte Verbindung zwischen UI-Komponenten in der Figma-Library und den dazugehörigen Code-Dateien in einem Repository her. Sobald diese Verbindung besteht, sehen Entwickler im Dev Mode nicht mehr Figmas Interpretation, sondern den tatsächlichen Code ihrer Organisation.

Voraussetzung ist eine Organisation- oder Enterprise-Lizenz von Figma. Das Feature ist in den unteren Lizenzmodellen nicht verfügbar.

Einrichtung über die Benutzeroberfläche

Die Verknüpfung erfolgt im Dev Mode über den Menüpunkt »Library → Connect Components to Code«. Figma zeigt eine Liste aller Komponenten der aktuellen Bibliothek an. Für jede Komponente kann eine URL zur entsprechenden Code-Datei in einem Repository hinterlegt werden.

Besonders komfortabel wird es mit einer GitHub-Verbindung: Figma erkennt dann die Repository-Struktur und ermöglicht eine direktere Auswahl der passenden Dateien. Grundsätzlich funktioniert das Feature aber auch mit beliebigen URLs, die nicht auf GitHub liegen.

Sobald die Verbindung hergestellt ist, wird die Komponente in der Übersicht als „connected“ markiert und im Dev Mode erscheint der Verweis auf die verknüpfte Code-Datei.

KI-Instruktionen für gezielte Steuerung

Ein besonders nützliches Feature ist die Möglichkeit, pro Verbindung zusätzliche Anweisungen für KI-Tools zu hinterlegen. Diese »Instructions« werden gelesen, wenn eine KI die Komponente umsetzen soll. So lässt sich sicherstellen, dass KI-gestützte Workflows nicht blind arbeiten, sondern kontextbewusst agieren.

Integration mit KI-Coding-Tools

Über das Model Context Protocol (MCP) können KI-Tools wie Claude Code auf den Figma-Kontext zugreifen. In der Praxis bedeutet das: Man kopiert den Link zu einer Figma-Komponente, gibt Claude Code & Co. den Auftrag, diese Komponente zu bauen, und das Tool liest automatisch den hinterlegten Code sowie die Instructions aus.

Die KI greift dann nicht auf eine neue Interpretation zurück, sondern nutzt den tatsächlichen Production-Ready-Code als Basis – ergänzt um die spezifischen Anweisungen, die für diese Komponente hinterlegt wurden.

Der Beitrag Figma Code Connect UI: Komponenten mit »Production Ready« Code verknüpfen erschien zuerst auf Agentur kulturbanause.

Video

Link zum Video

Was ist das Original?

Im klassischen Workflow zwischen Design und Entwicklung steht das Design am Anfang. UX/UI-Teams gestalten Oberflächen und Komponenten in Tools wie Figma, und anschließend wird das Ergebnis in Code übertragen – ob manuell durch Entwickler oder automatisiert durch KI. Änderungen werden zuerst im Design umgesetzt und danach im Code nachgezogen.

Dieses Vorgehen hat einen grundlegenden Nachteil: Was in Figma als einzelne Komponente existiert – etwa ein Button – wird in der Praxis in verschiedenen Umgebungen gerendert. Unterschiedliche Browser, verschiedene Zieltechnologien wie HTML und React, und diverse Rendering-Engines führen dazu, dass aus einem einzigen Design-Original eine multidimensionale Code-Darstellung entsteht. Die Single Source of Truth im Design wird durch die Vielfalt der Implementierungen aufgeweicht.

Code als Single Source of Truth

Die Alternative besteht darin, den Workflow umzudrehen. Statt im Design zu starten und den Code abzuleiten, wird der Code selbst zum Original. Änderungen finden direkt in der Code-Basis statt, und das Design-Tool – in diesem Fall Figma – dient als Darstellungsoberfläche, um mit den UI-Komponenten im Kontext von Prototypen und Iterationen arbeiten zu können.

Dieser Ansatz ist besonders dann sinnvoll, wenn bereits ein ausgereiftes Design-System als Code-Bibliothek vorliegt, beispielsweise in einem Storybook oder einer browserbasierten Komponentendokumentation. Statt die Bibliothek in Figma von Grund auf aufzubauen und anschließend an den Code zu übertragen, kommt man von der Code-Seite und importiert die Komponenten zurück in die visuelle Umgebung.

HTML to Design: Das Figma-Plugin für den Import

Das Figma-Plugin HTML to Design ermöglicht genau diesen Weg. Es ist im Design-Modus verfügbar (nicht im Dev Mode) und bietet in der kostenlosen Version etwa 10 Importe pro Monat. Es gibt zwei Hauptwege für den Import: Die direkte Eingabe einer URL, um eine komplette Seite zu importieren, oder die Nutzung einer Chrome-Extension, mit der gezielt einzelne Bereiche einer Live-Website ausgewählt und an Figma gesendet werden können.

Die Chrome-Extension funktioniert ähnlich wie die Browser-DevTools: Man wählt auf der gewünschten Website den gewünschten Bereich aus – etwa eine Navigationsleiste – und sendet ihn direkt an das Plugin in Figma. Dort stehen verschiedene Import-Optionen zur Verfügung, etwa ob Auto Layout verwendet werden soll oder wie mit Schriften umgegangen wird.

Was das Plugin erkennt und umsetzt

Beim Import interpretiert das Plugin die Code-Struktur intelligent. Flexbox-Layouts werden automatisch als Auto Layouts erkannt, Container-Strukturen und Verschachtelungen werden beibehalten. Das Ergebnis ist ein Figma-Frame, der die tatsächliche Code-Architektur widerspiegelt – mit korrekten Hierarchien, Abständen und Layout-Eigenschaften.

Falls verwendete Schriftarten lokal nicht verfügbar sind, bietet das Plugin einen automatischen Ersatz an, etwa durch Helvetica. So entsteht ein arbeitsfähiges Figma-Element, das als Ausgangspunkt für weitere Design-Arbeit, Prototypen oder Iterationen dienen kann.

Der Beitrag Figma HTML to Design: Wenn der Code zur Single Source of Truth wird erschien zuerst auf Agentur kulturbanause.

Video

Link zum Video

Pixelgrafiken (PNG, JPG) aus Figma exportieren

Beim Umsetzen von Designs müssen regelmäßig Grafiken exportiert werden – von Hintergrundbildern über Logos bis hin zu Icons. Figma bietet dafür im Dev Mode mehrere Wege an, die je nach Anwendungsfall unterschiedlich effizient sind.

Für den Export als Pixelgrafik (PNG, JPG) muss das zu exportierende Element in einem Frame liegen. Frames sind in der Ebenenpalette am Rauten-Symbol erkennbar. Nach Auswahl des Frames erscheint rechts unten die Export-Funktion mit Einstellungen für Format, Auflösung (1x, 2x, 3x) und Farbprofil (sRGB, Display P3). Eine Vorschau zeigt das Ergebnis vor dem Download. Moderne Bildformate wie WebP oder AVIF werden aktuell noch nicht nativ unterstützt, können aber über Plugins ergänzt werden.

SVG exportieren

In der Praxis dominiert der SVG-Export, insbesondere für Icons, Logos und grafische Formen. Figma erkennt innerhalb einer Auswahl automatisch enthaltene Assets – ein Icon innerhalb eines Buttons wird als eigenständiges Element identifiziert und kann separat heruntergeladen werden. Bei Vektorformen zeigt die rechte Seitenleiste einen SVG-Abschnitt mit dem vollständigen Quellcode.

Der effizienteste Workflow für SVGs die im Code eingefügt werden sollen: Per Rechtsklick auf das Element und »Copy as SVG« den Code direkt in die Zwischenablage kopieren. Anschließend lässt sich der Code in einem Optimierungstool wie SVG Viewer einfügen, dort auf Korrektheit prüfen und in der Dateigröße reduzieren. Das optimierte SVG wird dann direkt in die Codebasis übernommen – ohne den Umweg über eine gespeicherte Datei. Alternativ steht der SVG-Code auch in der rechten Seitenleiste zum Kopieren bereit. Verschachtelte Komponenten – etwa ein Button, der ein Icon als eigene Instanz enthält – lassen sich durch Klicken auf die tiefere Ebene einzeln inspizieren. So kann das Icon isoliert exportiert werden.

Der Beitrag Figma Dev Mode: Grafiken und SVGs exportieren erschien zuerst auf Agentur kulturbanause.

Video

Link zum Video

Eine Datei oder mehrere?

Solange ein Projekt überschaubar ist und alle Designs in einer einzigen Datei leben, müssen Komponenten und Styles nicht zwingend als Bibliothek veröffentlicht werden. Erst wenn mehrere Projektdateien auf dieselben globalen Assets zugreifen sollen, lohnt sich der Schritt zur geteilten Bibliothek. In der Praxis ist das allerdings üblich.

Das Veröffentlichen erfolgt über den Bereich Assets → Bibliotheken. Bei größeren Designsystemen mit über 1000 Komponenten kann dieser Vorgang durchaus mehrere Minuten dauern.

Verknüpfte Bibliotheken im Dev Mode

Sobald eine Bibliothek veröffentlicht und in einer Projektdatei verknüpft ist, können Komponenten aus der Bibliothek ganz normal eingesetzt werden. Im Dev Mode fällt dann jedoch ein kleiner, aber wichtiger Unterschied auf:

• Befindet sich die Hauptkomponente in derselben Datei, zeigt Figma in der Seitenleiste schlicht »Component instance« an.
• Stammt die Komponente aus einer externen Bibliothek, erscheint ein abweichendes Icon und ein Hinweis, dass das Original in einer anderen Datei liegt. Zusätzlich wird der Name der Quelldatei in Klammern angezeigt, zum Beispiel: »Component instance (Simple Design System)«.

Mit einem Klick auf dieses Icon springt man direkt in die Originaldatei und genau an die Stelle, wo die Komponente erstellt wurde. Voraussetzung ist natürlich, dass man Zugriff auf diese Datei hat. Fehlt der Zugriff, erscheint eine entsprechende Meldung.

Bibliotheks-Updates und Änderungen

Hat jemand eine Instanz lokal angepasst – etwa den Text geändert –, zeigt der Dev Mode das transparent an: Es wird darauf hingewiesen, dass Text oder Layout vom Original abweichen. Über eine Vergleichsansicht lässt sich genau nachvollziehen, was geändert wurde.

Wenn in der Hauptbibliothek Änderungen vorgenommen werden, können diese als Update in den Projektdateien eingespielt werden. Dabei sollte man im Hinterkopf behalten, dass eine scheinbar kleine Änderung weitreichende Folgen haben kann: Da Komponenten im Atomic Design oft ineinander verschachtelt sind, kann eine einzelne Anpassung Dutzende abhängige Komponenten betreffen.

Das Update selbst kann global oder selektiv für einzelne Instanzen eingespielt werden. Hier liegt jedoch eine wichtige Einschränkung des beschriebenen Workflows: Wurde ein Update nur für einzelne Instanzen eingespielt, ist der veraltete Stand anderer Instanzen im Dev Mode nicht leicht erkennbar.

Der Beitrag Figma-Bibliotheken: Struktur, Updates und Dev-Mode-Besonderheiten erschien zuerst auf Agentur kulturbanause.