MCP Figma Design to Code: KI-Workflow richtig optimieren

Was ist MCP?

MCP (Model Context Protocol) ist eine standardisierte Schnittstelle, über die KI-Modelle strukturiert mit externen Tools, Design-Systemen und Entwicklungsumgebungen kommunizieren können. Im Kontext Figma Design-to-Code ermöglicht MCP, dass KI-Modelle wie OpenAI, Claude oder GitHub Copilot nicht nur Screenshots oder statische Exporte analysieren, sondern direkt auf semantische Designinformationen zugreifen können.

Abbildung 1: MCP verbindet Code, KI-Agent und Figma Dev Mode.

Warum MCP für UX- und Projektteams relevant ist

Für UX-Teams, Product Owner und Projektteams ist MCP nicht nur ein technisches Thema. Es verändert die Art, wie Designentscheidungen in die Entwicklung übertragen werden.

Der größte Vorteil liegt in der Verbindung von Design, Codebase und Design-System. Wenn die KI versteht, welche Komponenten existieren, welche Tokens verwendet werden und welche Regeln im Projekt gelten, kann sie wesentlich konsistentere Ergebnisse liefern. Figma empfiehlt für besseren Code unter anderem den Einsatz von Komponenten, Code Connect, Variablen, semantischen Layer-Namen, Auto Layout und Annotationen.

Das bedeutet: Je besser ein Design-System gepflegt ist, desto wertvoller wird es für KI-gestützte Entwicklung. Eine gute Figma-Struktur wird damit nicht nur zur Designqualität, sondern direkt zur Codequalität.

Vom klassischen Handoff zur KI-gestützten Entwicklung

Figma Dev Mode: Der klassische Standard

Vor MCP war der Figma Dev Mode für viele Teams der zentrale Übergabepunkt zwischen Design und Entwicklung. Designer:innen erstellen Interfaces in Figma, Entwickler:innen übernehmen anschließend Maße, Farben, Textstile, Abstände und Assets aus dem Dev Mode. Dieser Prozess funktioniert, ist aber häufig manuell. Entwickler:innen müssen Designentscheidungen interpretieren, Komponenten zuordnen, responsive Verhalten ableiten und technische Regeln aus der Codebase berücksichtigen. Genau hier entstehen oft Reibungsverluste.

Figma Dev Mode + MCP: Mehr Kontext für KI-Systeme

Mit MCP erweitert sich der klassische Dev-Mode-Workflow um eine KI-gestützte Kontextebene. Die KI kann über den Figma MCP Server strukturierte Informationen aus der Figma-Datei verwenden. Dazu gehören beispielsweise Komponenten, Variablen, Assets, Layoutinformationen und konkrete Varianten. OpenAI beschreibt für Codex, dass über den Figma Skill der Figma MCP-Server genutzt werden kann, um strukturierten Designkontext, Variablen, Assets und die exakte Variante für die Implementierung abzurufen. Dadurch entsteht ein intelligenterer Design-to-Code-Prozess. Das Design wird nicht nur visuell analysiert, sondern in seiner Struktur verstanden. Komponenten, Zustände, Abstände und Hierarchien können besser in Code übersetzt werden.

Figma Dev Mode + MCP + Design-System: Die höchste Qualität

Die besten Ergebnisse entstehen, wenn MCP nicht isoliert genutzt wird, sondern mit einem vollständigen Design-System und einer bestehenden Codebase verbunden ist. Dann kennt die KI nicht nur das Design aus Figma, sondern auch:

• bestehende UI-Komponenten,
• Design Tokens,
• Variablen,
• Namenskonventionen,
• Framework- und Architekturvorgaben,
• Datei- und Komponentenstrukturen,
• Regeln für Accessibility und Responsiveness.

Das Ergebnis ist ein deutlich konsistenten Code, eine bessere Wiederverwendbarkeit sowie eine design-system-konforme Implementierung. Der entscheidende Punkt: Je mehr strukturierte Design-System-Daten verfügbar sind, desto präziser und hochwertiger wird der generierte Code.

Best Practices

Bevor KI-gestützte Workflows ihr volles Potenzial im Design-to-Code-Prozess entfalten können, braucht es eine saubere Grundlage im Design selbst. Denn die Qualität des generierten Codes hängt nicht mehr nur vom verwendeten Tool oder Prompt ab, sondern zunehmend von der Struktur und Systematik der Figma-Datei.

Große Sprachmodelle (LLMs) arbeiten besonders gut mit klaren Regeln, konsistenten Mustern und wiederverwendbaren Strukturen. Genau deshalb gewinnen klassische Design-System-Prinzipien plötzlich enorm an Bedeutung: Komponenten, Variablen, Auto Layouts und eindeutige Naming-Conventions helfen der KI dabei, Interfaces korrekt zu interpretieren und daraus konsistenten Code abzuleiten.

