Wie Figma Claude Code in den Designprozess einbindet

Claude Code to Figma: Welche Oberflächen lassen sich erfassen?

Claude Code to Figma erfasst die Oberfläche, die gerade im Browser läuft: in der Produktivumgebung, in einer Staging-Umgebung oder unter localhost, also auf dem Entwicklungsserver des eigenen Rechners. In einer Sitzung lassen sich mehrere Bildschirme erfassen und zum Vergleich auf dem Canvas ablegen. Jeder Bildschirm wird zu einem bearbeitbaren Frame, der sich verschieben, duplizieren, überarbeiten und kommentieren lässt. Figmas Ankündigung beschreibt diese Umgebungen und Abläufe mit mehreren Bildschirmen.

Das ist, als würde man die laufende App zur Bearbeitung auf einem Tisch ausbreiten. Im Browser erlebt man den Ablauf Schritt für Schritt; in Figma lassen sich die einzelnen Schritte im Zusammenhang betrachten.

MCP steht für Model Context Protocol. Über diese Verbindung kann Claude Code die Werkzeuge von Figma nutzen. Das Erfassungswerkzeug heißt generate_figma_design. Es kann Ebenen in eine neue oder vorhandene Figma-Design-Datei sowie in die Zwischenablage übertragen. Neu angelegte Dateien mit erfassten Oberflächen landen in den Entwürfen des Teams oder der Organisation. Inhalte aus der Zwischenablage lassen sich auf einem Canvas einfügen. Figmas Werkzeugreferenz erläutert diese Ziele.

So verbindet Figma Claude Code mit dem Canvas

Für diesen Workflow wird der Remote-Server benötigt. Er ist unter https://mcp.figma.com/mcp erreichbar und funktioniert ohne die Figma-Desktop-App. Figma dokumentiert zwei Einrichtungswege: das bevorzugte Plugin und die manuelle Konfiguration. Einer davon genügt. Anleitung für den Remote-Server.

Empfohlen: das Figma-Plugin für Claude Code installieren

Ist Claude Code bereits installiert, wird im Terminal folgender Befehl ausgeführt:

claude plugin install figma@claude-plugins-official

Anschließend folgt die von Figma beschriebene Autorisierung:

1. Claude Code neu starten, falls es bereits lief.
2. /plugin eingeben, Installed öffnen, figma auswählen und die Autorisierung starten.
3. Im Browser für das Figma-Konto Allow access auswählen.
4. Zu /plugin zurückkehren und unter Installed prüfen, ob Figma als verbunden angezeigt wird.

Das Plugin enthält die MCP-Konfiguration und Skills, also wiederverwendbare Anweisungen für häufige Figma-Workflows. Blockiert die Organisation die Installation, verweist Figma an die zuständigen Claude-Administratoren. Figmas Einrichtungsanleitung für Claude Code.

Manuell: die Verbindung projektübergreifend einrichten

Für eine manuelle Einrichtung, die sich in mehreren Projekten nutzen lässt, dokumentiert Figma genau diesen Befehl:

claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp

Danach eine neue Claude-Code-Sitzung starten, /mcp eingeben, figma auswählen und zuerst Authenticate, dann Allow Access wählen. Die Verbindung lässt sich mit /mcp prüfen.

Das Flag --scope user macht die Verbindung projektübergreifend verfügbar. Figma dokumentiert außerdem claude mcp add --transport http figma https://mcp.figma.com/mcp; dieser Befehl gilt standardmäßig nur für das aktuelle Projekt. Manuelle Einrichtung und Geltungsbereich.

Welcher Figma-Tarif und welcher Seat sind erforderlich?

Für die Verbindung, das Anlegen von Frames und das Zurücklesen von Designs gelten unterschiedliche Voraussetzungen. Die folgenden Angaben stammen aus Figmas veröffentlichten Regeln und wurden am 12. Oktober 2026 geprüft:

