Der KI-Design-System-Workflow, der endlich professionelle Ergebnisse liefert

Der KI-Design-System-Workflow, der endlich professionelle Ergebnisse liefert

Ich habe den Großteil eines Samstags damit verbracht, mit Claude über einen Button zu streiten.

Nicht über die Logik. Den Button. Den primären Call-to-Action auf einem Paywall-Screen für eine Finanz-App, die ich prototypisierte. Ich hatte das Figma MCP eingerichtet, Claude auf mein Designsystem angesetzt, „bau mir eine Paywall mit unseren Komponenten“ getippt – und das Ergebnis sah aus wie jeder andere KI-generierte Screen, den ich je gesehen habe. Abgerundete Ecken, die willkürlich wirkten. Ein Farbverlauf, der nirgendwo in meinem System existierte. Abstände, die fast stimmten, so wie eine Coverband fast wie das Original klingt. Nah genug, um es zu erkennen. Weit genug entfernt, um weh zu tun.

Ich schloss die Datei. Machte mir einen Kaffee. Setzte mich hin und las tatsächlich, was ich da eigentlich gemacht hatte.

Dabei wurde mir klar: Ich hatte Claude wie einen Zauberstab behandelt. Draufhalten auf eine Figma-Datei, pixelgenaues Ergebnis erwarten. Und Claude tat still und leise genau das, was jedes Modell macht, wenn man ihm einen Haufen unbeschrifteter Daten gibt – mitteln. Meine Tokens wurden mit allen anderen Designsystemen, die es je gesehen hatte, gemittelt. Meine Buttons mit jedem Button im Internet verglichen. Das Resultat war ein Geist meines Designsystems, der ein überzeugendes Kostüm trug.

Die Lösung war kein besserer Prompt. Die Lösung waren strukturierte Trainingsdaten – Tokens mit Beschreibungen, Komponenten gruppiert mit Nutzungsregeln, konkrete Beispiel-Screens – und dann lokale Iteration in Claude Code, bevor auch nur ein Frame nach Figma geschoben wurde. Sobald ich das gemacht hatte, ging mein erster UI-Entwurf von „okay, das baue ich komplett neu“ zu „eigentlich muss ich nur zwei Textstile anpassen“.

Genau diesen Workflow möchte ich dir zeigen. Nichts Revolutionäres. Einfach langweilige, geduldige Struktur, die Claude dazu bringt, sich wie ein Junior-Designer zu verhalten, der dein System tatsächlich gelesen hat – und nicht wie ein betrunkener Tourist, der mal von Design gehört hat.

Warum Vanilla Figma AI und „Just Prompt It“-Workflows scheitern

Lassen Sie mich das Scheitern ganz genau beschreiben, denn die meisten Artikel überspringen diesen Teil.

Sie installieren den Figma MCP-Server. Sie verbinden Claude mit Ihrer Figma-Datei. Sie schreiben „Erstelle einen Einstellungsbildschirm mit unserem Designsystem.“ Claude legt los, liest ein paar Metadaten, produziert etwas. Sie öffnen es. Es ist auf eine schwer zu benennende Weise falsch – die Hierarchie fühlt sich unstimmig an, das Padding ist das falsche 16 (das 16, das in jedem System existiert, nicht das, das Sie verwenden), der Kartenschatten ist nah dran, aber eben nicht Ihr Schatten. Technisch verwendet es Ihre Komponenten. Es versteht nur nicht, wann sie zu verwenden sind.

Das passiert aus einem Grund, der offensichtlich ist, sobald man ihn benennt: Eine Designsystem-Datei ist kein Trainingsdatensatz. Eine Designsystem-Datei ist ein Lagerhaus. Tokens liegen in einer Sammlung. Komponenten in einer anderen. Nutzungsregeln stehen in einem Notion-Dokument, das niemand liest. Der Klebstoff – das eigentliche Wissen darüber, „wann verwenden wir die erhöhte Oberfläche und wann die angehobene“ – existiert nur im Kopf Ihres Senior Designers.