Je strukturierter und systematischer eine Figma-Datei aufgebaut ist, desto besser kann ein KI-System Designentscheidungen nachvollziehen.

Struktur

Die Organisation einer Figma-Datei hat direkten Einfluss darauf, wie gut KI-Systeme das Design interpretieren können. Einfache Layer-Strukturen oder generische Namen wie “Frame 24” oder “Group 5” führen zu nicht wiederverwendbarem und unstrukturiertem Code-Output. Daher sollte man folgende Anweisungen beachten:

• Verwende semantische Layer-Namen
• Nutze konsequent Komponenten und Varianten
• Arbeite mit Auto Layout
• Reduziere unnötige Verschachtelungen

Abbildung 2: Saubere Figma-Struktur mit semantischen Layern und Komponenten.

Das Ergebnis:

Abbildung 3: Vergleich zwischen unstrukturiertem und strukturiertem Login-Design.

Variablen

Variablen und Tokens gehören zu den wichtigsten Grundlagen für hochwertigen Code-Output. Ohne sie greifen KI-Systeme häufig auf harte Werte zurück - etwa feste Pixelgrößen und Hex-Codes. MCP kann Variablen direkt auslesen und dadurch konsistenten, design-system-konformen Code generieren. Daher gilt:

• Farben ausschließlich über Variablen definieren
• Spacing-Tokens für Padding, Gap, Border-Radius und Layout verwenden
• Typografie über Text-Styles oder Variablen steuern
• Semantische Tokens nutzen

Abbildung 4: Figma-Variablen und Token-Struktur als Grundlage für konsistente UI-Werte.

Annotationen

Die KI bzw. das LLM versteht nicht automatisch die funktionale Bedeutung eines Interfaces. Zusätzliche Annotationen helfen dabei, Interaktionen, Verhalten und technische Anforderungen besser zu interpretieren. Folgendes gilt es dabei zu beachten:

• Hover- und Active-Status (falls nicht über Komponenten gelöst)
• Accessibility-Hinweise
• Keyboard-Interaktionen (falls nicht bereits über den Prototyp gelöst)
• Responsive-Design-Regeln
• Hinweise zu Animationen
• Developer Notes

Abbildung 5: Annotationen geben der KI zusätzlichen Kontext zu Inhalt, Entwicklung, Barrierefreiheit und Interaktion.

Regeln

Große Sprachmodelle arbeiten besonders zuverlässig, wenn klare Regeln und feste Konventionen definiert sind. Genau dafür bietet es sich an, projektbezogene Regeln oder Guidelines zu hinterlegen. Diese Regeln beschreiben das implizite Wissen einer Codebase — also Dinge, die erfahrene Entwickler:innen normalerweise automatisch berücksichtigen würden, sowie zusätzliche Anweisungen und Design-Informationen. Dazu gehören bspw.:

• welche Komponenten verwendet werden sollen,
• welche Stile die einzelnen Komponenten enthalten,
• wie die KI den Prompt verarbeiten darf,
• Accessibility-Hinweise,
• wie Dateien strukturiert werden,
• welche Werte niemals hardcoded sein dürfen,
• oder welche Naming-Conventions gelten.

Beispielhafte Guidelines-Struktur

guidelines/
|-- overview.md            <- project philosophy, source of truth hierarchy, global rules
|-- discovery.md           <- Figma MCP reading order, node inspection workflow
|-- setup.md               <- project architecture, providers, imports, build setup
|-- icon-discovery.md      <- icon lookup workflow, code connect icon mapping

foundations/
|-- variables.md           <- Figma Variables architecture, token collections
|-- color.md               <- semantic colors, token usage hierarchy
|-- typography.md          <- text styles, scale, weights, line heights
|-- spacing.md             <- spacing tokens, layout rhythm, gap strategy
|-- surfaces.md            <- backgrounds, containers, surface hierarchy
|-- elevation.md           <- shadows, layering, elevation levels
|-- radius.md              <- border radius scale, component mapping
|-- icons.md               <- icon sizing, icon usage rules
|-- modes.md               <- light mode, dark mode, theme variants
|-- focus.md               <- focus indicators, keyboard focus rules
|-- input-styling.md       <- inputs, validation states, field appearance

components/
|-- overview.md            <- component catalog, lookup strategy
|-- button.md              <- button variants, states, accessibility
|-- input.md               <- text fields, labels, validation
|-- modal.md               <- dialogs, overlays, focus management
|-- menu.md                <- dropdowns, context menus, keyboard support
|-- tabs.md                <- tab navigation, layouts, interactions
|-- navigation.md          <- nav bars, sidebars, breadcrumbs
|-- media.md               <- avatars, images, video components
|-- icons.md               <- icon components, wrappers, patterns

