Schluss mit Augenmaß: In 3 Schritten von Figma zu verifiziertem Code
Die meisten UIs entstehen immer noch so: Man schaut sich ein Design an und baut es nach Augenmaß nach. Das Ergebnis sieht ähnlich aus, aber kleine Unterschiede bei Abständen, Farben oder Schriftstärke übersieht man leicht. KI-Agenten machen das schneller, aber wenn du ihnen nur einen Screenshot gibst, raten sie auch.
In diesem Beitrag zeigen wir dir einen einfachen Workflow, der das in drei Schritten vermeidet: das Design als Daten auslesen, nach einer schriftlichen Spezifikation bauen und das Ergebnis im Browser prüfen. Wir haben ihn an einem kostenlosen
Was ist ein MCP-Server?
Mit MCP muss der Agent nicht anhand eines Screenshots oder einer Beschreibung raten. Er fragt das Tool und bekommt echte Daten zurück. Dieser Workflow nutzt zwei MCP-Server: einen zum Auslesen des Designs und einen zum Prüfen des Ergebnisses.
Was du brauchst
-
Claude Code -
Einen Figma-MCP-Server, damit der Agent das Design lesen kann. Mit einem kostenpflichtigen Figma-Plan nutzt du das offizielle
Figma-Plugin für Claude Code Figma Linux Next -
Den
Chrome-DevTools-MCP-Server -
Deine App lokal gestartet, zum Beispiel auf
localhost:3000.
Wenn du Figma Linux Next nutzt, öffne die Settings, geh zum Tab Integrations und aktiviere Figma MCP. Der Server läuft standardmäßig auf Port 3845 und liest die Datei im aktiven Tab. Lass dein Design also in der App geöffnet.
Verbinde die Server mit Claude Code:
# Figma: offizielles Plugin...
claude plugin install figma@claude-plugins-official
# ...oder der lokale Server von Figma Linux Next
claude mcp add --scope user --transport http figma http://127.0.0.1:3845/mcp
# Chrome DevTools
claude plugin marketplace add ChromeDevTools/chrome-devtools-mcp
claude plugin install chrome-devtools-mcp@chrome-devtools-pluginsPlugins werden für deinen Benutzer installiert und funktionieren daher in jedem Projekt. claude mcp add fügt einen Server standardmäßig nur zum aktuellen Projekt hinzu. Mit --scope user ist er in all deinen Projekten verfügbar.
Ob alles verbunden ist, prüfst du mit claude mcp list. Mit Figma Linux Next sollten beide Server als verbunden erscheinen. Deine Liste kann auch weitere Server enthalten:
Checking MCP server health…
figma: http://127.0.0.1:3845/mcp (HTTP) - ✔ Connected
plugin:chrome-devtools-mcp:chrome-devtools: npx chrome-devtools-mcp@latest - ✔ Connected1. Das Design als Daten auslesen
Mit dem Figma-MCP-Server liest der Agent die Datei direkt aus: Größen, Abstände, Farben und Schriften.
Klick in Figma mit der rechten Maustaste auf die Ebene, wähle Copy/Paste as und dann Copy link to selection. Der Link enthält die node-id, so weiß der Agent genau, was er lesen soll.
Dann gibst du dem Agenten den Link:
Read this node from Figma: <link to the "Earning" stats row>
Write the sizes, spacing, colors and typography into design-spec.md,
and save a PNG export of the node.
Report anything you could not read instead of estimating it.Das ist der Export des Nodes, den der Agent gespeichert hat. Schau genau hin: Die Avatare unter „Active Now" fehlen. Darauf kommen wir in Schritt 3 zurück.
Und das ist ein kurzer Auszug aus der design-spec.md, die er geschrieben hat:
Die letzte Zeile des Prompts ist die wichtigste. Der Agent hat vier Dinge aufgelistet, die er nicht lesen konnte. Das ist wichtig, weil sich ein fehlender Wert später leicht prüfen lässt. Ein geschätzter Wert sieht richtig aus, deshalb prüft ihn niemand.
2. Nach der Spezifikation bauen
Danach lässt du den Agenten den Code nur anhand von design-spec.md schreiben, nicht anhand von Figma.
Implement the stats row from design-spec.md. Do not call Figma.
If a value is missing, choose one and mark it as an assumption in the code.Jeder Wert im Code ist jetzt eine Messung oder eine markierte Annahme. Für den Verlauf der Icons stand zum Beispiel kein CSS-Winkel in der Spezifikation. Der Agent hat ihn aus der Matrix berechnet und markiert:
{/* ASSUMPTION: 339deg derived from the gradientTransform recorded in design-spec.md. */}
<div className="flex size-[84px] items-center justify-center rounded-full
bg-linear-[339deg,var(--color-stat-icon-from),var(--color-stat-icon-to)]">In der Statistikzeile gab es zwei solche Kommentare: den Winkel des Verlaufs und die Schriftstärke des Trendtexts. Vor dem Review kannst du im Code nach ASSUMPTION suchen und siehst alle Annahmen an einer Stelle.
3. Im Browser prüfen
Zum Schluss lässt du den Agenten die App in Chrome öffnen, dieselbe Bildschirmgröße wie das Design nutzen und beides vergleichen.
Open the app in Chrome at 1440x1198 and take a screenshot.
Compare it with an export of the whole Figma frame, not only the node.
Report the differences, then fix them.Wir vergleichen bewusst mit dem ganzen Frame. Der Export des Nodes zeigt nur, was der Agent in Schritt 1 gelesen hat. Was fehlt, sieht man darin nicht.
Das ist ein kurzer Auszug aus dem Bericht des Agenten:
Compared at 1440x1198 against the export of the whole Figma frame.
Matches: card 968x151, radius 30, shadow, icon circles 84px,
labels 14px #acacac, values 32px #333333, dividers 87x1 #f0f0f0.
Differences:
1. The avatar stack under "Active Now" is missing (5 avatars, 26px).
It is outside the "Earning" group, so it is not in the spec.
2. The trend percentage is lighter than in the design
(code: Medium 500, design looks SemiBold).
3. The cards are about 1px narrower than in Figma (216.95 vs 218px),
because their width follows the text.
Die erste Version sah richtig aus, aber unser Vergleich hat zwei sichtbare Unterschiede gefunden. Beide sind in der letzten Zeile oben behoben:
-
Fehlende Avatare. In Figma liegen sie außerhalb der Ebene, die wir verlinkt haben. Deshalb hat der Agent sie nie gelesen. Tipp: Verlinke den ganzen Bereich, den du bauen willst, nicht nur eine Gruppe.
-
Falsche Schriftstärke. Die Stärke der Prozentzahl war eine unserer Annahmen. Der Vergleich hat gezeigt, dass sie zu dünn war.
In der Spezifikation waren diese Fehler nicht sichtbar. Wir haben sie erst beim Vergleich mit dem Design gefunden.
So sieht das Ergebnis im Browser aus:
Das Ergebnis
-
Eine Review-Runde. Der erste Vergleich hat die zwei sichtbaren Unterschiede gefunden. Eine Korrektur hat beide behoben, und der zweite Vergleich hat keine sichtbaren Unterschiede mehr gezeigt.
-
Nah am Design. Nach der Korrektur stimmen Karte, Icons, Text und Avatare mit dem Design überein. Übrig bleiben nur Abweichungen von etwa 1px: die Breite der Karten und die vertikale Position der Zeile. Die haben wir akzeptiert.
-
Zeit. Für einen Abschnitt wie diesen brauchst du von Hand normalerweise etwa eine Stunde: das Design in Figma ausmessen, den Code schreiben und das Ergebnis nach Augenmaß vergleichen. Mit diesem Workflow übernimmt der Agent diese Arbeit, und die Prüfungen dauern nur Minuten. In unserem Durchlauf hat der Vergleich etwa eine Minute gedauert, die Korrektur beider Unterschiede samt erneuter Prüfung etwa vier Minuten.
-
Eine Spezifikation für später. Die
design-spec.mdbleibt im Projekt. Die nächste Person kann den nächsten Teil des Dashboards bauen, ohne Figma erneut auszulesen.
Fazit
Dieser Workflow lohnt sich vor allem, wenn du ein Design genau umsetzen musst, zum Beispiel für ein Design-System oder ein Kundenprodukt. Für schnelle Prototypen oder Designs, die sich noch täglich ändern, ist er weniger nützlich.
Er hat auch Grenzen:
-
Er hängt von der Figma-Datei ab. Der Agent liest die Ebenen so, wie sie sind. Elemente außerhalb der verlinkten Gruppe, gemischte Textstile oder fehlende Design-Tokens hinterlassen Lücken.
-
Er braucht weiterhin ein menschliches Review. Der Agent markiert seine Annahmen, aber jemand muss sie prüfen. Der finale Vergleich ist ein guter Startpunkt.
-
Er prüft nur eine Bildschirmgröße. Wir haben nur die Desktop-Größe verglichen. Mobile Layouts, Hover-Zustände und echte Daten brauchen eigene Prüfungen.
Der Agent übernimmt die repetitive Arbeit: Ebenen auslesen, CSS schreiben und Screenshots machen. Du prüfst die Spezifikation, die Annahmen und den finalen Vergleich.
