UI-Generierung aus Entwürfen, Screenshots und Skizzen

Die Übergabe eines fertigen Entwurfs an Frontend-Entwickler ist langsam, repetitiv und verlustbehaftet: Abstände, Tokens und Zustände weichen zwischen Mock-up und Umsetzung voneinander ab. Multimodale Modelle und Anbindungen an Design-Werkzeuge lesen heute einen Figma-Frame, einen Screenshot oder sogar eine Skizze auf einer Serviette und liefern funktionierenden Komponentencode, idealerweise dem eigenen Designsystem des Teams zugeordnet. Das Ergebnis ist ein starker erster Entwurf in Minuten; Feinschliff, Barrierefreiheit, Zustandslogik und Prüfung bleiben menschliche Arbeit.

Problem & Nutzen

• Heute: Designer liefern Figma-Dateien; Entwickler bauen jeden Bildschirm von Hand nach, übertragen Tokens in CSS-Variablen, jagen Pixelabweichungen hinterher und überarbeiten nach Designänderungen. Prototypen von Produktverantwortlichen oder Agenturen sind oft Wegwerfware.
• Nutzen durch KI: schnellere erste Umsetzung von Bildschirmen und Komponenten, konsistente Verwendung von Design-Tokens, schnelle klickbare Prototypen aus Skizzen und rasche Nachbildung bestehender Oberflächen, wenn kein Quellcode existiert (Altbildschirme, neutrale Referenzlayouts, Migration auf ein neues Framework).
• Belege: Der Benchmark Design2Code (484 reale Webseiten) zeigte, dass multimodale Modelle visuelles Layout und Text einigermaßen gut nachbilden können, die Treue bei Struktur und Positionierung aber zwischen den Modellen stark schwankte [1]. Synthetische Datensätze wie WebSight (2 Millionen Paare aus Screenshot und HTML in v0.2) ermöglichten es offenen Modellen, die Aufgabe zu lernen [2]. Anbieter veröffentlichen Produktivitätsversprechen, behandeln Sie diese aber als Marketing, bis sie am eigenen Backlog gemessen sind.

Varianten

• Design-Werkzeug zu Code (strukturiert): Ein Agent liest den Figma-Knotenbaum, Variablen und Komponenten- Metadaten über einen MCP-Server und erzeugt Code auf Basis der vorhandenen Komponentenbibliothek [3].
• Screenshot/URL zu Code (unstrukturiert): Ein Bildmodell bildet eine Seite aus einem Bild nach; nützlich für Re-Skinning von Altsystemen und Migrationen, schwächer bei Semantik und Responsivität.
• Skizze zu Prototyp: Whiteboard- oder Papier-Wireframes werden zu einem klickbaren Prototyp für Nutzertests.
• Prompt-to-UI-Generatoren: Text plus optional ein Bild erzeugen vollständige Bildschirme (siehe CODE-007 für App-Entwicklung durch Nicht-Entwickler).
• Umgekehrte Richtung / Design-Synchronisierung: Rückschreiben von Code ins Design und Design-Token-Pipelines halten beide Seiten im Einklang.
• Private Nutzung: Hobby-Webseiten aus Skizzen; geringes Risiko, dieselben Werkzeuge.

So funktioniert es

1. design source (Figma frame / screenshot / sketch)
2. context extraction (node tree, tokens, variants, assets | image only)
3. mapping to design system (Code Connect / component index / project rules)
4. code generation (VLM + code LLM, agent with repo access)
5. render in headless browser
6. screenshot
7. visual diff vs. design
8. self-correction loop (agent fixes mismatches)
9. automated checks (lint, type-check, accessibility, unit/visual tests)
10. human review, pull request, preview deployment

• Strukturierter Kontext schlägt Pixel: Werden Layout-Constraints, Variablen und Komponentennamen übergeben, entsteht Code, der vorhandene Komponenten wiederverwendet, statt Markup zu duplizieren. Reine Bildeingabe zwingt das Modell, Hierarchie, Schriften und Abstände zu raten.
• Render-und-Vergleich-Schleife: Ein Agent mit Browser-Werkzeug (Playwright, Chrome DevTools MCP) rendert seine Ausgabe und vergleicht sie per Screenshot-Vergleich oder VLM-Bewerter mit der Referenz; das schließt einen großen Teil der Treuelücke.
• Mensch-in-der-Schleife (Human-in-the-Loop): Designer geben die visuelle Treue frei, Entwickler prüfen Architektur, Zustands- behandlung, Barrierefreiheit und Sicherheit vor dem Merge.