composition/
|-- overview.md            <- composition principles, layout decisions
|-- alignment.md           <- alignment rules, baselines, grids
|-- icons.md               <- icon placement within layouts
|-- surfaces.md            <- card stacking, nested containers
|-- layouts.md             <- grids, sections, responsive layouts
|-- density.md             <- whitespace, content density strategy
|-- hierarchy.md           <- visual weight, information hierarchy

accessibility/
|-- overview.md            <- WCAG AA philosophy and requirements
|-- keyboard.md            <- keyboard navigation and focus order
|-- forms.md               <- labels, errors, validation, autocomplete
|-- dialogs.md             <- modal accessibility and focus trapping
|-- navigation.md          <- landmarks, skip links, semantics
|-- contrast.md            <- color contrast and readability rules
|-- screenreaders.md       <- ARIA, announcements, semantic HTML
|-- wcag-aa.md             <- complete WCAG 2.2 AA reference
|-- react-checklist.md     <- mandatory accessibility review checklist

ai/
|-- roctoc.md              <- role, objective, context, task, output contract
|-- figma-mcp.md           <- MCP workflow and node inspection strategy
|-- code-connect.md        <- component discovery and reuse rules
|-- design-to-code.md      <- implementation workflow
|-- validation.md          <- code review and validation checks
|-- prompting.md           <- prompt templates, patterns, anti-patterns

Prompts richtig schreiben

Der MCP-Server stellt der KI alle relevanten Informationen aus Figma zur Verfügung. Wie diese Informationen verarbeitet werden und welche Qualität der generierte Code erreicht, hängt jedoch maßgeblich vom Prompt ab.

Ein guter Prompt definiert nicht nur die Aufgabe, sondern liefert auch den notwendigen technischen Kontext. So kann die KI beispielsweise bestehende Komponenten verwenden, die richtige Projektstruktur berücksichtigen, bestimmte Frameworks einsetzen oder vorgegebene Entwicklungsstandards einhalten.

Dabei gilt: Je konkreter die Anweisung, desto präziser wird das Ergebnis. Gute Prompts funktionieren deshalb weniger wie Befehle und mehr wie ein Briefing für ein erfahrenes Entwicklungsteam.

Abbildung 6: Kontext macht den Prompt präziser.

Eine hilfreiche Struktur bietet das ROCTOC-Framework:

• Role - welche Rolle soll die KI übernehmen?
• Objective - welches Ziel soll erreicht werden?
• Context - welche Informationen zur Codebasis oder Architektur sind relevant?
• Tasks - welche konkreten Schritte sollen durchgeführt werden?
• Outputs - in welchem Format soll das Ergebnis geliefert werden?
• Constraints - welche Regeln und Einschränkungen müssen eingehalten werden?

Prompt Beispiel mit dem ROCTOC-Framework

# ROLE

You are a Senior Frontend Engineer with a focus on Figma MCP, React, TypeScript, and design system implementation.

# OBJECTIVE

Implement the selected Login Card from Figma as production-ready React code.

The implementation must match the design pixel-perfectly and fully comply with the guidelines in the repository.

# CONTEXT

The project uses:

- React
- TypeScript
- Figma MCP
- Figma Code Connect
- Figma Variables

Important rules:

- No assumptions about shadcn/ui
- No assumptions about Iconoir
- No hardcoded colors
- No hardcoded spacing values
- No hardcoded border radius values
- No invented components when Code Connect exists

Source of truth order:

1. Code Connect component
2. Figma component
3. Figma variables
4. Custom implementation

# TASK

Analyze the selected Login Card in Figma.

Perform the following steps in exactly this order:

1. Identify all Figma components used
2. Check the available Code Connect references for each component
3. Identify all Figma variables used
4. Identify text styles
5. Identify the layout structure and Auto Layout properties

# OUTPUT REQUIREMENTS

## Design Analysis

Provide:

- used components
- used variants
- used variables
- used text styles

## Mapping

Show a mapping:

### Components

Figma Component -> React Component

### Tokens

Figma Variable -> used token

## Implementation

Generate:

- complete React component code
- TypeScript
- Imports
- Props Interface
- Accessibility
- responsive behavior

## Validation

Finally verify:

- no hardcoded colors
- no hardcoded spacing values
- no hardcoded radius values
- no duplicated components
- all possible Code Connect components used

# CONSTRAINTS

## Forbidden

- guessing Tailwind values
- guessing colors
- guessing radius values
- guessing spacing values
- rebuilding components when Code Connect exists

If information is missing in the Figma design:


1. Name the missing information
2. Make no assumptions
3. Suggest an alternative

# COMPLETION CRITERIA

The solution is only considered complete when:

- all components come from Code Connect or are newly created with justification
- all tokens come from Figma variables
- the structure matches the Figma layout
- no design decisions were invented

Der besondere Vorteil im MCP-Umfeld: Große Teile dieser Struktur müssen nicht bei jeder Anfrage neu formuliert werden. Rollen, Architekturvorgaben, Coding Standards oder Design-System-Regeln können dauerhaft in Markdown-Dateien als Regeln oder Guidelines hinterlegt werden.

Abbildung 7: Ablage der Prompt-Vorlage als Markdown-Datei

Dadurch reduziert sich der eigentliche Prompt häufig auf die reine Aufgabe:

Implement the selected Login Card from Figma.
Follow all project guidelines.

Häufige Fehler vermeiden

Viele Probleme entstehen nicht durch die KI selbst, sondern durch unklare Designs, fehlende Regeln oder zu große Kontextmengen.

• ❌ Der MCP-Server wurde nicht gestartet
• ❌ Die Figma Desktop App ist nicht geöffnet, falls der lokale Server genutzt wird
• ❌ Berechtigungen fehlen
• ❌ Die Verbindung zwischen IDE, MCP Client und Figma ist instabil
• ❌ Es wird ein zu großer Frame ausgewählt
• ❌ Layer sind schlecht benannt
• ❌ Komponenten wurden nicht sauber angelegt
• ❌ Variablen und Tokens fehlen
• ❌ Die KI generiert Rohcode statt Design-System-Code
• ❌ Projektregeln fehlen
• ❌ Der Prompt ist zu allgemein
• ❌ Es wird versucht, eine komplette komplexe Seite in einem Schritt umzusetzen

Figma empfiehlt, große oder komplexe Frames zu vermeiden und stattdessen kleinere Bereiche wie einzelne Komponenten oder logische Sektionen auszuwählen. Große Selektionen können Tools verlangsamen, Fehler verursachen oder zu unvollständigen Antworten führen.

Für die Praxis heißt das: Lieber iterativ arbeiten. Erst Header, dann Card, dann Pricing Section, dann responsive Verhalten. Kleine, klar abgegrenzte Aufgaben führen meist zu besseren Ergebnissen als ein großer One-Shot-Prompt.

Warum Design-Systeme durch MCP wichtiger werden

MCP macht Design-Systeme nicht überflüssig. Im Gegenteil: Es erhöht ihren Wert.

Ein gepflegtes Design-System liefert der KI genau die Struktur, die sie für guten Code benötigt. Komponenten, Tokens, Varianten, Namenskonventionen und Dokumentation werden zu maschinenlesbarem Kontext.

Wer in Zukunft bessere KI-generierte Frontends möchte, sollte zuerst die Design- und Codebasis strukturieren. MCP ist kein Ersatz für Systematik. MCP verstärkt Systematik.

Checkliste

So bereitest du Figma-Dateien optimal für MCP vor:

• ☑️ Sind alle wiederverwendbaren Elemente als Komponenten angelegt?
• ☑️ Gibt es Varianten für relevante States?
• ☑️ Werden Auto Layouts konsequent verwendet?
• ☑️ Sind Layer und Komponenten semantisch benannt?
• ☑️ Werden Farben, Spacing, Typografie und Radius über Variablen oder Tokens gesteuert?
• ☑️ Gibt es Annotationen für Verhalten, Responsiveness und Accessibility?
• ☑️ Sind Assets und Icons sauber eingebunden?
• ☑️ Gibt es Projektregeln für die KI?
• ☑️ Ist klar, welche Code-Komponenten wiederverwendet werden sollen?
• ☑️ Ist der ausgewählte Frame klein genug?
• ☑️ Ist der Prompt konkret und technisch eindeutig?
• ☑️ Wird iterativ gearbeitet, statt alles in einem Schritt zu generieren?

Fazit: LLMs lieben Struktur, Regeln und Konsistenz

MCP verändert den Figma Design-to-Code-Prozess grundlegend. Statt Designs nur visuell zu interpretieren, können KI-Systeme strukturierte Designinformationen nutzen und diese mit Projektregeln, Code-Konventionen und Design-System-Komponenten verbinden. Der entscheidende Erfolgsfaktor ist jedoch nicht allein das Tool. Entscheidend ist die Qualität des Kontexts.

Eine saubere Figma-Datei, ein gepflegtes Design-System, klare Variablen, eindeutige Annotationen und gut formulierte Prompts führen zu deutlich besseren Ergebnissen. Teams, die diese Grundlagen schaffen, profitieren von schnellerem Handoff, konsistenterem Code und weniger Abstimmungsschleifen zwischen Design und Entwicklung.

Die wichtigste Regel lautet:

Je strukturierter das Design, desto besser der Code.