Figma-to-Code mit KI

Ein Teil dieser Erwartung ist berechtigt. Für Prototypen, einfache Oberflächen oder erste technische Skizzen kann KI tatsächlich helfen, schneller von einem Design zu einem sichtbaren Ergebnis zu kommen. Die ersten Meter sind heute oft schneller geschafft als noch vor wenigen Jahren. Ein Entwurf lässt sich schneller ausprobieren, eine Komponente schneller nachbauen, eine technische Variante schneller diskutieren.

Genau darin liegt aber auch die Gefahr. Denn ein sichtbares Ergebnis ist noch keine tragfähige Umsetzung. Besonders bei Websites, die langfristig betrieben, redaktionell gepflegt und über Jahre weiterentwickelt werden, reicht es nicht, wenn ein Export dem Design auf den ersten Blick ähnlich sieht. Entscheidend ist, ob der erzeugte Code in das System passt, das hinter dem Design steht.

Universitäten und Hochschulen sind dafür ein besonders gutes Beispiel. Ihre Websites bestehen nicht aus wenigen klar abgegrenzten Seiten, sondern aus vielen Inhaltstypen, Zielgruppen, Redaktionsbereichen, Fachlogiken und technischen Abhängigkeiten. Studiengänge, Forschungsprojekte, Personenprofile, Veranstaltungen, News, Serviceinformationen und Organisationseinheiten müssen unterschiedlich gepflegt werden, sollen für Nutzerinnen und Nutzer aber als ein zusammenhängendes digitales Angebot funktionieren. Genau hier zeigt sich, warum Figma-to-Code nicht nur als Frage der Codegenerierung betrachtet werden sollte.

Die Erwartung: KI macht aus Design einfach Code

Die Vorstellung ist verständlich. Ein Figma-Design wirkt auf den ersten Blick bereits sehr konkret. Farben sind definiert, Abstände sichtbar, Schriften gesetzt, Komponenten angelegt, Layouts ausgestaltet. Für viele sieht der Weg zum fertigen Frontend deshalb kürzer aus, als er tatsächlich ist. Wenn KI inzwischen ganze Codeblöcke erzeugt und visuelle Inhalte analysieren kann, scheint der nächste Schritt fast logisch: Das Design wird erkannt und daraus entsteht Code.

Für einfache Anwendungsfälle kann das durchaus funktionieren. Eine Landingpage, ein Prototyp oder ein isoliertes Interface lassen sich auf diesem Weg schneller in eine erste technische Form bringen. Auch für interne Tests oder frühe Abstimmungen kann das hilfreich sein. Man sieht schneller, ob ein Layout im Browser grundsätzlich trägt, wie sich Elemente verhalten und wo eine Idee technisch hakt.

Bei komplexeren Website-Projekten verschiebt sich der Maßstab aber. Dort geht es nicht nur darum, einen Screen nachzubauen. Es geht darum, Gestaltung in ein System zu übertragen. Ein Design ist dann nicht nur eine visuelle Vorlage, sondern Ausdruck von Regeln: Komponenten, Varianten, Tokens, Zustände, Inhaltsmodelle, Redaktionslogiken, Barrierefreiheitsanforderungen und technische Schnittstellen. Wenn diese Ebenen nicht mitübersetzt werden, entsteht zwar Code, aber noch keine belastbare Umsetzung.

Die Frage ist deshalb nicht, ob KI aus einem Frame Code erzeugen kann. Die Frage ist, ob dieser Code zum System passt, das hinter dem Design steht.

Warum Interpretation schnell zum Problem wird

Figma-to-Code wird häufig so diskutiert, als müsse KI ein Design möglichst gut verstehen. Ein Modell soll erkennen, welche Elemente zusammengehören, was eine Komponente ist, welche Abstände relevant sind und welche Struktur sich daraus ableiten lässt. Dieser Blick ist naheliegend, führt aber leicht in die falsche Richtung.

In professionellen Webprojekten sollte an dieser Stelle möglichst wenig frei interpretiert werden. Wenn ein Designsystem sauber aufgebaut ist, müssen zentrale Dinge nicht jedes Mal neu erraten werden. Ein Button sollte nicht als etwas Button-ähnliches rekonstruiert werden, sondern als definierte Button-Komponente. Ein Abstand sollte nicht als ungefähr passender Pixelwert im Code landen, sondern als Token übersetzt werden. Eine Card sollte nicht nur als Gruppe aus Bild, Überschrift und Text erkannt werden, sondern als definierte Komponente mit Varianten, Zuständen und redaktionellen Regeln.

Gerade hier liegt ein häufiger Denkfehler. Weil KI gut darin ist, Muster zu erkennen und plausible Vorschläge zu machen, wird ihr schnell eine Interpretationsaufgabe gegeben. Bei Figma-to-Code ist aber nicht immer mehr Interpretation gefragt. In vielen Fällen ist das Gegenteil richtig: Je weniger ein System raten muss, desto besser.

Das eigentliche Ziel ist eine verlässliche Übersetzung. Designentscheidungen müssen in technische Strukturen übertragen werden. Aus einer Figma-Komponente wird eine Frontend-Komponente. Aus einem Design Token wird ein technischer Token. Aus einer Variante wird eine Property oder Konfiguration. Aus einem Modul wird ein CMS-Modell. Aus einem Zustand wird ein klar definiertes Interaktions- und Accessibility-Verhalten.

Wenn diese Zuordnung fehlt, erzeugt Automatisierung schnell visuell ähnliche Einzelstücke. Sie sehen zunächst richtig aus, folgen aber nicht derselben Logik. Genau daraus entstehen später Inkonsistenzen.

Visuelle Nähe reicht für langlebige Websites nicht aus

Viele automatisch erzeugte Ergebnisse wirken im ersten Moment überzeugend. Die Seite sieht ähnlich aus, Abstände und Typografie kommen grob hin, das Layout ist erkennbar. Für eine Präsentation oder einen ersten Prototyp kann das ausreichend sein. Für eine Website, die über Jahre gepflegt und erweitert wird, ist das ein schwacher Maßstab.

Im Betrieb kommen andere Fragen dazu. Funktioniert die Komponente mit echten Inhalten? Was passiert bei langen deutschen oder englischen Überschriften? Gibt es Fallbacks, wenn ein Bild fehlt? Ist das Markup semantisch sauber? Kann die Komponente mit Tastatur bedient werden? Versteht eine Redaktion im CMS, welche Felder gepflegt werden müssen? Ist klar, welche Varianten erlaubt sind und welche nicht? Lässt sich der Baustein später erweitern, ohne dass ein neuer Sonderfall entsteht?

Diese Fragen lassen sich nicht allein aus einem Screenshot beantworten. Sie betreffen die Verbindung zwischen Design, Frontend und Redaktion. Wenn ein Figma-to-Code-Prozess diese Verbindung nicht berücksichtigt, spart er oft nur am Anfang Zeit. Später entstehen Nacharbeiten: CSS wird aufgeräumt, Komponenten werden neu gebaut, CMS-Felder werden ergänzt, Varianten werden vereinheitlicht, Accessibility-Probleme werden korrigiert oder Dokumentation wird nachgezogen.

Das ist in gewachsenen Organisationen besonders relevant. Große Websites leiden selten daran, dass einzelne Bausteine nicht schnell genug entstehen. Häufiger liegt die Herausforderung tiefer: in gewachsenen Inhaltsstrukturen, uneinheitlichen Modulen, unklaren Verantwortlichkeiten, historischen Sonderfällen oder Designsystemen, die im Alltag nicht sauber in Redaktion und Technik übersetzt wurden. Wenn Automatisierung diese Strukturen nicht berücksichtigt, erzeugt sie nicht weniger Komplexität, sondern schneller neue Einzelteile.

Warum die CMS-Perspektive entscheidend ist

Viele Figma-to-Code-Diskussionen enden beim Frontend. Für CMS-basierte Websites reicht das nicht. Ein Modul muss nicht nur im Browser gut aussehen, sondern im Backend sinnvoll gepflegt werden können. Redakteurinnen und Redakteure brauchen klare Felder, Hilfetexte, Validierungen und Grenzen. Sie müssen verstehen, wann ein Modul verwendet wird, welche Varianten vorgesehen sind und welche Inhalte an welcher Stelle gepflegt werden.

Ein Beispiel zeigt das gut: Eine Teaserliste kann im Design wie ein einfacher Abschnitt aussehen. Technisch kann sie aber sehr unterschiedlich gemeint sein. Vielleicht wird sie manuell gepflegt. Vielleicht zieht sie automatisch News aus einer Kategorie. Vielleicht verweist sie auf Studiengänge, Veranstaltungen oder Forschungsprojekte. Vielleicht braucht sie Filter. Vielleicht darf sie nur auf bestimmten Seitentypen erscheinen. Aus dem sichtbaren Layout allein lässt sich das nicht zuverlässig ableiten.

Gerade bei Universitäten und Hochschulen ist diese redaktionelle Ebene zentral. Viele Inhalte entstehen dezentral. Unterschiedliche Bereiche haben eigene Anforderungen, müssen aber innerhalb eines gemeinsamen Systems arbeiten. Ein Modul, das technisch sauber aussieht, aber redaktionell schlecht bedienbar ist, schafft im Alltag keine Entlastung. Es erzeugt Rückfragen, Workarounds und später neue Sonderlösungen.

Deshalb muss Figma-to-Code bei solchen Projekten weiter gedacht werden: vom Design zur Komponente, von der Komponente zum Modul, vom Modul zum Datenmodell und vom Datenmodell zum redaktionellen Alltag. Erst dann wird aus einem gestalteten Baustein ein Element, das nicht nur im Frontend funktioniert, sondern auch in der täglichen Pflege trägt.

Das eigentliche Thema heißt Mapping

Der zentrale Begriff für einen guten Figma-to-Code-Prozess ist nicht Export, sondern Mapping. Es geht darum, die Ebenen eines Systems sauber miteinander zu verbinden. Welche Figma-Komponente entspricht welcher Frontend-Komponente? Welche Variante steuert welche technische Property? Welche Tokens werden verwendet? Welche Inhalte kommen aus dem CMS? Welche Felder sind Pflicht, welche optional? Welche Module dürfen miteinander kombiniert werden? Welche Regeln gelten für mobile Ansichten, Barrierefreiheit und Interaktion?

Gerade bei den gestalterischen Grundlagen sollte dabei möglichst wenig interpretiert werden. Abstände, Radien, Farben, Schriftgrößen, Line-Heights oder Breakpoints sind keine Werte, die ein System „ungefähr“ ableiten sollte. Wenn sie im Designsystem definiert sind, sollten sie auch entsprechend übernommen werden. Ein Radius von 8px ist kein Vorschlag für „etwas abgerundet“. Ein definierter Spacing-Wert ist kein Anlass für eine optisch ähnliche Schätzung. Ein Farbwert, ein Typografie-Token oder ein Grid-Abstand sollte nicht neu interpretiert, sondern eindeutig in die technische Entsprechung übertragen werden.

Genau darin unterscheidet sich gutes Mapping von einfachem Nachbau. Es geht nicht darum, dass ein Tool ein Design möglichst plausibel rekonstruiert. Es geht darum, vorhandene Designentscheidungen zuverlässig in Code, Komponenten und CMS-Strukturen zu übertragen. Wo ein Token existiert, sollte dieser genutzt werden. Wo eine Komponente definiert ist, sollte die passende technische Komponente verwendet werden. Wo ein Wert vom System abweicht, sollte diese Abweichung sichtbar werden, statt stillschweigend als neuer Sonderfall im Code zu landen.

Diese Fragen sind weniger spektakulär als die Vorstellung, dass KI aus einem Design automatisch eine fertige Website baut. Für echte Projekte sind sie aber entscheidend. Denn genau hier entsteht der Unterschied zwischen einem schnellen visuellen Nachbau und einer langfristig brauchbaren Umsetzung. Ein Export kann auf den ersten Blick richtig aussehen und trotzdem falsche Werte, unnötige Einzelstyles oder abweichende Komponentenlogiken erzeugen.

Ein gutes Mapping verhindert, dass jedes Designfragment als neuer Sonderfall behandelt wird. Es sorgt dafür, dass wiederkehrende Muster wiederverwendet werden, Varianten kontrolliert bleiben und Redaktionen nicht mit unnötiger Komplexität konfrontiert werden. Außerdem hält es technische und gestalterische Entscheidungen nachvollziehbar. Das ist wichtig, wenn Websites über Jahre weiterentwickelt werden und Teams wechseln oder wachsen.

KI kann dieses Mapping unterstützen. Sie kann Muster erkennen, Abweichungen sichtbar machen, Komponenten vergleichen und Vorschläge vorbereiten. Aber sie sollte fehlende Systementscheidungen nicht durch Raten ersetzen. Wenn nicht klar ist, welche Designkomponente welchem CMS-Modul entspricht, kann KI zwar eine plausible Zuordnung vorschlagen. Genau das ist aber häufig der falsche Ansatz. Bei Figma-to-Code ist die bessere Automatisierung nicht die, die am kreativsten interpretiert, sondern die, die definierte Werte und Strukturen möglichst präzise übernimmt.

Wo KI trotzdem sinnvoll eingesetzt werden kann

Figma-to-Code ist also kein Fall gegen KI. Im Gegenteil: KI kann an dieser Stelle wertvoll sein, wenn ihre Rolle richtig verstanden wird. Sie sollte nicht als magischer Exportknopf betrachtet werden, sondern als Unterstützung bei der Übersetzung zwischen Designsystem, Frontend und CMS.

Sie kann helfen, wiederkehrende Muster in Designs zu erkennen und mit vorhandenen Komponenten abzugleichen. Sie kann auffällige Abweichungen markieren, zum Beispiel wenn Abstände, Farben oder Typografie nicht zu definierten Tokens passen. Sie kann Dokumentation für Komponenten vorbereiten oder Varianten beschreiben. Sie kann technische Grundstrukturen vorschlagen, wenn das zugrunde liegende Mapping bereits klar genug ist.

Der Unterschied ist wichtig. Es geht nicht um „Design rein, Website raus“. Es geht darum, Designentscheidungen kontrollierter in Tokens, Komponenten, Varianten, CMS-Module und redaktionelle Logiken zu übertragen. Das ist weniger spektakulär als viele KI-Versprechen, aber im Alltag deutlich hilfreicher.

Genau an dieser Stelle entstehen auch sinnvolle eigene Workflows und Automatisierungen. Nicht mit dem Ziel, komplette Websites blind aus Figma zu exportieren, sondern um wiederkehrende Übersetzungsarbeit zu reduzieren, Abweichungen früher sichtbar zu machen und die Verbindung zwischen Gestaltung und Umsetzung verlässlicher zu gestalten.

Gute Automatisierung braucht gute Vorarbeit

Figma-to-Code zeigt eine unbequeme Wahrheit: Automatisierung wird nicht dadurch gut, dass man einen unklaren Prozess automatisiert. Wenn Komponenten im Design nicht sauber benannt sind, wird Mapping schwierig. Wenn Varianten unklar bleiben, entstehen Sonderfälle. Wenn Tokens inkonsequent genutzt werden, landet diese Inkonsistenz im Code. Wenn das CMS-Modell nicht mitgedacht wird, entsteht ein Frontend ohne tragfähige redaktionelle Grundlage.

Gute Automatisierung braucht deshalb Vorarbeit. Ein belastbares Designsystem. Klar definierte Komponenten. Benannte Varianten. Ein Verständnis für Inhalte. Regeln für Responsiveness. Anforderungen an Barrierefreiheit. Ein CMS-Modell, das zur Gestaltung passt. Erst dann kann KI sinnvoll unterstützen, weil sie nicht jedes Element neu deuten muss.

Der Wert eines guten Figma-to-Code-Prozesses zeigt sich nicht im ersten Screenshot. Er zeigt sich später: wenn eine neue Seite entsteht, wenn eine Redaktion einen Teaser mit längerer Überschrift pflegt, wenn ein Forschungsprojekt zusätzliche Metadaten bekommt, wenn eine englische Version mehr Platz braucht, wenn eine Barrierefreiheitsprüfung erfolgt oder wenn ein anderes Teammitglied eine Komponente erweitert.

Dann zeigt sich, ob der Code nur ähnlich aussah oder wirklich Teil eines Systems geworden ist.

Was daraus folgt

KI macht Figma-to-Code nicht automatisch einfach. Sie macht vor allem sichtbar, wie wichtig klare Systeme sind. Je besser Designsystem, Komponentenlogik und CMS-Modell beschrieben sind, desto hilfreicher kann Automatisierung werden. Je mehr ein Tool interpretieren muss, desto größer wird das Risiko für Inkonsistenzen, Nacharbeit und technische Schuld.

Für komplexe Websites, gerade im Umfeld von Universitäten, Hochschulen und anderen großen Organisationen, ist das entscheidend. Dort geht es nicht nur darum, ein Design schnell in Code zu übertragen. Es geht darum, digitale Systeme zu bauen, die über Jahre gepflegt, erweitert und verstanden werden können.

Der Fortschritt liegt deshalb nicht darin, Layouts immer schneller zu exportieren. Er liegt darin, Designentscheidungen verlässlicher in langfristig wartbare Systeme zu übersetzen.

Gute Automatisierung braucht weniger Magie, als man denkt. Sie braucht klare Zuordnung, saubere Vorarbeit und möglichst wenig Rätselraten.