Datenaufbereitung

Benötigte Daten: Figma-Dateien mit Komponenten, Variablen und Design-Tokens, Screenshots oder Aufzeichnungen, Skizzen sowie die vorhandene Komponentenbibliothek und die Code-Konventionen. In einem KMU liegen diese in Figma, auf gemeinsamen Laufwerken, in E-Mails, als Fotos von Whiteboards und im Git-Repository.

Typische Lücken: unstrukturierte Figma-Dateien ohne Auto-Layout oder benannte Ebenen, keine Design-Tokens, eine undokumentierte Komponentenbibliothek, doppelte Komponenten, uneinheitliche Benennung zwischen Design und Code sowie Skizzen von schlechter Qualität.

Schritte der Aufbereitung: - Die Figma-Datei bereinigen: Ebenen benennen, Komponenten, Auto-Layout und Variablen verwenden. - Design-Tokens exportieren und Code-Komponenten zuordnen (PREP-012 für gemeinsame Definitionen). - Die Komponentenbibliothek und die Konventionen in einem kurzen maßgeblichen Leitfaden dokumentieren (PREP-013, PREP-014). - Goldstandard-Beispiele gut gebauter Bildschirme sammeln (PREP-016). - Visuelle Regressionstests als Auswertungsdatensatz einrichten (PREP-018). - Werkzeuge: Figma MCP/Dev Mode, Storybook, Playwright.

Grober Aufwandsanteil: mittel, etwa 25–35 Prozent, vor allem für die Pflege des Designsystems. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: B. Generierte Oberflächen müssen dem bestehenden Designsystem und der Codebasis folgen, was fertige Werkzeuge nur teilweise leisten; eine schlanke Pipeline auf APIs in EU-Regionen passt.
• Großunternehmen: B. Die Integration in Designsystem, CI und Prüfregeln zählt mehr als Nutzerlizenzen; A nur für isolierte Prototypen verwenden.
• Entwickler: C. Open-Weight-Modelle für Bild und Code sowie lokale Agenten halten Entwürfe und Code privat und erlauben Kostenkontrolle.

Weg A — Kaufen (Standardsoftware)

• Nativ im Design-Werkzeug: Figma (Dev Mode, Figma Make, Code Connect, offizieller MCP-Server) [3]; Builder.io (Visual Copilot), Anima, Locofy, Kombai.
• Prompt-to-UI-Generatoren: Vercel v0, Bolt.new, Lovable (Stockholm, EU), Replit, Google Stitch.
• IDE-/Agenten-Produkte: GitHub Copilot, Cursor, Claude Code, Windsurf, OpenAI Codex mit dem Figma-MCP- Server (siehe CODE-001, CODE-002).
• A wählen, wenn: wenige Teams, ein Standard-Webstack und keine strengen Vorgaben zur Datenresidenz für Entwürfe vorliegen. Prüfen Sie, wo Entwürfe und generierter Code verarbeitet werden und ob das Training mit Ihren Daten deaktiviert ist.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen)

• Modelle: multimodale Spitzenmodelle mit starker Codierfähigkeit (Claude, Gemini, GPT) oder die multimodalen Modelle von Mistral (EU-Anbieter) über Endpunkte in EU-Regionen (Vertex AI, Azure OpenAI, Amazon Bedrock Frankfurt/Paris, Mistral La Plateforme).
• Orchestrierung: ein Coding-Agent (Claude Code, Codex CLI, Cursor oder eine eigene Schleife) mit dem Figma-MCP- Server, einer Projekt-Regeldatei, die Ihr Designsystem beschreibt, und einem Playwright-MCP für Rendern und Vergleichen.
• Integration: In der CI ausführen, sodass ein Label „design-ready" an einem Ticket einen Branch, eine Vorschau- Bereitstellung (Vercel, Netlify, selbst betrieben) und einen PR zur Prüfung auslöst.
• B wählen, wenn: Sie eine etablierte Komponentenbibliothek haben und generierten Code wollen, der dazu passt.

Weg C — Selbst betreiben (Open Source)