Quellen: MCP-Verfügbarkeit, Berechtigungen für die Erfassung und Limits beim Auslesen.

Im Starter-Tarif sowie mit View- oder Collab-Seats stehen bis zu 20 lesende Werkzeugaufrufe pro Monat zur Verfügung. Ein Werkzeugaufruf ist eine einzelne Anfrage. Das Kontingent reicht daher nicht automatisch für 20 vollständige Durchläufe von Code zu Design und zurück. Das Erfassungswerkzeug generate_figma_design ist von den üblichen MCP-Anfragelimits ausgenommen. Lesekontingent und Ausnahme für die Erfassung.

Eine umfassendere Einordnung des Produkts und der Kaufentscheidung bietet unser Figma-Test.

Praxisbeispiel: ein Onboarding mit drei Bildschirmen

Angenommen, die App läuft bereits und ihr Onboarding besteht aus drei Bildschirmen: Willkommen, Teammitglieder einladen und Erstes Projekt. Dieses Beispiel führt den Ablauf von der Erfassung über die Designprüfung bis zur Umsetzung durch.

Den gesamten Ablauf in einer Datei erfassen

Zunächst wird das Projekt in Claude Code geöffnet. Der Prompt nennt die URL der App und das gewünschte Ziel, zum Beispiel:

Soll eine neue Datei entstehen, erhält Claude stattdessen diesen Auftrag. Läuft die App noch nicht, kann Claude den lokalen Server starten. Beim Erfassen bereitet der Client das benötigte Skript vor und öffnet den Browser. Sobald dieses Fenster geöffnet wird, erfolgt die erste Erfassung. Figmas Anleitung zur Erfassung.

Zunächst prüfen, ob der Bildschirm Willkommen vorhanden ist, dann den Ablauf in der App fortsetzen. Bei Teammitglieder einladen und Erstes Projekt jeweils Entire screen in der Erfassungsleiste verwenden. Für einen kleineren Ausschnitt steht Select element zur Verfügung. Zum Abschluss Open file wählen. Werkzeugleiste und Abschluss der Erfassung.

Meine Empfehlung: Bei diesem ersten Durchgang die Größe des Browserausschnitts konstant halten und festhalten, welcher Zustand erfasst wurde. Ein Bildschirm mit Validierungsfehler und derselbe Bildschirm mit gültigen Eingaben sollten unterschiedliche Namen bekommen.

Den Ablauf in Figma überarbeiten

Die Originalaufnahmen bleiben als Reihe erhalten; für Änderungsvorschläge wird diese Reihe dupliziert. Die Frames erhalten eindeutige Namen. Anschließend wird für jeden Bildschirm eine konkrete Entscheidung getroffen:

Diese Änderungen sind zunächst Designhypothesen. Eine gezeichnete Option zum Überspringen setzt insbesondere noch keine Berechtigungs- oder Routinglogik um. Die Entscheidung gehört als Notiz neben den freigegebenen Frame und in das Briefing für die Umsetzung.

Vor der Verwendung als Bausteine des Designsystems sollten die erfassten Ebenen geprüft werden. Laut Figma kommen sie als einfache Ebenen an, ohne automatische Zuordnung zu Komponenten oder Stilen der eigenen Bibliothek. Kompatible Variablen, also wiederverwendbare Werte wie Farben und Abstände, kann Figma aus der Datei oder einer hinzugefügten Bibliothek zuweisen. Für das Hinzufügen veröffentlichter Bibliotheken ist ein kostenpflichtiger Tarif erforderlich. Verhalten bei Erfassung und Variablenzuordnung.

Die freigegebenen Frames an Claude Code zurückgeben

Für jeden freigegebenen Frame per Rechtsklick Copy link to selection wählen. Die Links werden zusammen mit dem Umsetzungsauftrag in Claude Code eingefügt. So beschreibt Figma den Workflow mit dem Remote-Server. Verwendung von Frame-Links.

Ein brauchbares Briefing für dieses Beispiel lautet:

Figmas Werkzeug get_design_context liefert dem Agenten Designinformationen. Im Prompt lassen sich das Framework und das Verzeichnis der vorhandenen Komponenten angeben. Beim Remote-Server müssen Links zu Frames oder Ebenen übergeben werden. Eine bloße Auswahl auf dem Canvas liefert ihm noch keinen Kontext. Werkzeuge für die Umsetzung von Design in Code.

Zum Schluss die aktualisierte App starten und denselben Ablauf durchgehen. Zuerst Layout und Texte vergleichen, dann das Überspringen, die Validierung und die Tastaturbedienung prüfen. Wenn eine weitere Designprüfung sinnvoll ist, werden die überarbeiteten Bildschirme erneut erfasst. Diese Kontrolle liegt beim Team: Figma liefert den Kontext, der Coding-Agent erstellt die Implementierung. Die jeweiligen Aufgaben von MCP und Agent.

Fünf Einsatzfälle, in denen sich der Workflow lohnen könnte

Ein guter Ausgangspunkt sind bestehende Oberflächen, über die mehrere Personen gemeinsam entscheiden müssen. Die folgenden Vorschläge sind danach geordnet, wie unmittelbar sie doppelte Arbeit verringern könnten.

Für Teams, die wiederverwendbare Designanweisungen systematisieren möchten, bietet unser Designsystem-Paket mit Custom Skills für Figma Make ergänzende Lektüre zu diesem eigenständigen Figma-Make-Workflow.

Wirtschaftlichkeit: den Aufwand für den Nachbau messen

Entscheidend sind die Kosten für die Vorbereitung der Designprüfung und für wiederholte Implementierungsarbeit. Baut das Team bereits entwickelte Bildschirme bislang vor der Prüfung nach, sollte dieser Aufwand mit Erfassung und Nachbearbeitung verglichen werden:

Nettonutzen pro Prüfung = (bisherige Stunden für Vorbereitung und Nacharbeit − neue Stunden für Erfassung, Bereinigung und Nacharbeit) × interner Stundensatz − zusätzliche Toolkosten.

Grundlage sind die tatsächlich erfassten Arbeitszeiten. Zusätzliche Prüfungen der Implementierung, die durch den Workflow entstehen, müssen ebenfalls einfließen. Nutzt ein Team Claude Code und die erforderlichen Figma-Seats bereits, stehen die bestehenden Abonnements auf beiden Seiten des Vergleichs. Nur zusätzliche Ausgaben verändern das Ergebnis. Figma unterscheidet zwischen den Zugriffsrechten eines Seats und Dateiberechtigungen. Die Kosten des Professional-Abonnements hängen von der Anzahl der Seats und dem Abrechnungszeitraum ab. Figmas Erläuterung zur Abrechnung.

Meine Entscheidungsregel: Der Workflow bleibt, wenn das Team damit bei insgesamt geringerem Design- und Entwicklungsaufwand zu einer freigegebenen Änderung gelangt. Ein schnellerer Import, der umfangreiche Nachbearbeitung erfordert, bringt wenig.

Zwei klar umrissene Produktideen

Eine sinnvolle Geschäftsmöglichkeit liegt darin, den Prüfprozess rund um die vorhandene Verbindung als Angebot zu gestalten. Die folgenden Ideen sind Produkthypothesen. Die am 12. Oktober 2026 geprüften DataForSEO-Schätzungen für englischsprachige Suchanfragen in den USA zeigen monatliche Suchanfragen, keine zahlenden Kunden.

Die stärkste Idee: ein Paket für Onboarding-Reviews

Ein Produktteam oder eine kleine Agentur könnte für ein wiederholbares Verfahren zahlen, das aus einem laufenden Onboarding eine strukturierte Prüfung und ein Umsetzungsbriefing macht. Benachbarte Nachfragesignale sind 590 monatliche Suchanfragen nach „claude code to figma“ und 260 nach „website to figma“. Diese Zielgruppen können sich überschneiden.

Die kleinste sinnvolle Version könnte aus einer projektspezifischen Checkliste für die Erfassung, einer Vorlage für die Figma-Prüfung, Namenskonventionen für Frames und wiederverwendbaren Prompts bestehen, die freigegebene Frame-Links mit Entscheidungen zum Verhalten verknüpfen. Ein begleiteter Service eignet sich als Einstieg, um zu beobachten, an welchen Stellen Teams Unterstützung brauchen.

Dies ist die stärkste der Ideen, weil das Ergebnis Entscheidungen zum konkreten Ablauf des Kunden umfasst. Der Haken: Die Erfassung liefert Figma bereits. Ein Angebot, das lediglich den Import verpackt, bietet daher wenig Mehrwert. Ob Kunden für das Review-Paket zahlen würden, muss weiterhin validiert werden.

Ein Prüfwerkzeug für Umsetzungsbriefings

Ein Team, das regelmäßig Figma-Änderungen an Claude Code übergibt, könnte ein kleines Prüfwerkzeug nutzen. Es würde vor der Umsetzung auf fehlende Frame-Links, unklare Navigationsziele und fehlende Komponentenvorgaben hinweisen. Für „Figma to code“ werden 720 monatliche Suchanfragen geschätzt. Das ist ein breites Signal für die zugrunde liegende Aufgabe, kein Nachweis der Nachfrage nach diesem Prüfwerkzeug.

Die kleinste Version könnte ein strukturiertes Briefing mit freigegebenen Links, Komponentenpfaden und Abnahmekriterien prüfen und eine Liste offener Fragen ausgeben. Die Schwierigkeit liegt in der Bedeutung: Das Werkzeug kann melden, dass eine Beschreibung der Regel zum Überspringen fehlt. Ob Nutzer den Schritt überspringen dürfen, kann es aber nicht entscheiden. Diese Entscheidung bleibt beim Produktverantwortlichen.

Wo der Weg von Code zu Design und zurück an Grenzen stößt

Dieser Workflow ist ein bewusst durchlaufener Zyklus aus Erfassung, Bearbeitung und Umsetzung. Figma beschreibt MCP als Quelle strukturierten Designkontexts und als Ausgangspunkt für Code. Der Agent benötigt weiterhin die Konventionen des Projekts und klare Anweisungen. MCP garantiert weder fertigen Code noch die automatische Behebung von Implementierungsproblemen. Figmas Erklärung dieser Grenze.

Auch die Qualität der Erfassung schwankt. Figma nennt aufwendige JavaScript-Animationen, Canvas-Rendering und virtualisierte Listen als mögliche Problemstellen. Letztere rendern jeweils nur einen Ausschnitt einer langen Liste. Wenn die ganze Seite nur unzureichend übernommen wird, kann die Erfassung eines einzelnen Elements helfen. Unkenntlich gemachte CSS-Variablennamen können außerdem die Variablenzuordnung verhindern. Bei einer Erfassung vom Entwicklungsserver bleiben lesbare Namen möglicherweise erhalten. Bekannte Grenzen der Erfassung.

Für eine triviale Textkorrektur ohne Designentscheidung würde ich mir diesen Umweg sparen. Sinnvoll ist er, wenn der Vergleich des gesamten Ablaufs voraussichtlich beeinflusst, was das Team baut. Passt schon das gemeinsame Arbeiten auf dem Figma-Canvas nicht zum Team, hilft unser Vergleich der Figma-Alternativen bei der grundsätzlicheren Auswahl.

Der nächste Schritt für Montag: ein Onboarding mit drei Bildschirmen auswählen, erfassen, eine Verbesserung vereinbaren und diese Entscheidung in der App umsetzen. Erst diesen Kreislauf abschließen, bevor der Prozess auf den Rest des Produkts ausgeweitet wird.

Soll dieser Prüfprozess auf das Produkt des eigenen Teams zugeschnitten werden, helfen wir bei der Automatisierung.