Figma Make bringt die visuelle Bearbeitung näher an den echten Code heran

Der Abstand zwischen Design Und die Entwicklung war schon immer einer der kostspieligsten Schwachpunkte in der Softwareentwicklung. Ein Designer entwirft eine Benutzeroberfläche. Ein Entwickler setzt diese in Code um. Die Umsetzung fällt dann etwas anders aus. Der Designer gibt Feedback. Der Entwickler nimmt Anpassungen vor. Ein weiterer Sonderfall taucht auf. Der Kreislauf setzt sich fort.

Das neueste Update von Figma für „Make“ ist ein Versuch, diesen Kreislauf zu verkürzen. Nach Angaben des Unternehmens können Nutzer „Make“ nun mit einer lokalen Codebasis verbinden, Elemente visuell auswählen, Eigenschaften wie Layouts, Farben, Schriftarten oder Größen anpassen und den Agenten den entsprechenden Code finden und die Änderung übernehmen lassen. Die Funktion unterstützt zudem die Bereitstellung von Änderungen aus „Make“ heraus, wodurch sie über die Prototypenerstellung hinausgeht und in den sensibleren Bereich der Bearbeitung echter Software vordringt.

Das bedeutet nicht, dass Designer plötzlich Ingenieure ersetzen. Es bedeutet auch nicht, dass jede visuelle Änderung die Überprüfung durch die Entwickler umgehen sollte. Sinnvoller ist es, das Update folgendermaßen zu verstehen: Figma versucht, den Zugang zur Codebasis genau an der Stelle zu verbessern, an der Designentscheidungen getroffen werden.

Für Produktteams könnte das von großer Bedeutung sein.

Der alte Hand-off steht unter Druck

Die Übergabe vom Design an die Entwicklung hat sich im Laufe der Jahre verbessert, ist jedoch nie vollständig verschwunden. Designsysteme, Komponentenbibliotheken, Tokens, Prüftools und eine bessere Zusammenarbeit haben zwar geholfen, doch viele Teams verlieren immer noch Zeit dabei, die Absicht in die Umsetzung zu übertragen.

Das Problem besteht selten darin, dass Designer und Entwickler nicht miteinander kommunizieren. Vielmehr arbeiten sie auf unterschiedlichen Ebenen. Designer gestalten die Benutzeroberfläche visuell. Entwickler bearbeiten den zugrunde liegenden Code. Jede Seite sieht nur einen Teil der Wahrheit.

Das führt zu den bekannten Reibungspunkten. Eine Änderung der Abstände, die in einer Designdatei geringfügig erscheint, kann mit einer gemeinsam genutzten Komponente verknüpft sein. Bei einer Farbanpassung müssen möglicherweise Design-Tokens berücksichtigt werden. Der Zustand einer Schaltfläche kann von Barrierefreiheitsregeln, der Responsivität, der Fehlerbehandlung oder der Produktlogik abhängen. Eine Seite, die in einem Viewport korrekt dargestellt wird, kann in einem anderen Viewport Fehler aufweisen.

Die Local-Code-Integration von Figma Make ist interessant, weil sie versucht, diese beiden Welten einander näherzubringen. Anstatt den Designer zu bitten, eine Änderung zu beschreiben und darauf zu warten, dass jemand anderes die richtige Datei findet, ermöglicht das Tool dem Nutzer, direkt auf die Benutzeroberfläche zu zeigen und die Änderung anzufordern. Der Agent liest dann den Code-Kontext aus und wendet die Änderung an.

Das ist ein anderer Arbeitsablauf als die bloße Erstellung eines Prototyps anhand einer Vorgabe.

Die visuelle Bearbeitung wird zu einer ernsteren Angelegenheit, sobald sie den Produktionscode betrifft

Figma Make ist bereits Teil der allgemeinen Entwicklung im Bereich der KI-gestützten App-Entwicklung, bei der Nutzer anhand von Eingaben in natürlicher Sprache und Designvorlagen Prototypen oder funktionsfähige Apps erstellen können. Der neue Schritt ist von größerer Tragweite, da er eine Anbindung an bestehende Codebasen ermöglicht. The Verge beschrieb das Update so, dass es Teams nun ermöglicht, Figma Make als visuelle Oberfläche für die Entwicklung und Bearbeitung echter Software zu nutzen, anstatt nur Prototypen zu entwerfen.

Das verändert das Risikoprofil.

Ein erstellter Prototyp kann zwar unvollkommen sein, aber dennoch nützlich. Er hilft einem Team dabei, ein Konzept zu erproben. Eine Änderung an einer echten Codebasis muss hingegen höheren Anforderungen genügen. Dabei müssen Architektur, die Wiederverwendung von Komponenten, Barrierefreiheit, Zustandsverwaltung, Reaktionsfähigkeit, Tests, Namenskonventionen und die Regeln des Design-Systems berücksichtigt werden.

Hier kann die visuelle Code-Bearbeitung ihre Stärken ausspielen – allerdings nur, wenn der Agent das umgebende System versteht. Eine einfache Änderung der Farbe oder des Abstands ist eine Sache. Eine Layoutänderung, die sich auf wiederverwendbare Komponenten über mehrere Seiten hinweg auswirkt, ist eine andere. Eine visuelle Oberfläche mag den Eindruck vermitteln, dass die Änderung lokal begrenzt ist, während die Codeänderung möglicherweise weitreichendere Folgen hat.

Deshalb ist der Entwickler-Workflow nach wie vor von Bedeutung. Visuelle Bearbeitungen erfordern eine Überprüfung, Versionskontrolle und die Möglichkeit, genau zu sehen, was sich geändert hat. Eine solide Implementierung sollte einen Pull-Request erstellen, den Diff anzeigen, die Branch-Workflows berücksichtigen und es den Entwicklern ermöglichen, die Änderung anzunehmen, abzulehnen oder zu ändern.

Wenn das Tool diesen Bereich unterstützt, könnte dies unnötigen Hin- und Her-Aufwand reduzieren. Ist dies nicht der Fall, könnte es neue Arten von Aufräumarbeiten nach sich ziehen.

Die Rolle des Designers beginnt sich zu wandeln

Für Designer liegt der Reiz auf der Hand. Viele Designentscheidungen sind visuell und präzise. Designer erkennen, wenn ein Layout nicht stimmt, wenn die Abstände falsch sind, wenn ein Element nicht der beabsichtigten Hierarchie entspricht oder wenn die implementierte Benutzeroberfläche vom Designsystem abweicht.

Bislang mussten sie diese Probleme oft indirekt kommunizieren: eine Anmerkung, ein Screenshot, ein Ticket, eine Slack-Nachricht, eine QA-Notiz. All das verursacht Reibungsverluste. Die visuelle Bearbeitung bietet dem Designer eine direktere Möglichkeit, die Korrektur darzustellen.

Das bedeutet nicht, dass jeder Designer zum Softwareentwickler werden muss. Es erfordert jedoch ein stärkeres Bewusstsein für Code. Designer, die Tools wie Figma Make nutzen, müssen verstehen, dass eine Benutzeroberfläche nicht nur das ist, was auf dem Bildschirm erscheint. Sie ist auch ein System aus Komponenten, Einschränkungen, Tokens und Verhaltensweisen. Die besten Designer werden sich möglicherweise zunehmend daran gewöhnen, in Implementierungsbegriffen zu denken, ohne dabei unbedingt selbst Code schreiben zu müssen.

Dies könnte dazu führen, dass die Rolle des Designers an Einfluss gewinnt – nicht, weil er die Technik umgeht, sondern weil er direkter in die Umsetzungsebene eingebunden ist.

Dies könnte auch dazu führen, dass sich die Art der Arbeit ändert, mit der sich Designer beschäftigen. Es werden möglicherweise weniger Stunden für die Dokumentation kleiner visueller Korrekturen aufgewendet. Stattdessen könnte mehr Zeit in die Interaktionsqualität, die Produktlogik, die Barrierefreiheit, die Inhaltshierarchie und das systemische Denken fließen.

Entwickler könnten dies begrüßen – oder sich dagegen wehren

Die Reaktion der Entwickler wird davon abhängen, wie sich das Tool in der Praxis bewährt.

Wenn Figma Make saubere, überprüfbare Änderungen erzeugt, die die bestehende Codebasis berücksichtigen, könnten Entwickler dies begrüßen. Kleine visuelle Korrekturen, die Anpassung an das Designsystem und sich wiederholende UI-Anpassungen können mühsam sein. Wenn ein Agent diese Aufgaben gut bewältigt, können sich die Entwickler auf Architektur, Leistung, Logik, Datenflüsse, Tests und technisch anspruchsvollere Aufgaben konzentrieren.

Wenn der Agent jedoch unübersichtliche Diffs erzeugt, bestehende Muster ignoriert oder Änderungen vornimmt, die zwar optisch richtig aussehen, aber die Codebasis schwächen, werden sich die Entwickler dagegen wehren. Und das sollten sie auch.

Die Geschichte der Design-to-Code-Tools ist geprägt von überzogenen Versprechungen. Viele Tools liefern Ergebnisse, die in einer Demo zwar akzeptabel aussehen, in einem echten Produkt jedoch schwer zu warten sind. Jüngste Untersuchungen zu automatisierten Figma-to-Code-Workflows haben ergeben, dass selbst leistungsstarke Modelle trotz verbesserter visueller Genauigkeit Probleme mit der Reaktionsfähigkeit des Layouts und der Wartbarkeit des Codes haben können.

Das ist der Standard, den Figma Make erfüllen muss. Visuelle Genauigkeit allein reicht nicht aus. Der Code muss fest in das Produkt integriert sein.

Die tatsächlichen Chancen sind geringer als der Hype vermuten lässt, aber dennoch wertvoll

Die schwächste Interpretation dieser Geschichte lautet, dass Figma Make die Softwareentwicklung über Nacht “revolutionieren” wird. Das wird wahrscheinlich nicht der Fall sein.

Die leistungsstärkere Version ist praktischer. Figma Make könnte den Aufwand bei bestimmten Arten von Frontend-Änderungen verringern: Anpassung von Abständen, Typografie, Farben, Layoutdetails, Komponentenvarianten, responsivem Verhalten oder kleinen Verfeinerungen der Benutzeroberfläche. Genau das sind die Änderungen, die viel Zeit in Anspruch nehmen können, da sie sich zwischen gestalterischen Entscheidungen und Implementierungsdetails bewegen.

Wenn diese Änderungen schneller umgesetzt werden, können Teams ausgereiftere Produkte mit geringerem Koordinationsaufwand auf den Markt bringen. Designer können Ideen in einer realistischeren Umgebung testen. Entwickler können konkrete Codeänderungen überprüfen, anstatt vages Feedback interpretieren zu müssen. Produktmanager können frühzeitig Versionen von Funktionen sehen, die der Realität näher kommen.

Das Tool kann auch bei der Pflege von Design-Systemen nützlich sein. Wenn ein Team ein visuelles Muster an vielen Stellen anwenden muss, könnte ein KI-Agent mit Kontext zur Codebasis dabei helfen, relevante Komponenten zu identifizieren und diese konsistenter zu aktualisieren als bei einer manuellen Bearbeitung einzelner Tickets.

Das funktioniert jedoch nur, wenn die Codebasis so strukturiert ist, dass der Agent sie verstehen kann. Ein ausgereiftes Komponentensystem, eine klare Namensgebung, Design-Tokens und eine einheitliche Architektur führen wahrscheinlich zu besseren Ergebnissen als eine fragmentierte Codebasis voller Einmal-Implementierungen.

Mit anderen Worten: Figma Make könnte Teams belohnen, die bereits über eine gute Frontend-Praxis verfügen.

Governance wird Teil des Arbeitsablaufs

Sobald visuelle Bearbeitungen Auswirkungen auf den Live-Code haben können, rückt die Governance in den Mittelpunkt. Teams benötigen klare Regeln dazu, wer Änderungen vornehmen darf, welche Arten von Änderungen die Genehmigung eines Entwicklers erfordern, wie Branches angelegt werden, wie Pull-Requests geprüft werden und wie die Regeln des Design-Systems durchgesetzt werden.

Das ist nicht nur eine technische Frage. Es ist eine Frage der Teamkultur.

Designer möchten möglicherweise mehr Kontrolle über die Detailtreue. Entwickler möchten möglicherweise die Codequalität sichern. Produktteams möchten möglicherweise schnellere Iterationen. Die Führungskräfte möchten möglicherweise kürzere Lieferzyklen. All diese Ziele sind legitim, können jedoch zu Konflikten führen, wenn der Arbeitsablauf nicht klar definiert ist.

Figma Make lässt sich wahrscheinlich am besten nicht einseitig, sondern im Rahmen der Zusammenarbeit nutzen. Designer können visuelle Änderungen vorschlagen oder vornehmen. Der Agent kann diese Änderungen in Code umsetzen. Entwickler können die Unterschiede überprüfen. Das Designsystem kann weiterhin als Grundlage für Konsistenz dienen. Das Produktteam kann schneller vorankommen, ohne dabei die technische Verantwortung aus den Augen zu verlieren.

Dieses Gleichgewicht ist wichtig. KI-Tools sollten Reibungsverluste bei der Übergabe verringern, nicht aber die berufliche Verantwortung aufheben.

Warum dies über Figma hinaus von Bedeutung ist

Der Schritt von Figma fügt sich in einen größeren Trend in der Softwareentwicklung ein. Die Grenzen zwischen Design, Programmierung und Produktmanagement verschwimmen zunehmend. KI-basierte Programmieragenten können Codebasen auswerten, Änderungen generieren und auf Anweisungen in natürlicher Sprache reagieren. Mit Design-Tools lassen sich funktionsfähige Prototypen erstellen. Produktteams können Ideen schneller testen. Entwickler arbeiten zunehmend mit Agenten zusammen, anstatt jede Zeile von Grund auf neu zu schreiben.

Die Forschung zu Agenten, die visuelle Spezifikationen in Webanwendungen umsetzen, weist in dieselbe Richtung: Agenten werden nicht nur danach bewertet, ob sie Code schreiben können, sondern auch danach, ob sie aus Designvorgaben und Screenshots visuell stimmige, funktionsfähige Anwendungen erstellen können.

Das bedeutet nicht, dass jeder zum Entwickler wird. Vielmehr wird die Softwareentwicklung flexibler. Die Person, die dem Problem am nächsten steht, kann die Änderung möglicherweise direkter formulieren, während das Tool einen Teil der Umsetzung übernimmt.

Das ist wertvoll, da viele Produktverzögerungen nicht auf einen Mangel an Ideen zurückzuführen sind. Sie entstehen vielmehr durch die Kosten für die Abstimmung zwischen den verschiedenen Fachbereichen.

Die Fahrtrichtung

Die neue Integration der Codebasis in Figma Make lässt sich am besten als Teil eines schrittweisen Wandels und nicht als plötzlicher Bruch verstehen. Die Trennung zwischen Designdateien und der Umsetzung wird immer geringer. Code lässt sich zunehmend über visuelle Schnittstellen und Schnittstellen in natürlicher Sprache bearbeiten. KI-Agenten werden Teil der Zusammenarbeit zwischen den verschiedenen Disziplinen.

Der Vorteil liegt in schnelleren Iterationen und einer besseren Übereinstimmung zwischen dem, was die Teams entwerfen, und dem, was die Nutzer erleben. Das Risiko besteht in einer geringeren Codequalität, wenn visuelle Änderungen als harmlos angesehen werden, obwohl sie es nicht sind.

Am meisten profitieren werden jene Teams, die den Arbeitsablauf diszipliniert gestalten. Sie werden die visuelle Bearbeitung für jene Änderungen nutzen, bei denen sie wirklich effizient ist, die Entwickler in den Überprüfungszyklus einbinden, solide Komponentensysteme pflegen und KI-generierte Änderungen als Vorschläge betrachten, die einer Überprüfung bedürfen.

Figma Make macht den Übergang zwischen Design und Entwicklung zwar nicht überflüssig, kann diesen Übergang jedoch weniger zu einer Übersetzungsaufgabe und mehr zu einem gemeinsamen Bearbeitungsprozess machen.

Das ist eine bedeutende Veränderung. Die Zukunft der Produktentwicklung wird wohl nicht darin bestehen, dass Designer auf der einen Seite und Entwickler auf der anderen Seite stehen und Dateien hin und her schicken. Es wird vielmehr ein stärker vernetzter Arbeitsablauf sein, bei dem Designabsicht, Code-Kontext und KI-Unterstützung schon in einem früheren Stadium zusammenkommen.

Die Gewinner werden nicht die Teams sein, die jedem erlauben, alles zu bearbeiten. Es werden vielmehr jene Teams sein, die diese Tools nutzen, um schneller voranzukommen und gleichzeitig die Kohärenz, Zugänglichkeit und Wartbarkeit des Produkts zu gewährleisten.