• Modelle: multimodale Open-Weight-Modelle wie die Qwen-VL-Familie (Qwen2.5-VL / Qwen3-VL), Mistral Small multimodal, Gemma 3 sowie Codemodelle (Qwen-Coder, Devstral), bereitgestellt mit vLLM oder Ollama. Spezialisierte offene Werkzeuge: screenshot-to-code (abi/screenshot-to-code) [4], auf WebSight trainierte Modelle von Hugging Face.
• Agenten: OpenHands, Cline, Continue oder Aider, die ein lokales Modell ansteuern; Playwright zum Rendern.
• Hardware: HW3 (48–96 GB) für ein gutes VLM plus Coder; HW2 funktioniert mit kleinen Modellen bei geringerer Treue. Entwurfsdateien bleiben On-Premises, relevant für Verteidigung, öffentlichen Sektor oder Lieferketten der Automobilindustrie.

Weg D — Eigenes Training

Lohnt sich nur für große Organisationen mit einem proprietären Komponenten-Framework oder Zielplattformen außerhalb des Webs (z. B. eingebettete HMI-Toolkits, SAP UI5/Fiori, Qt). Benötigt Tausende Paare aus Entwurf und Code, die sich (im Stil von WebSight) aus der internen Komponentenbibliothek synthetisieren lassen und dann mit LoRA auf einem offenen VLM feingetunt werden.

Stand der Technik (2026)

• Agentische Schleife statt einmaligem Prompt: Die besten Ergebnisse kommen von Agenten, die strukturierten Designkontext lesen, rendern, vergleichen und iterieren, nicht von einem einzelnen Screenshot-Prompt.
• Protokolle: MCP ist zur Standardbrücke zwischen Design-Werkzeugen und Coding-Agenten geworden; der Figma-Server stellt Frames, Variablen, Komponenten-Metadaten und den Code von Make-Dateien bereit, in Remote- und Desktop-Varianten [3].
• Benchmarks: Design2Code [1] und Nachfolger (z. B. Web2Code, interaktionsbewusste und mehrseitige Benchmarks) zeigen stetigen Fortschritt, doch die Benchmarks nutzen überwiegend statische Seiten.
• Grenzen und Fehlerbilder: halluzinierte oder fehlende Texte und Bilder, falsches responsives Verhalten (ein Frame = ein Breakpoint), flache „Div-Suppe" ohne Semantik, ignorierte vorhandene Komponenten, nicht barrierefreie Ausgabe (fehlende Labels, Kontrast, Fokusreihenfolge), keine Geschäftslogik oder Zustände und Pixelgenauigkeits-Versprechen, die bei komplexen Animationen oder dichten Datentabellen nicht halten. Generierter Code kann außerdem Schriften, Icons oder Bildmaterial Dritter mit unklaren Lizenzen übernehmen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (vlm + llm-code + agent-framework): CODE-001 IDE-Assistenten, CODE-002 Coding-Agenten, CODE-007 Vibe Coding; ein selbst betriebener VLM-/Coder-Server (HW3) bedient alle.
• Qualitätsschranke: CODE-017 Barrierefreiheitstests und CODE-004 Testgenerierung (visuelle Regression, Komponententests) sollten für jeden generierten Bildschirm laufen; CODE-006 dokumentiert die Komponentenbibliothek.
• Vorgelagert: GEN-004 Grafikdesign-Generierung und Werkzeuge für Designsysteme liefern die Ausgangsentwürfe.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage; Abonnements pro Nutzer plus guthabenbasierte Nutzung, die mit den Iterationen wachsen kann.
• Weg B: 2–6 Wochen, um Designsystem, MCP, CI und Prüfregeln zu verbinden; die Token-Kosten pro Bildschirm sind gering im Vergleich zur Entwicklerzeit, doch Iterationsschleifen vervielfachen sie.
• Weg C: 1–3 Monate inkl. GPU-Server und Agenten-Feinabstimmung.
• Kennzahlen: Zeit von „design-ready" bis zum gemergten PR, Anteil des generierten Codes, der die Prüfung übersteht, Wiederverwendungsquote von Design-Tokens und Komponenten, Wert des visuellen Vergleichs, Barrierefreiheitsverstöße je Bildschirm, Nacharbeit nach der Design- Abnahme, Fehlerquote in generierten Komponenten.

Menschen & Veränderung

Beziehen Sie zuerst die Design-Leitung und die Frontend-Leitung ein, denn sie verantworten das Designsystem und die Code-Konventionen. Endnutzer sind die Entwickler und Designer, die die Ausgabe prüfen; beziehen Sie sie ab dem Pilot ein. IT/Sicherheit prüft, welche Entwürfe und welcher Code das Netz verlassen; Recht/Compliance prüft Lizenzen und Anbieterbedingungen (GUIDE-010, GUIDE-013). Die Geschäftsleitung legt Umfang und Budget fest (GUIDE-002).