Wenn Claude dieses Lagerhaus liest, sieht es Namen und Werte. Es sieht keine Intention. Und ohne Intention wird jede mehrdeutige Entscheidung durch statistisches Mittelmaß gegen alles, was es je im Internet gesehen hat, aufgelöst. So landen Sie bei einer Paywall, die irgendwie nach Stripe aussieht, irgendwie nach Linear, aber überhaupt nicht nach Ihrer App.

Figma selbst ist in dieser Frage eigentlich ziemlich klar – sie haben einen Leitfaden zum Erstellen eigener Skills genau aus diesem Grund veröffentlicht. Der MCP-Server wird mit grundlegenden Skills wie figma-use und figma-generate-library ausgeliefert, aber das ist nur das Gerüst. Sie erwarten, dass Sie Ihr eigenes Domänenwissen darüberlegen. Die meisten tun das nicht. Dann geben sie dem Modell die Schuld.

Ich habe dem Modell auch die Schuld gegeben. Dann habe ich aufgehört.

Es gibt noch ein drittes Problem, das die meisten Tutorials ausklammern – darauf kommen wir später im Implementierungsteil zurück. Es geht darum, was passiert, wenn ein Modell drei Varianten einer „Card“-Komponente sieht und eine auswählen muss. Ich zeige Ihnen, wie das aussieht und wie Sie es beheben. Aber zuerst brauchen wir Tokens, die sprechen.

Tokens, die sprechen: Die Vorlage, die alles veränderte

Hier kommt der größte Durchbruch in diesem gesamten Workflow – und er ist peinlich einfach.

Claude ist ein Sprachmodell. Deine Tokens bestehen größtenteils aus Zahlen und Hex-Codes. Wenn du einem Sprachmodell nicht-sprachlichen Input gibst, muss es die Bedeutung erraten. Gibst du ihm sprachlichen Input, folgt es Anweisungen. Die Lösung ist also, deine Tokens Englisch sprechen zu lassen.

Ich verwende für jeden einzelnen Token eine Vier-Spalten-Vorlage: Name. Light-Wert. Dark-Wert. Ein Satz, wann er verwendet werden soll.

Hier ist ein Ausschnitt meiner tatsächlichen Surface-Tokens:

| Token                  | Light    | Dark     | When to use                                      |
|------------------------|----------|----------|--------------------------------------------------|
| surface-base           | #FFFFFF  | #0B0B0F  | The page background. Nothing sits behind this.   |
| surface-raised         | #F7F7F9  | #15151B  | Cards, list rows, anything one layer above base. |
| surface-elevated       | #FFFFFF  | #1D1D25  | Modals, popovers, menus — floating UI only.      |
| surface-sunken         | #F0F0F3  | #08080C  | Input fields, inset wells, read-only regions.    |
| surface-brand-subtle   | #EEF2FF  | #1A1D3A  | Brand-tinted backgrounds for promoted content.   |

Lies dir die Spalte „When to use“ durch. Das ist der Teil, der für Claude zählt. Das ist der Teil, der einen Token von einem Wert in eine Anweisung verwandelt.

Mach das für jede Token-Kategorie – Surface, Content (Text), Border, Action, Status, Elevation, Radius, Spacing, Motion. Ja, auch Spacing. space-2: 8px — tight rhythm inside dense components like form field groups ist tausendmal hilfreicher als space-2: 8px.

Das entspricht genau dem, worauf sich die Design-System-Community 2026 geeinigt hat – semantische Tokens mit Intent im Namen, kombiniert mit Dokumentation, die den Zweck beschreibt, nicht das Aussehen. Mein Twist: Die Dokumentation muss mit dem Token im von Claude verarbeitbaren Format leben, nicht in einem separaten Wiki.

Speichere diese Tabelle als Markdown-Datei. design-tokens.md. Lege sie in dein Projekt-Repo, direkt neben deinen Code. Diese Datei ist jetzt dein eigentliches Design-System – die Figma-Variablen sind nur das gerenderte Ergebnis.

Kurzer Einschub – ich habe mich wochenlang dagegen gewehrt, weil ich dachte, Claude könnte die Figma-Variablenbeschreibungen direkt lesen. Technisch gesehen kann es das. Aber die Beschreibungen, die die meisten Teams in Figma schreiben, sind entweder leer oder für Designer geschrieben („primary brand color“) – nicht für ein Modell, das sich Samstag um 2 Uhr morgens zwischen fünf Blautönen entscheiden muss. Schreibe sie für das Modell um. Deine Designer können sie trotzdem lesen. Niemand verliert.

Das ist die halbe Miete. Die andere Hälfte sind Komponenten – und genau dort scheitert der Workflow meist, wenn du sie nicht richtig gruppierst.

Komponenten gruppieren, damit Claude nicht in Panik gerät

Hier ist etwas, das ich auf die harte Tour gelernt habe. Wenn du Claude ein Designsystem mit 140 Komponenten in einer flachen Liste gibst und ihn bittest, einen Screen zu bauen, verhält er sich wie ein Handwerker, dem man einen Baumarkt überreicht und sagt, er solle eine Küche bauen. Technisch gesehen hat er alles, was er braucht. Praktisch wird er aber den falschen Hammer benutzen.

Die Lösung: Gruppiere deine Komponenten in semantische Kategorien, mit einer eigenen „Skill“ für jede Gruppe (oder, wenn du es einfach halten willst, eine Skill, die alle Gruppen kennt). Die drei Gruppierungen, die 90 % der Produkt-UIs abdecken:

1. Formularelemente. Inputs, Textareas, Auswahlmenüs, Checkboxen, Radiobuttons, Toggles, Datepicker, Datei-Upload-Zonen, Formularzeile, Formularfehler, Hilfetext. Jede Variante. Jeder Zustand — Standard, Fokus, Fehler, deaktiviert, Ladezustand.

2. Navigation. Topbars, Seiten-Navigation, Tab-Bars, Breadcrumbs, Paginierung, Zurück-Links, Segmentierte Steuerungen, Stepper. Auch hier sind Zustände wichtig — aktiv, Hover, deaktiviert, eingeklappt.

3. Datendarstellung. Tabellen, Karten, Listeneinträge, Statistik-Kacheln, Badges, Tags, Avatare, leere Zustände, Lade-Skelette, Diagramme, Paginierungs-Footer. Hier scheitern die meisten KI-generierten Screens, weil das Modell standardmäßig Tabellen verwendet, wo ein Kartenraster richtig wäre, oder Statistik-Kacheln, wenn eine Liste passender wäre.

Für jede Komponente in jeder Gruppe dokumentiere für Claude drei Dinge:

• Varianten — alle, mit exakt den Variantenschlüsseln, wie sie im Figma-Properties-Panel erscheinen
• Props — alle Booleans und Enums, die die Komponente bereitstellt
• Verwendungsregel — ein Satz: „Nutze die kompakte Variante für dichte Tabellen mit mehr als 8 Spalten. Standardvariante für alles andere.“

Diese dritte Zeile verhindert, dass Claude eine zufällige Variante auswählt, nur weil der Name cool klingt.

Dieses Muster habe ich in meinem früheren Figma-MCP-Artikel ausgearbeitet, und es ist das Muster, das den aktuellen Workflow tatsächlich dazu gebracht hat, brauchbare Erstentwürfe zu liefern. Wenn du schon einmal Designsysteme gebaut hast, weißt du: Das Schwierigste ist nicht, die Komponenten zu definieren — sondern zu dokumentieren, wann man welche verwendet. Diese Dokumentation war schon immer wertvoll für Menschen. Es stellt sich heraus, dass sie für Modelle noch wertvoller ist.

Profi-Tipp: Wenn du mehr als einen Designer im Team hast, hol sie in einen Raum und diskutiert die Verwendungsregeln lautstark, bevor ihr sie aufschreibt. Die Diskussion ist die Spezifikation. Die dabei auftauchenden Meinungsverschiedenheiten sind genau die Edge Cases, die Claude sonst falsch machen würde. Schreibe die gemeinsam gefundene Antwort als Regel auf.

Man könnte meinen, wir sind jetzt bereit für die Generierung. Sind wir nicht. Es fehlt noch ein Teil – und das ist genau der, den die meisten komplett überspringen.

Hör auf zu sagen „Bau mir ein Modal“ — Zeig Claude genau, was du meinst

Der größte Fehler beim Prompt-Engineering, den ich in der AI-Designarbeit sehe, ist Vagheit, die sich als Prägnanz tarnt. „Bau mir ein Modal.“ „Gestalte ein Dashboard.“ „Mach einen Einstellungsbildschirm.“ Das klingt wie ein klarer Prompt. Ist es aber nicht. Es ist das Prompt-Äquivalent dazu, einem Bauunternehmer zu sagen: „Bau mir eine Küche“, ohne einen Grundriss zu liefern.

Was tatsächlich funktioniert: Kombiniere deine Komponenten-Skills mit konkreten Beispiel-Screens aus echten Produktions-Apps.

Hier spielt Mobbin seine Stärken aus. Mobbins Bibliothek umfasst über 600.000 Screens aus mehr als 1.200 Produktions-Apps (Stand 2026) — das heißt, für nahezu jedes UI-Muster, das du bauen willst, gibt es dort eine ausgelieferte Version, entwickelt von einem Team, das wahrscheinlich mehr Zeit in die Überlegungen gesteckt hat, als du aufbringen kannst.

Mein tatsächlicher Workflow, am Beispiel eines Paywallscreens vom Samstag:

1. Mobbin öffnen. Nach „paywall“ in der Kategorie Finance suchen.
2. Die Paywall von Rocket Money aufrufen. Die von Copilot. Die von YNAB.
3. Zwei oder drei Screenshots machen, die den gewünschten Ton treffen.
4. Die Screenshots zusammen mit meinen Tokens- und Komponenten-Skills als Bildreferenzen in Claude Code einfügen.
5. Prompt: „Erstelle einen Paywall-Screen für eine Finanz-App. Stil- und Layout-Referenz angehängt. Verwende unsere Design-Tokens und Komponenten. Ausgabe als HTML. Hero: Jahresplan für 79,99 $ mit ‚40 % sparen‘-Pill. Drei Feature-Reihen. Monatsumschalter. Trust-Logos unten.“

Dieser Prompt enthält alles, was ein Designer braucht. Referenzen für Stil und Komposition. Konkrete Angaben zum Inhalt. Vorgaben für die Bausteine. Keine Unklarheiten, die das Modell durch Mittelwerte auflösen müsste.

Vergleiche das mit „bau mir eine Paywall“. Die erste Version liefert dir einen echten Screen. Die zweite Version eine Halluzination eines Screens.

(Falls du Mobbin nicht nutzen willst: Die Alternativen 2026 sind wirklich gut geworden — InspoAI bietet natürliche Sprachsuche, Appshots zeigt Flows statt Einzelscreens, Webframe ist web-first. Ich bleibe trotzdem bei Mobbin, weil die Kategorien Finance und B2B SaaS dort einfach tiefer gehen. Deine Erfahrung kann variieren.)

Noch ein Hinweis zu Referenzen — verwende zwei oder drei, nicht nur eine. Bei einer Referenz kopiert Claude sie. Bei drei interpoliert Claude, was dem entspricht, was du eigentlich willst. Die Kunst des Promptens liegt im Abstand zwischen den Beispielen, die du auswählst.

Gut. Du hast Tokens. Du hast gruppierte Komponenten mit Nutzungsregeln. Du hast Beispiel-Screens. Jetzt kommt der Teil, in dem du die Maschine tatsächlich installierst und generierst.

Installation der Figma-Skills in Claude

Zwei Skills übernehmen die eigentliche Arbeit in dieser Pipeline, und beide sind in fünf Minuten installiert.

1. figma-use — das ist der grundlegende Skill vom eigenen MCP-Server von Figma. Er ermöglicht es Claude, auf dein Figma-Canvas zu schreiben: Frames erstellen, Komponenten instanziieren, Variablen anwenden, Styles setzen. Alles, was in Figma landet, läuft über diesen Skill. Die offizielle Figma-Dokumentation beschreibt die Installation; die Kurzfassung: Skill-Repository klonen, zippen, ins Skills-Verzeichnis von Claude legen, Session neu starten. Fertig.

2. Dein eigener „Apply Design System“-Skill — das ist das individuelle Element. Eine einzelne Markdown-Datei, die du selbst erstellst. Sie enthält:

• Einen Link oder Verweis auf deine design-tokens.md-Datei
• Einen Link oder Verweis auf deine components.md-Datei (nach Kategorie gruppiert, mit Anwendungsregeln)
• Ein Vorwort, das Claude erklärt, wie diese anzuwenden sind: „Immer semantische Tokens verwenden. Niemals rohe Hex-Werte nutzen. Immer die Komponentenvariante wählen, deren Anwendungsregel zum Kontext passt. Im Zweifel lieber nachfragen als raten.“
• Eine Liste verbotener Verhaltensweisen: „Keine neuen Tokens erfinden. Keine neuen Komponenten erstellen. Keine Verläufe verwenden, die nicht in der Token-Liste stehen. Keine Ecken mit beliebigen Radiuswerten abrunden.“

Dieses Vorwort ist entscheidend. Besonders die Liste der verbotenen Verhaltensweisen verhindert das „Durchschnitt-Internet“-Abdriften. Du bringst dem Modell nicht Kreativität bei. Du bringst ihm Disziplin bei. Disziplin ist genau das, was du beim ersten Durchlauf willst.

Beide Skills bereitstellen. Claude Code neu starten. Prüfen, ob sie geladen wurden.

An diesem Punkt hast du eine Claude-Instanz, die deine Tokens auf Englisch versteht, deine Komponenten im Kontext kennt, Referenz-Screens für das gewünschte Pattern hat und über Skills verfügt, mit denen sie in Figma schreiben kann. Das ist das Setup. Jetzt wird generiert — und hier kommt der nicht offensichtliche Teil, den dir niemand verrät.

Falls du möchtest, dass jemand diese gesamte Pipeline für ein produktives Designsystem einrichtet — Tokens-Skill, Komponenten-Skills, MCP-Verdrahtung, Team-Rollout — das ist ein spezielles Angebot von mir. Was ich gebaut habe, findest du unter fiverr.com/s/EgxYmWD.

Lokal in Claude Code generieren. Dann nach Figma pushen.

Hier liegt der Fehler, den die meisten Tutorials machen. Sie geben Claude einen Prompt, lassen es direkt nach Figma pushen, schauen sich das Ergebnis an und beginnen dann, in Figma zu iterieren. Dieser Workflow ist langsam, verbraucht viele Tokens und liefert schlechtere Ergebnisse, weil jede Iteration über den MCP-Server läuft.

Das richtige Muster: Zuerst in Claude Code als HTML iterieren. Erst nach Figma pushen, wenn das HTML passt.

Mein tatsächlicher Ablauf für die Finance-Paywall:

1. Prompt mit allem geladen — Token-Skill, Komponenten-Skill, drei Mobbin-Referenzen, das spezifische Content-Briefing. Ich fordere HTML-Output mit Tailwind-Klassen, die auf meine Design-Tokens gemappt sind.

2. Claude generiert das HTML inline in Claude Code. Ich rendere es in einer Browser-Vorschau. Das dauert etwa 8 Sekunden. Kein Figma-Roundtrip.

3. Ich beurteile das Ergebnis. Nicht „mach es besser“. Konkret: „Der Hero-CTA verwendet action-primary-subtle, aber das ist eine Conversion-Fläche — benutze action-primary-bold. Der Abstand in der Feature-Row ist space-3; dieses Pattern verlangt space-4, weil die Icons 24px groß sind. Die Trust-Logos-Reihe fehlt ein Divider.“

4. Claude aktualisiert das HTML. Nochmals 6 Sekunden. Ich rendere erneut.

5. Diesen Loop mache ich zwei- bis dreimal. In dieser Phase ist jede Iteration günstig — kein Figma, kein MCP-Payload, nur Text.

6. Wenn das HTML zu 90% passt, lasse ich Claude mit dem figma-use-Skill nach Figma pushen. Das ist der teure Schritt, und ich mache ihn nur einmal pro Design.

7. Claude schreibt die Frames in Figma. Echte Komponenten. Echte Variablen. Echte Varianten. Responsiv. Benannte Layer. Auto-Layout angewendet. Kleinere Textstil-Abweichungen, auf die ich gleich eingehe.

Dieses Local-First-Muster halbiert meine Iterationszeit ungefähr und verbraucht deutlich weniger Tokens. Es liefert auch bessere Ergebnisse, weil ich am Design arbeite, solange Änderungen noch günstig sind. Wenn ich nach Figma pushe, ist das Design im Grunde fertig — Figma ist das Ziel, nicht die Werkstatt.

Ein spezifischer Hinweis: Wenn du HTML-Output anforderst, gib die Token-Namen im Prompt an. „Verwende Klassen wie bg-surface-raised, text-content-primary, rounded-radius-md.“ So zwingst du Claude, die Tokens als First-Class-Citizens im generierten Markup zu behandeln. Du kannst sie später mit deiner echten Tailwind-Konfiguration verbinden oder einfach als Dokumentation lesen, welche Tokens wo verwendet wurden. So oder so erhältst du prüfbaren Output.

Der ehrliche Teil: Was an diesem Workflow immer noch schiefgeht

Ich habe inzwischen Dutzende von Screens durch diese Pipeline geschickt. Es ist eine enorme Verbesserung gegenüber dem klassischen Prompting. Magie ist es trotzdem nicht. Hier sind die konkreten Dinge, die immer noch schiefgehen – ganz ohne Schönfärberei.

Textstile werden am häufigsten übersehen. Claude trifft den Abstand, die Farben, die Komponenten, das Layout – und wendet dann text-body-md auf eine Überschrift an, die eigentlich text-heading-sm sein sollte. Ich verstehe bis heute nicht ganz, warum ausgerechnet Typografie die Schwachstelle ist. Meine Arbeitshypothese: Textstil-Tokens transportieren subtilere Intentionen („verwende dies für mitteldichte Listenüberschriften“) als Farb- oder Abstands-Tokens, und das Modell hat weniger Signal, an dem es sich orientieren kann. So oder so: Typografie immer manuell in Figma prüfen. Plane pro Screen drei bis fünf Minuten für diesen Feinschliff ein.

Auto-Layout-Richtung kippt manchmal. Aus einer Zeile wird eine Spalte oder umgekehrt, besonders bei verschachtelten Komponenten. In Figma meist mit einem Klick behoben, aber trotzdem ein nerviger Mehraufwand.

Markenpersönlichkeit kommt nicht rüber. Der Workflow produziert Screens, die korrekt sind. Er produziert keine Screens, die Charakter haben. Diese letzten 10 % – die Mikro-Interaktion, die eine ungewöhnliche Kompositionsentscheidung, die Typo-Behandlung, die deine App unverwechselbar macht – müssen weiterhin von Menschen kommen. Dieser Workflow liefert einen polierten, systemkonformen ersten Entwurf. Kunst entsteht daraus nicht.

Tokens werden manchmal wörtlich statt semantisch angewendet. Wenn Claude in meiner Token-Datei surface-raised: #F7F7F9 sieht, schreibt er gelegentlich #F7F7F9 direkt ins HTML statt bg-surface-raised. Das Vorwort, das dies verbietet, hilft, beseitigt das Problem aber nicht vollständig. Den generierten Code immer prüfen.

Light/Dark-Parität erfordert manuelle Kontrolle. Selbst wenn beide Werte in den Tokens definiert sind, wählt Claude gelegentlich eine Kombination, die im Light-Mode funktioniert, aber im Dark-Mode die WCAG-Kontraste verfehlt. Ich habe das beim Paywall-Screen überprüft – die Trust-Logo-Reihe hatte im Light-Mode ein Kontrastverhältnis von 4,5:1, im Dark-Mode aber nur 3,2:1. Vor dem Release unbedingt einen Kontrast-Check durchführen; der 2026er-Standard liegt weiterhin bei 4,5:1 für Fließtext.

Würde ich diese Schwächen ohne den Kontext der strukturierten Arbeitsweise aufzählen, klänge es schlimmer, als es ist. Deshalb drehe ich den Spieß jetzt um.

Was sich tatsächlich ändert: Erstentwurfsqualität und Aufräumzeit

Hier ist die echte Differenz, beobachtet über meine eigenen Projekte in den letzten acht Wochen. Ich gebe dir keine erfundenen Prozentsätze, weil ich das nicht in einer Datenbank erfasse. Was ich jedoch tracke, ist, wie viele Screens ohne signifikante Nacharbeit ausgeliefert werden – und das Muster ist konsistent genug, dass ich ihm vertraue.

Vor diesem Workflow: Der Erstentwurf aus klassischem Prompting erforderte meistens einen strukturellen Neuaufbau. Komponenten waren falsch, die Hierarchie stimmte nicht, die Hälfte der Tokens wurde gar nicht angewendet. Der realistische Weg zu einem auslieferbaren Screen lag bei 45–90 Minuten Nacharbeit pro Screen, und meist habe ich wesentliche Teile von Hand neu gebaut.

Nach diesem Workflow: Der Erstentwurf ist strukturell korrekt. Tokens werden angewendet. Komponenten stimmen. Die Layout-Hierarchie ist fast final. Die Nacharbeit beschränkt sich meist auf Textstile, ein oder zwei Abstands-Anpassungen und einen Kontrast-Check. Der realistische Weg zu einem auslieferbaren Screen liegt bei 10–15 Minuten Nacharbeit pro Screen, und ich editiere, statt neu zu bauen.

Der kumulierte Gewinn ist Konsistenz. Ein Teammitglied, das dieses Setup ebenfalls nutzt, liefert Screens, die aussehen, als kämen sie aus demselben System – weil sie es tun. Vor strukturierten Skills hatten KI-generierte Screens eine Art Entropie – jede Generation driftete leicht ab. Nach strukturierten Skills wird das Driften durch die Systembeschreibung selbst begrenzt.

Für Teams, die mit Designsystemen arbeiten, spiegelt dieses Muster das wider, was Figma Anfang des Jahres in ihrem AI-to-Figma-Workflow für Designsysteme dokumentiert hat: Strukturiere das System, dann lass die Agenten innerhalb dieser Struktur arbeiten. Die Verbesserung kommt nicht durch smartere Modelle, sondern durch engere Leitplanken.

Noch ein Punkt, der erwähnt werden sollte: Die Stunde, die du in das Schreiben von Token-Beschreibungen und Komponenten-Regeln investierst, zahlt sich jedes Mal aus, wenn du einen Screen generierst. Nach dem fünften oder sechsten Screen ist der Workflow netto deutlich im Plus. Vor dem fünften investierst du noch. Hör nicht nach Screen zwei auf. Hör nach Screen zehn auf, wenn es dann immer noch nicht funktioniert – und bis dahin weißt du genau, welcher Teil des Setups noch nachgeschärft werden muss.

Die Paywall, fertiggestellt

Die Paywall, die mir am Anfang dieses Beitrags den Samstag geraubt hat, wurde am nächsten Morgen in etwa 40 Minuten neu aufgebaut – inklusive der Token- und Komponentenarbeit, die ich beim ersten Mal hätte erledigen sollen. Die finale Version nutzte mein tatsächliches action-primary-bold für den CTA, das korrekte surface-elevated für die Plan-Karte, den spezifischen space-4-Rhythmus für die Feature-Zeilen. Der Trust-Logo-Divider war vorhanden. Sowohl im Light- als auch im Dark-Mode wurde der Kontrast bestanden. Die Textstile brauchten noch einen Durchgang zur Bereinigung auf der Figma-Seite. Versandt.

Die Lektion ist nicht, dass AI-Design jetzt einfach funktioniert. Die Lektion ist, dass AI-Design funktioniert, wenn du dein Designsystem als Trainingsdaten behandelst und lokal iterierst, bevor du dich auf die Leinwand festlegst. Es funktioniert, wenn du aufhörst zu hoffen, dass das Modell deine Gedanken liest, und stattdessen so spezifisch beschreibst, was du im Kopf hast, dass das Modell es nicht mehr erraten muss.

Hier ist, was ich möchte, dass du heute tust – nicht nächste Woche, nicht nachdem du noch drei weitere Artikel gelesen hast. Öffne dein Designsystem. Wähle eine Token-Kategorie aus. Surface, Content oder Spacing. Schreibe für jeden Token in dieser Kategorie einen einzeiligen „Wann verwenden“-Beschreibungssatz. Das ist dein erster Schritt. Das ist der ganze Schlüssel. Wenn du das heute für eine Kategorie machst, bist du schon weiter als die meisten Teams. Mach das diese Woche für jede Kategorie, und du hast ein Designsystem, das ein Modell tatsächlich anwenden kann.

Die nächste Paywall, die du baust, wird dir nicht den Samstag rauben. Sie wird dich vierzig Minuten kosten. Und die vierzig Minuten werden größtenteils für Typografie-Bereinigung draufgehen, was – ehrlich gesagt – du sowieso gemacht hättest.

Häufig gestellte Fragen

Brauche ich den kostenpflichtigen Figma MCP-Server für diesen Workflow?

Nein. Der Kern des Figma MCP-Servers und die grundlegende figma-use-Skill sind kostenlos installierbar. Für einige Schreiboperationen in gemeinsam genutzte Team-Bibliotheken ist ein kostenpflichtiger Figma-Plan erforderlich, aber Solo-Arbeiten an Entwurfsdateien funktionieren mit dem kostenlosen Tarif. Siehe den Implementierungsabschnitt oben für die vollständige Einrichtung.

Funktioniert das auch mit Codex oder anderen Nicht-Claude-Modellen?

Teilweise. Der Figma MCP-Server unterstützt mehrere MCP-Clients, darunter Codex, sodass die Figma-Seite funktioniert. Das Skill-Ladeverfahren ist jedoch Claude-spezifisch — Codex verwendet sein eigenes Erweiterungsformat. Die Kernidee (strukturierte Tokens plus Komponenten-Skills plus Referenz-Screens) ist modellunabhängig und lässt sich auf jeden fähigen Coding-Agent übertragen.

Wie lange dauert es, Design-Token- und Komponenten-Skills beim ersten Mal einzurichten?

Rechnen Sie mit drei bis sechs Stunden konzentrierter Arbeit für ein mittelgroßes System, vorausgesetzt, Ihre Tokens und Komponenten sind bereits irgendwo dokumentiert. Der Zeitaufwand entfällt fast vollständig auf das Schreiben der „Wann verwenden“-Beschreibungen — das eigentliche Erstellen der Skill-Dateien geht schnell.

Kann Claude neue Komponenten erstellen, wenn ich ihn darum bitte?

Ja, aber Sie sollten dies im Skill-Preamble für produktive Arbeit verbieten. Wenn Claude spontan Komponenten erfindet, wird die Systemkonsistenz untergraben — genau das wollen Sie mit diesem Workflow verhindern. Wenn wirklich eine neue Komponente benötigt wird, entwerfen Sie sie zuerst bewusst in Figma, fügen Sie sie dann Ihrem Komponenten-Skill hinzu und generieren Sie anschließend damit.

Was ist der häufigste Fehler beim Einstieg in diesen Workflow?

Das Überspringen der „Wann verwenden“-Beschreibungen bei Tokens. Teams kopieren Token-Namen und -Werte, denken, das reicht, und wundern sich, warum das Ergebnis immer noch generisch aussieht. Die Beschreibungen sind der Teil, der ein Token von Daten in eine Anweisung verwandelt. Ohne sie landen Sie wieder beim klassischen Prompting — nur mit mehr Schritten.

Lass uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io