Workflow-Lab: Wechsel zwischen Design und Code mit Agenten
Coding-Agenten verändern die Arbeitsweise von Entwickler*innen. Sie sind aber nur so gut wie die Eingaben, die sie erhalten. Mit diesem Workflow bleiben Code und Arbeitsfläche durch Kontext synchron.
Workflow-Lab: Wechsel zwischen Design und Code mit Agenten teilen
Hero-Illustration von Marine Buffard
Willkommen im Workflow-Lab, wo wir einen Beispiel-Workflow mit Figma-Produkten und -Tools präsentieren.
Fact Sheet zum Workflow:
Figma-Produkte: Figma Design, FigJam
Tools: Figma MCP-Server, Code Connect, use_figma, generate_diagram, search_design_system, generate_figma_design, get_variable_defs
Team: Produktdesigner*innen, Designsystem-Veranwortliche*r, Softwareentwickler*innen
Fragestellung: Was wäre, wenn die Ausgabe deines Coding-Agenten früher produktionsreif sein könnte?
Das Entwicklungsteam für Radicle, eine fiktive MINT-Lern-App, kommt schneller voran denn je. Aufgaben, die früher Wochen in Anspruch nahmen, dauern jetzt Tage oder sogar Stunden. Dennoch bringt sie diese Geschwindigkeit nicht weit: Ihr KI-generierter Code weicht meist von den Designvorgaben ab. Das Team stellt seinem Coding-Agenten Screenshots und Entwicklungstickets zur Verfügung. Dennoch erhalten sie nicht die richtigen Ausgaben, sodass das Team Zeit für das Überarbeiten aufwenden muss.
Was wäre, wenn der erste KI-Durchlauf näher an ein produktionsreifes Ergebnis herankäme? Wenn ein Coding-Agent mehr Designkontext zur Verfügung gestellt bekommt (z. B. genehmigte Komponenten und Token, die in Figma dokumentiert sind) kann er deine Absicht in weniger Prompts umsetzen. In diesem Beispiel-Workflow verwenden Entwickler*innen bei Radicle Figma-Entwickler-Tools, um ihrem Coding-Agenten besseren Kontext zu geben, damit er besseren Code generieren kann. Hier erfährst du, wie die Entwickler*innen sicherstellen, dass Design und Code für das neue Feature synchron bleiben – vom ersten Wireframe bis zur finalen Überprüfung.
Das Problem
Das Radicle-Team möchte den Posteingang aktualisieren, in dem Schüler*innen Lehrkräften und Mitschüler*innen Nachrichten senden können. Für den ersten Schritt planen sie, einen neuen Flow für Massenupdates hinzuzufügen, der drei Oberflächen haben wird: eine Symbolleiste, ein Modal und eine Toast-Nachricht (eine temporäre Benachrichtigung). Über die Symbolleiste können Benutzer*innen alle ihre Nachrichten auswählen, Nachrichten löschen oder als ungelesen markieren. Mit dem Modal werden Benutzer*innen aufgefordert, die Aktion zu bestätigen oder abzubrechen. Und die Toast-Nachricht informiert darüber, ob die Aktion erfolgreich war, und bietet eine Option an, mit der sie rückgängig gemacht werden kann.
Die Teamdesigner*innen erstellen jeden Bildschirm in Figma Design, und die Entwickler*innen des Projekts stellen diese Designs dem Codierungs-Agenten zur Verfügung. Sie erhalten schnell Code zurück – aber die UI passt nicht zum Design. Die Icons passen nicht, die Abstände im Modal sind ungleichmäßig und in der Toast-Nachricht fehlt der Fehlerzustand. Die Entwickler*innen könnten den Nachmittag damit verbringen, das Design neu zu bearbeiten. Stattdessen treten sie einen Schritt zurück und beginnen mit den Entwickler-Tools von Figma von vorne.
Vor dem Prompting planen
Bevor die Entwickler*innen mit dem Schreiben von Code beginnen, skizzieren sie das beabsichtigte Verhalten der Bildschirme, die Zustände und die Übergänge, die den neuen Flow für Massenupdates definieren. Sie übergeben diese Details an den Agenten, zusammen mit der PRD und dem Code für die Komponenten, die den Posteingang derzeit ausmachen. Mit dem generate_diagram-Tool und dem MCP-Server von Figma erstellen die Entwickler*innen dann ein bearbeitbares Diagramm in FigJam, das den Flow auf den drei Oberflächen veranschaulicht:
- Die „Alle auswählen“-Option in der Symbolleiste wählt alle Nachrichten aus.
- Die „Löschen“-Option öffnet das Modal zur Bestätigung.
- Die „Rückgängig machen“-Schaltfläche in der Toast-Nachricht setzt das Dashboard in seinen vorherigen Zustand zurück.
Das Diagramm bietet zusätzlichen Kontext, auf dem der Agent aufbauen kann, während des Team auch eine Reaktionsmöglichkeit erhält, bevor die Entwicklung beginnt. Die Entwickler*innen teilen das FigJam mit dem Designteam und der Designsystem-Verantwortlichen. Diese geben ihr Feedback direkt auf dem Diagramm, anstatt in einem Slack-Thread.
Dem Agenten ein System zum Erstellen geben
Sobald alle ihr Okay gegeben haben, geben die Entwickler*innen das FigJam-Diagramm über den MCP-Server von Figma an den Coding-Agenten, damit der Agent Zugriff auf die Komponenten, Token und Layouts im Radicle-Designsystem erhält.
Wenn den Entwickler*innen nur einen Screenshot zur Verfügung stehen würde, müssten sie im Code nach der richtigen Komponente suchen oder das Designteam kontaktieren, um Details zu klären: Ist dieser 12px-Abstand der richtige Abstands-Token, handelt es sich bei der Schaltfläche um die sekundäre Schaltfläche aus dem Repository oder verwendet das Modal in neues Muster oder etwas, das das Team bereits ausgeliefert hat? Stattdessen sind alle diese Antworten über den MCP-Server von Figma bereits in der Datei enthalten, sodass dem Agenten der gesamte benötigte Designkontext zur Verfügung steht.
Das Designsystem mit Code verbinden
Es genügt nicht zu wissen, welche Komponente verwendet werden soll. Wichtig ist, wie sie aufgebaut ist. Dieser Teil stammt von Code Connect und wird von der Designsystem-Verantwortlichen von Radicle eingerichtet. Ausgehend von Figma verbindet sie die Bibliothek mit dem GitHub-Repository des Teams, sodass jede Komponente auf die Datei verweist, die sie implementiert. Dann schreibt sie Vorlagendateien für Komponenten wie Schaltflächen, Icons und Modal im Code-Repository, wobei sie Figma-Eigenschaften Code-Eigenschaften zuordnet.
Jetzt prompten die Entwickler*innen den Agenten, basierend auf der Figma-Auswahl zu generieren, und Code Connect identifiziert, welche Komponente importiert werden soll. Anstatt Zeit und Credits mit dem Schreiben von neuem Code zu verschwenden, beginnt der Agent mit dem bereits vorhandenen Implementierungsentwurf.
Die Massenupdate-Auswahlstatus ist aber neu und damit das einzige Element, das Code Connect nicht zuordnen kann. Bevor er den Status von Grund auf neu erstellt, prompten die Entwickler*innen search_design_system, damit der Agent die Figma-Bibliotheken des Teams nach einer vorhandenen Auswahlkomponente durchsucht. Der Agent identifiziert eine ähnliche Komponente aus einer Funktion, die das Team vor einigen Monaten veröffentlicht hat. Basierend darauf findet der Agent diese Komponente im Code-Repository und passt sie an den Massenupdate-Flow an. Das Ergebnis ist markenkonform und mit dem Rest der Radicle-App konsistent. Zudem musste der Agent kein Muster mehr erfinden, das das Team schon erstellt hat.
Abweichungen erkennen, bevor sie entstehen
Die Entwickler*innen beginnen mit der Programmierung des Bestätigungsmodals. Doch während sie daran arbeiten, nimmt das Designteam zwei Änderungen vor: Das Modal soll eine dunklere Markenfarbe haben und die Schaltfläche hat einen neuen Eckenradius. Die Designer*innen veröffentlichen das Update in der Radicle-Bibliothek und markieren die Änderungen in einem Ticket. Anstatt die Änderungen manuell vorzunehmen, bitten die Entwickler*innen den Agenten, auf Abweichungen zu prüfen.
Sie prompten get_variable_defs im Coding-Agenten. Dies gibt die im Modal verwendeten Variablen zurück, die jetzt die Änderungen des Designerteams widerspiegeln. Der Agent vergleicht diese mit den Token im Code, findet beide Unterschiede sofort und aktualisiert das Modal.
Der Weg zur Produktion
Die Entwickler*innen haben die Symbolleiste, die Nachrichtenauswahlzustände und das Bestätigungsmodal abgeschlossen und dafür jeweils Komponenten verwendet, die das Team bereits pflegt. Jetzt fehlt noch die Toast-Nachricht, die während des Builds erstellt wurde und bisher nur im Code existiert. Der Fehlerzustand fehlt weiterhin. Die Entwickler*innen prompten use_figma, damit die Toast-Nachricht als bearbeitbare Ebenen auf der Arbeitsfläche platziert wird, und die Designer*innen fügen den fehlenden Status mit einer „Wiederholen“-Aktion hinzu. Anschließend veröffentlicht die Designsystem-Verantwortliche die neue Komponente und ordnet sie mit Code Connect dem Code zu. Die Toast-Nachricht funktioniert jetzt wie alle anderen Komponenten in der Bibliothek von Radicle.
Von hier aus verläuft alles wie bei jeder anderen Veröffentlichung. Die Entwickler*innen öffnen eine Pull-Anfrage, und der Unterschied besteht hauptsächlich in der Feature-Logik. Die Entwickler*innen überprüfen den Code und die Designer*innen überprüfen den Build in einer Vorschau.
Der MCP-Server von Figma und Code Connect geben dem Agenten Zugang zu demselben System, mit dem alle arbeiten. Dadurch kann das Team sich auf die Details konzentrieren, die die Benutzererfahrung prägen, anstatt KI-generierten Code erneut bearbeiten zu müssen. Wenn mehr Zeit für die Erstellung zur Verfügung steht, wird die Arbeit nicht nur beschleunigt, sondern es werden auch bessere Ergebnisse erzielt.
Gib deinem Agenten besseren Kontext, indem du den MCP-Server von Figma installierst und ihn mit dem Coding-Agenten deiner Wahl verbindest. Richte Code Connect für die Komponenten ein, die dein Team am häufigsten wiederverwendet.
Lies alle unsere Blogbeiträge der Workflow-Lab-Reihe, um weitere Arbeitsweisen in Figma kennenzulernen.