Betriebsrat: abhängig. Design- und Code-Assistenten überwachen Beschäftigte selbst nicht, doch Werkzeug-Logs pro Nutzer können objektiv zur Überwachung geeignet sein und lösen dann die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG aus. § 90 Abs. 1 Nr. 3 verlangt eine rechtzeitige Unterrichtung, wenn KI Arbeitsabläufe verändert. Vereinbaren Sie, dass Logs nicht zur Leistungsbewertung genutzt werden (GUIDE-004). Öffentlicher Dienst: Personalrat.

Datenschutz: Entwürfe enthalten selten personenbezogene Daten, Screenshots realer Systeme können aber Kunden- oder Beschäftigtendaten zeigen; verpixeln oder ersetzen Sie diese, schließen Sie einen AVV ab und beziehen Sie im Zweifel die/den Datenschutzbeauftragte(n) ein (GUIDE-005).

KI-Kompetenz: Unterstützen Sie Designer und Entwickler mit Übung im Prompten und Prüfen (GUIDE-006). Typische Sorgen: Designer fürchten den Verlust des Handwerks, Entwickler fürchten unaufgeräumten Code. Begegnen Sie dem mit der Regel, dass generierter Code die normale Pull-Request-Prüfung und die Design-QA durchläuft. Pilotieren Sie mit einem Feature-Team (GUIDE-009); Menschen entscheiden über jede übernommene Änderung.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko; Entwicklungswerkzeuge sind keine Verwendung nach Anhang III. Die Pflicht zur KI-Kompetenz (Art. 4) gilt. Ist die generierte Oberfläche Teil eines Hochrisiko-Systems, gelten die Pflichten dieses Systems.
• DSGVO: Entwürfe und Screenshots können echte personenbezogene Daten enthalten (Kundennamen, Produktivbildschirme, Chatverläufe). Verwenden Sie bereinigte Mock-Daten, einen AVV mit dem Anbieter, eine EU-Region und Einstellungen ohne Training.
• Barrierefreiheitsrecht: Der European Accessibility Act (seit dem 28. Juni 2025 anwendbar) und EN 301 549 betreffen Online-Shops für Verbraucher, Bankdienstleistungen und E-Books; generierte Oberflächen müssen getestet werden, die Konformität darf nicht unterstellt werden [5].
• Geistiges Eigentum und Lizenzen: Das Klonen von Seiten Dritter per Screenshot kann Urheberrechte, Aufmachungsschutz oder Datenbankrechte verletzen; prüfen Sie Schriften, Icons und Bilder; dokumentieren Sie die Herkunft der Entwurfsvorlage.
• Sicherheit: Generierter Frontend-Code kann XSS, unsichere Abhängigkeiten oder offengelegte Schlüssel einführen; führen Sie SAST, Abhängigkeitsscans und Prüfung durch. Behandeln Sie Entwurfsdateien und MCP-Werkzeugausgaben als nicht vertrauenswürdige Eingabe (Prompt Injection über Text in Entwürfen oder Screenshots).
• Gegenmaßnahmen: Vorgaben des Designsystems in Regeldateien, verpflichtende Prüfung und CI-Schranken, visuelle und Barrierefreiheitstests, bereinigte Eingaben.

Erste Schritte

1. Eine klar abgegrenzte Komponentenbibliothek auswählen und ihre Regeln dokumentieren (Tokens, Benennung, zulässige Komponenten).
2. Einen Coding-Agenten mit dem Figma-MCP-Server verbinden und 5 bestehende Bildschirme gegen bekannte, gute Umsetzungen ausprobieren [3].
3. Einen Schritt zum Rendern und Vergleichen (Playwright-Screenshots) ergänzen und Treue sowie Prüfaufwand messen.
4. Vor der Ausweitung Barrierefreiheits- und visuelle Regressionsprüfungen in die CI aufnehmen.
5. Den Umgang mit Daten festlegen (EU-Region, kein Training, bereinigte Inhalte) und teamweise ausrollen.

Quellen

1. Si et al. — Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering — https://arxiv.org/abs/2403.09029
2. Hugging Face — From screenshots to HTML code: Introducing the WebSight dataset — https://huggingface.co/blog/websight
3. Figma — Figma MCP server documentation — https://developers.figma.com/docs/figma-mcp-server/
4. screenshot-to-code (open source) — https://github.com/abi/screenshot-to-code
5. European Commission — European Accessibility Act — https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en
6. Design2Code repository — https://github.com/NoviScl/Design2Code
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj