Figma Make im Jahr 2026: Vom Design zum funktionierenden Prototyp und Code
Figma Make hat den Weg vom Interface-Design zu etwas verändert, das Nutzer tatsächlich anklicken, testen und bewerten können. Im Jahr 2026 kann das Tool aus einer schriftlichen Aufgabenbeschreibung, einem vorhandenen Figma-Frame oder einer Kombination aus Designreferenzen und Projektkontext einen funktionierenden Prototyp oder eine Web-App mit interaktiven Elementen und bearbeitbarem Code erstellen. Dadurch entfallen weder gestalterische Entscheidungen noch die technische Prüfung durch Entwickler, doch die Distanz zwischen einem statischen Konzept und einer realistisch nutzbaren Umsetzung wird deutlich kleiner. Am sinnvollsten ist es, Make nicht als Ein-Klick-Ersatz für Produktentwicklung zu betrachten, sondern als schnelle Arbeitsumgebung, mit der sich klare Designabsichten in funktionales Verhalten übertragen, frühzeitig überprüfen und konkreter an Entwickler übergeben lassen. Die besten Ergebnisse entstehen, wenn das Ausgangsdesign sauber aufgebaut ist, die Aufgabenstellung präzise formuliert wurde und jede Überarbeitungsrunde ein klares Ziel verfolgt.
Was Figma Make im Jahr 2026 tatsächlich kann
Figma Make basiert auf einem KI-Chat, der Code für funktionierende Prototypen, Web-Apps und interaktive Benutzeroberflächen erzeugt. Ein Projekt kann mit einer einfachen Texteingabe beginnen, doch in der Praxis ist eine Kombination aus Beschreibung und Designkontext meist die bessere Grundlage. Nutzer können Figma-Designs anhängen, Frames direkt in den Chat einfügen, auf berechtigten kostenpflichtigen Tarifen Stilinformationen aus veröffentlichten Bibliotheken einbeziehen und über unterstützte MCP-Verbindungen zusätzlichen externen Kontext verwenden. Für zahlende Nutzer steht außerdem der Plan-Modus zur Verfügung, der vor der eigentlichen Codegenerierung einen strukturierten Umsetzungsplan erstellt. Gerade bei Produkten mit mehreren Screens ist das hilfreich, weil sich der geplante Ablauf korrigieren lässt, bevor größere Mengen Code entstehen. Das Ziel ist einfach: Make sollte nicht nur verstehen, wie ein Screen aussehen soll, sondern auch, was wichtige Bedienelemente tun müssen und wie zentrale Zustände miteinander zusammenhängen.
Das generierte Ergebnis ist mehr als ein anklickbares Mock-up. Make schreibt den Code für die Anwendung und zeigt nach Abschluss der Generierung eine interaktive Vorschau. Anschließend kann die Unterhaltung fortgesetzt, die gerenderte Oberfläche bearbeitet, der Code direkt geändert oder zu einer früheren Version zurückgekehrt werden. Das ist wichtig, weil der erste Entwurf nur selten als endgültig betrachtet werden sollte. Eine Produktkarte kann optisch korrekt aussehen, sich bei geringer Bildschirmbreite aber schlecht verhalten, ein Suchfeld kann keinen leeren Zustand berücksichtigen oder ein Dialogfenster kann zwar geöffnet werden, den Fokus jedoch nicht sauber zum auslösenden Element zurückführen. Figma Make ist besonders nützlich, wenn solche Punkte als normaler Teil der Iteration verstanden werden und nicht als Zeichen dafür, dass der erste Prompt gescheitert ist. In der Praxis sollte der generierte Stand als testbarer Entwurf betrachtet und mit derselben Sorgfalt weiterentwickelt werden wie jeder andere Prototyp.
Auch die Wahl des Modells ist 2026 wichtiger geworden. Figma hat GPT-5.6 im Juli in die Modellauswahl von Make aufgenommen, mit Schwerpunkt auf besseren ersten UI-Ergebnissen, responsiven Layouts und Interaktionen. Das Modell ist jedoch nur ein Teil des Prozesses. Die Qualität der Eingabe wirkt sich weiterhin direkt auf die Qualität des Ergebnisses aus. Eine kurze Anweisung wie „Mach diesen Screen interaktiv“ lässt zu viele Entscheidungen offen. Besser ist es, die Nutzeraktion, die erwartete Reaktion, die sichtbare Zustandsänderung und relevante Einschränkungen zu definieren. Beispielsweise kann festgelegt werden, dass die Auswahl eines Produktfilters die Anzahl der Ergebnisse aktualisiert, den aktiven Filter sichtbar kennzeichnet, die aktuelle Sortierung beibehält und eine klare Möglichkeit zum Zurücksetzen bietet. Eine solche Beschreibung gibt dem generierten Prototyp konkrete Anforderungen und schafft zugleich eindeutige Kriterien für die anschließende Prüfung.
Mit einem bestehenden Design statt mit einem leeren Prompt beginnen
Eine der stärksten Einsatzmöglichkeiten von Figma Make besteht darin, einen vorhandenen Figma-Design-Frame in eine funktionierende Anwendung zu verwandeln, ohne die Oberfläche von Grund auf neu erstellen zu müssen. Figma empfiehlt, strukturierte Frames anzuhängen, statt sich ausschließlich auf Screenshots zu verlassen, da Frames Informationen enthalten, die ein Bild nicht zuverlässig vermittelt, darunter Layoutbeziehungen und die Struktur des Designs. Auto Layout ist besonders hilfreich, weil es Make klarere Hinweise darauf gibt, wie sich Elemente vergrößern, verkleinern oder neu anordnen sollen. Für eine kleine Funktion kann der relevante Frame angehängt und das gewünschte Verhalten beschrieben werden. Bei größeren Produkten ist es sinnvoller, Screen für Screen oder mit jeweils ein bis zwei Designs zu arbeiten. So bleibt der Kontext überschaubar und es lässt sich leichter erkennen, wenn der generierte Stand einen Ablauf falsch interpretiert, eine Komponente doppelt erstellt oder eine Annahme trifft, die im Design nie vorgesehen war.
Make Kits sorgen für zusätzliche Konsistenz bei Teams, die bereits mit einem Designsystem arbeiten. Ein Kit kann npm-Pakete als Codekontext, Variablen und Stile aus veröffentlichten Figma-Design-Bibliotheken sowie schriftliche Richtlinien zur Verwendung von Komponenten, Tokens und Mustern enthalten. Der praktische Vorteil besteht darin, dass der generierte Prototyp näher am tatsächlichen Produkt beginnen kann, statt für jedes Experiment eine neue visuelle Sprache zu erfinden. Das ist besonders bei wiederkehrenden Elementen wie Buttons, Eingabefeldern, Karten, Abstandsregeln und Typografie hilfreich. Ein Designer sollte das Ergebnis weiterhin prüfen, doch der Korrekturaufwand kann geringer ausfallen, wenn Make dieselben Gestaltungsregeln erhält, die das Team bereits verwendet. Für Organisationen mit regelmäßigem Prototyping reduziert ein gut gepflegtes Kit außerdem die Notwendigkeit, dieselben visuellen Vorgaben bei jedem neuen Chat erneut zu formulieren.
Anhänge können mehr als nur visuelle Referenzen liefern. Figma führte 2026 Make Attachments ein, damit Prototypen auf projektspezifischen Inhalten, Daten und Einschränkungen basieren können. Dadurch kann beispielsweise ein Prototyp für einen Kundenbereich mit realistischen Inhalten arbeiten, statt Platzhaltertext zu verwenden, während eine informationsreiche Oberfläche an den tatsächlichen Datentypen ausgerichtet werden kann, die später angezeigt werden sollen. Sinnvoll ist es, nur Material anzuhängen, das das Ergebnis tatsächlich beeinflusst. Eine kompakte Richtliniendatei, eine echte Komponentenreferenz und eine kleine Auswahl repräsentativer Daten sind meist wertvoller als eine große Sammlung nur lose zusammenhängender Dateien. Vertrauliche Informationen sollten nicht in den Chat eingefügt werden. Figma weist ausdrücklich darauf hin, keine API-Schlüssel, personenbezogenen Daten, Adressen oder vergleichbare sensible Informationen in Prompts einzugeben; sicherheitsrelevante Datenverarbeitung gehört in das Backend oder einen anderen kontrollierten Teil der Umsetzung.
Einen funktionierenden Prototyp Schritt für Schritt erstellen
Ein zuverlässiger Figma-Make-Workflow beginnt mit Layout und Nutzerablauf, bevor jede erweiterte Interaktion hinzugefügt wird. Zunächst sollte das wichtigste Design angehängt oder eingefügt und beschrieben werden, wofür der Screen gedacht ist, wer ihn nutzt und wie ein erfolgreich abgeschlossener Ablauf aussieht. Danach werden die zentralen Aktionen in normaler Sprache definiert. Ein Checkout-Prototyp sollte beispielsweise nicht mit einer langen Anweisung beginnen, die sämtliche Zahlungszustände, Animationen und Validierungsregeln gleichzeitig umfasst. Sinnvoller ist es, zunächst den Kernablauf umzusetzen: Lieferoption auswählen, Kontaktdaten eingeben, zur Zahlung wechseln und die Bestellung bestätigen. Sobald dieser Weg korrekt funktioniert, können fehlende Zustände schrittweise ergänzt werden. Dieses Vorgehen entspricht auch der Empfehlung von Figma, zunächst das Layout, danach die Funktionalität zu bearbeiten und komplexe Aufgaben in kleinere Schritte aufzuteilen. Fehler lassen sich dadurch leichter eingrenzen, weil jede Änderung einen klaren Ursprung hat.
Ein guter Prompt sollte Aufgabe, Kontext und Einschränkungen miteinander verbinden. Die Aufgabe erklärt Make, was erstellt werden soll; der Kontext beschreibt das Produkt und die Nutzungssituation; die Einschränkungen verhindern unerwünschte Annahmen. Bei der Umwandlung eines Dashboard-Designs könnte beispielsweise festgelegt werden, dass der vorhandene Desktop-Frame als visuelle Grundlage dient, die Tabelle auch bei kleineren Breiten lesbar bleiben muss, Filter die sichtbaren Zeilen aktualisieren sollen und keine neuen Navigationselemente hinzugefügt werden dürfen. Das ist hilfreicher als eine lange Liste vager Designadjektive. Gleichzeitig entsteht daraus eine einfache Prüfliste für den generierten Stand. Passt sich die Tabelle wie gefordert an? Funktionieren die Filter? Wurde die Informationsarchitektur beibehalten? Hat Make etwas ergänzt, das nicht angefordert wurde? Je genauer die Aufgabenstellung formuliert ist, desto leichter lässt sich das Ergebnis anhand konkreter Kriterien statt nach bloßem Eindruck bewerten.
Bei größeren Projekten kann der Plan-Modus unnötige Generierungsschritte reduzieren. Bevor Code geschrieben wird, erstellt Make einen strukturierten Plan, der geprüft und angepasst werden kann. Das ist besonders hilfreich, wenn eine Funktion mehrere Screens, Abhängigkeiten oder Datenzustände umfasst, denn ein schwerwiegender Fehler besteht oft nicht in einer falschen Farbe oder einem unpassenden Abstand, sondern in einem falschen Verständnis des Produktablaufs. Ein Plan kann beispielsweise zeigen, dass das Modell einen zusätzlichen Kontoschritt einbauen, einen Filter als Navigation behandeln oder zwei Zustände zusammenführen möchte, die getrennt bleiben müssen. Solche Missverständnisse lassen sich früh einfacher korrigieren, als nachdem sie sich bereits im Code ausgebreitet haben. Ist der Plan stimmig, erhält die Generierung ein klareres Ziel. Weitere Anpassungen können weiterhin notwendig sein, doch die Umsetzung beginnt auf Grundlage einer abgestimmten Struktur statt eines langen Prompts, der nie als Spezifikation geprüft wurde.
Interaktionen verfeinern, ohne alles neu schreiben zu müssen
Die Bearbeitungswerkzeuge von Figma Make im Jahr 2026 sind darauf ausgelegt, kleinere Änderungen präziser umzusetzen. In neuen Make-Dateien ermöglicht das Eigenschaften-Panel die Auswahl eines Elements und die Anpassung vertrauter visueller Eigenschaften wie Abstände, Typografie, Layout, Deckkraft, Rahmen und verwandter Einstellungen. Diese Änderungen werden zunächst vorbereitet, bevor sie übernommen werden, sodass sich die geplanten Anpassungen prüfen lassen, ohne sofort jede Modifikation dauerhaft anzuwenden. Das ist häufig besser als ein allgemeiner Prompt wie „Mach die Karte kompakter“, durch den möglicherweise mehrere nicht zusammenhängende Bereiche verändert werden. Die direkte Bearbeitung gibt Make ein eindeutiges Ziel. Besonders nützlich ist sie in einer späteren Projektphase, wenn das Grundlayout bereits stimmt und nur noch Ausrichtung, visuelle Hierarchie, Komponentengröße oder andere Details angepasst werden müssen, die sich visuell leichter beurteilen als ausführlich beschreiben lassen.
Annotationen eignen sich für Änderungen, die sich nicht allein über visuelle Eigenschaften ausdrücken lassen. Nutzer können ein oder mehrere Elemente direkt in der Vorschau markieren und diesen Stellen eine konkrete Anweisung zuordnen. Ein Designer kann beispielsweise ein Vorschaubild markieren und einen leichten Zoom beim Darüberfahren verlangen, einen Menüauslöser auswählen und eine bildschirmfüllende Einblendung anfordern oder mehrere zusammengehörige Steuerelemente kennzeichnen, für die dieselbe Interaktionsregel gelten soll. Da die Anweisung direkt mit dem jeweiligen Element verbunden ist, muss Make weniger darüber spekulieren, welcher Bereich der Oberfläche gemeint ist. Das wird vor allem bei dichten Screens mit mehreren ähnlich benannten Buttons oder wiederholten Komponenten nützlich. Statt einen weiteren allgemeinen Prompt für den gesamten Screen zu schreiben, wird das genaue Ziel markiert, das gewünschte Verhalten beschrieben und anschließend das Ergebnis geprüft. Laut Figma verbrauchen Änderungen über das Eigenschaften-Panel und Annotationen bei ihrer Anwendung KI-Credits.
Versionsverlauf und direkte Codebearbeitung bieten zwei weitere Möglichkeiten, Iterationen kontrolliert zu halten. Wenn ein Prompt einen Teil des Prototyps verbessert, gleichzeitig aber einen anderen verschlechtert, ist die Rückkehr zu einer früheren Version häufig schneller als der Versuch, eine Kette unbeabsichtigter Änderungen zu reparieren. Die direkte Bearbeitung des Codes ist sinnvoll, wenn ein Entwickler oder ein technisch versierter Designer ein kleines Problem im Quellcode schneller erkennt und korrigiert als über eine weitere KI-Anweisung. Entscheidend ist, für jedes Problem die passende Bearbeitungsmethode zu wählen. Das Eigenschaften-Panel eignet sich für konkrete visuelle Änderungen, Annotationen für ortsspezifisches Verhalten, Prompts für umfassendere Produktänderungen und Code für Aufgaben, die sich direkt im Quelltext am einfachsten lösen lassen. Dadurch wird vermieden, jede Aufgabe über einen Dialog zu steuern, selbst wenn ein präziseres Werkzeug verfügbar ist. Gleichzeitig lassen sich Credits sparen, weil weniger unnötige Generierungsschritte erforderlich sind.
Vom Prototyp zu bearbeitbarem Code und zur Veröffentlichung
Sobald der Prototyp funktioniert, bietet Figma Make mehrere Wege für die weitere Nutzung. Der generierte Code kann innerhalb der Make-Datei geprüft und bearbeitet werden, außerdem lassen sich Projekte zu GitHub übertragen. Die aktuelle GitHub-Integration von Figma kann für eine Make-Datei ein Repository erstellen und spätere Aktualisierungen in dasselbe Repository übertragen. Dabei ist eine wichtige Einschränkung zu beachten: Die Standardübertragung verläuft nur in eine Richtung von Make zu GitHub, und spätere Änderungen in GitHub werden nicht automatisch wieder in Make übernommen. Figma weist außerdem darauf hin, dass Make in das für diese Datei erstellte Repository überträgt und nicht in ein beliebiges bereits vorhandenes Repository. Für Teams eignet sich GitHub damit als Übergabepunkt, Sicherung und Grundlage für die weitere Entwicklung, sollte jedoch nicht mit einer vollständigen bidirektionalen Codesynchronisierung verwechselt werden. Sobald Entwickler außerhalb von Make weiterarbeiten, müssen Verantwortlichkeiten im Entwicklungsprozess weiterhin klar geregelt sein.
Figma testete 2026 außerdem einen tiefer gehenden Workflow für Produktionscode. Die im Mai angekündigte begrenzte Beta ermöglicht berechtigten Nutzern, eine echte Codebasis zu verbinden, einen Branch anzulegen, visuelle oder per Prompt gesteuerte Änderungen direkt am bestehenden Code vorzunehmen, Commits zu prüfen und die Arbeit bis zu einem Pull Request weiterzuführen. Dieses Szenario unterscheidet sich vom Export eines eigenständigen Make-Projekts in ein neu angelegtes GitHub-Repository. Designer arbeiten dadurch näher am tatsächlichen Produktionscode und können Abhängigkeiten erkennen, die in einem statischen Design nicht sichtbar sind, etwa eine gemeinsam genutzte Komponente, die auf mehreren Screens verwendet wird. Der Zugang zur Beta war während des Jahres eingeschränkt; Figma stellte die Funktion zunächst nur ausgewählten Nutzern der Beta-Desktop-App für Mac zur Verfügung. Teams sollten deshalb vor der Planung eines solchen Workflows prüfen, ob der entsprechende Zugang für ihr Konto aktuell vorhanden ist.
Wenn ein Prototyp öffentlich geteilt und nicht sofort an die Entwicklung übergeben werden soll, kann Make eine funktionierende Web-Anwendung oder einen interaktiven Prototyp mit eigener URL im Web veröffentlichen. Veröffentlichte Projekte lassen sich später aktualisieren, wieder offline nehmen und bei entsprechenden Kontotarifen mit einer eigenen Domain verbinden. Das ist praktisch für Usability-Tests, Stakeholder-Präsentationen, Vertriebsdemonstrationen oder kontrollierte Tests, bei denen Teilnehmer einen echten Link benötigen, ohne Zugriff auf die Design-Datei zu erhalten. Eine Veröffentlichung bedeutet jedoch nicht automatisch, dass generierter Code produktionsreif ist. Vor einem öffentlichen Einsatz sollten Nutzungsrechte, Datenverarbeitung, Barrierefreiheit, Leistung, responsives Verhalten und verwendete externe Dienste geprüft werden. Eine überzeugende Demo kann schwache Fehlerbehandlung oder unrealistische Datenannahmen verbergen. Deshalb sollte die abschließende Prüfung nicht nur den idealen Ablauf testen, sondern auch untersuchen, was passiert, wenn Eingaben fehlen, Dienste nicht reagieren oder Nutzer vom vorgesehenen Weg abweichen.
Wo Figma Make weiterhin menschliche Prüfung benötigt
Die wichtigste Grenze von Figma Make entspricht der vieler KI-gestützter Entwicklungswerkzeuge: Ein plausibles Ergebnis kann fertig wirken, bevor es wirklich geprüft wurde. Ein Button kann im idealen Ablauf funktionieren, bei einer langen Beschriftung jedoch Probleme verursachen, die Tastaturnavigation kann unvollständig sein, ein mobiles Layout kann mehr Nacharbeit benötigen als die Desktop-Version oder generierte Inhalte können rechtlichen und redaktionellen Anforderungen nicht entsprechen. Figma weist in den aktuellen Empfehlungen darauf hin, dass Desktop- und Vollbild-Ergebnisse in einigen Fällen weiterhin zuverlässiger ausfallen als mobile Umsetzungen, weshalb responsives Verhalten gezielt getestet werden sollte. Designer sollten Layouts bei realistischen Bildschirmbreiten, längere Texte, Fokuszustände, Ladezustände, leere Ansichten, Fehlermeldungen und wiederholte Inhalte prüfen. Entwickler sollten die Codestruktur, Abhängigkeiten und Sicherheitsaspekte bewerten. Der Prototyp gewinnt an Wert, wenn er solche Fragen früh sichtbar macht, nicht wenn er als Beweis dafür betrachtet wird, dass diese Prüfungen nicht mehr notwendig sind.
Es besteht außerdem ein Unterschied zwischen generiertem Code, der bearbeitet werden kann, und Code, den ein Team über Jahre hinweg zuverlässig pflegen möchte. Make kann einen sehr guten Ausgangspunkt schaffen, vor allem wenn präziser Designkontext, eine klare Aufgabenstellung und passende Komponentenregeln vorliegen. Produktionscode muss dennoch zur Architektur des Projekts, zu Teststandards, Sicherheitsvorgaben, Namenskonventionen und zum Release-Prozess passen. Wenn ein Team bereits gemeinsame Komponenten verwendet, kann eine zusätzlich generierte Variante unnötige Duplikate schaffen. Wenn eine Anwendung von Authentifizierung, privaten APIs oder regulierten Daten abhängt, ist vor der Nutzung durch echte Anwender eine fachkundige technische Prüfung erforderlich. Eine vernünftige Übergabe lautet daher nicht „Die KI hat den Code geschrieben, also kann er veröffentlicht werden“, sondern vielmehr: „Das gewünschte Verhalten ist konkret umgesetzt, der Code liegt vor und das Team kann nun einen deutlich spezifischeren Vorschlag prüfen.“ Damit wird Unsicherheit reduziert, ohne technische Verantwortung aus dem Prozess zu entfernen.
Der sinnvollste Figma-Make-Workflow im Jahr 2026 ist daher ein Kreislauf und kein einzelner Sprung vom Frame zum fertigen Produkt. Ausgangspunkt sollte ein sauber strukturiertes Design oder eine klare Aufgabenbeschreibung sein. Anschließend erhält Make ausreichend Kontext, um das gewünschte System beizubehalten, danach wird zunächst der kleinste sinnvolle Teil generiert, getestet und mit dem jeweils präzisesten verfügbaren Bearbeitungswerkzeug weiterentwickelt. Make Kits sind sinnvoll, wenn Konsistenz wichtig ist, Anhänge helfen dort, wo reale Inhalte oder projektspezifische Einschränkungen das Verhalten verändern, und GitHub oder die Produktionscode-Beta sollten erst eingesetzt werden, wenn der Stand für die technische Prüfung bereit ist. Öffentlich zugängliche Prototypen sollten erst nach der Kontrolle von Rechten, Datenschutz und Sonderfällen veröffentlicht werden. Auf diese Weise kann Figma Make Designabsichten deutlich früher in etwas Testbares verwandeln. Der eigentliche Nutzen besteht nicht darin, die Arbeit zwischen Design und Code vollständig zu beseitigen, sondern darin, sie früher sichtbar und in einer Form überprüfbar zu machen, mit der Designer, Produktmanager und Entwickler gemeinsam arbeiten können.
