KI im Frontend & Design: vom Mockup zum Prompt

Vom Mockup zum Prompt

Lange lief Gestaltung über Zwischenschritte: Wireframe, Mockup, klickbarer Prototyp, dann die Übergabe an die Entwicklung. KI verkürzt diese Kette – aus einer Beschreibung entsteht direkt eine bedienbare Oberfläche, oft schon mit echtem Code statt nur einem Bild. Damit rückt das Gestalten näher an das fertige Produkt heran.

Dass das kein Nischenthema mehr ist, zeigt Figmas Branchenreport 2025: 85 % der befragten Designerinnen und Entwickler halten den Umgang mit KI für essenziell für ihren künftigen Erfolg, 78 % sagen, KI steigere ihre Effizienz. Auffällig ist ein Gefälle: Bei der Kern-Entwicklung (Code-Generierung) setzen 59 % der Entwickler KI ein, bei der Kern-Gestaltung (Asset-Erzeugung) nur 31 % der Designer – im Frontend ist die Technik also weiter als im klassischen Design.

„KI-Kompetenz essenziell für den Erfolg“

85 % (Figma 2025)

„KI steigert meine Effizienz“

78 %

MerksatzDie Frage verschiebt sich von „Wie zeichne ich das?“ zu „Wie beschreibe ich es so, dass es richtig gebaut wird?“.

Prompt zu Oberfläche: Design-to-Code

Den Kern bilden Werkzeuge, die aus einer Beschreibung eine bedienbare Oberfläche bauen – meist als modernen Frontend-Code (React, Tailwind, fertige Komponenten). v0 (Vercel) und Lovable erzeugen UIs und ganze Web-Apps aus Prompt oder Screenshot; Bolt (StackBlitz) baut im Browser und kann Design-Systeme aus Figma oder GitHub übernehmen; Figma Make erzeugt aus einer Beschreibung Prototyp und Code und greift dabei auf die eigenen Figma-Bibliotheken zu, damit das Ergebnis zum Design-System passt. Framer bringt denselben Gedanken in einen visuellen No-Code-Builder.

Für das lockere Drauflos-Bauen per Prompt – ohne den erzeugten Code Zeile für Zeile zu lesen – hat sich der Begriff „Vibe Coding“ etabliert (Anfang 2025 von Andrej Karpathy geprägt, 2025 sogar Wort des Jahres im Collins-Wörterbuch). Für schnelle Prototypen ist das stark; je näher es ans Produktiv-Frontend geht, desto wichtiger wird, was der Prompt vorgibt – wie im Beispiel:

Baue eine Preis-Sektion mit drei Tarif-Karten (Basis, Pro, Team).
Nutze unser Design-System: Tokens aus tokens.css, Schrift „Rubik“,
Eckradius 20px, Akzentfarbe --signal. Mobile-first, WCAG-AA-Kontraste,
sichtbare Fokus-Ringe. Pro-Karte hervorgehoben. Ausgabe: React + Tailwind.

Die Werkzeuge im Katalog (Frontend & Design) →

Welches Modell baut das schönere Design?

Welches KI-Modell die schönsten Oberflächen liefert, ist Stand Mitte 2026 eine Frage von Erfahrungswerten, nicht von Messwerten – einen unabhängigen Design-Benchmark gibt es nicht, die folgenden Urteile sind subjektiv (Tier C) und versions-, fast schon tagesabhängig. Ein Muster zeichnet sich dennoch ab: Unter Praktikern gelten Anthropics Claude-Modelle als die treffsichersten Gestalter. Opus 4.8 baut die kohärentesten, „schönsten“ UIs – und, wichtiger, es ist steuerbar: Gibt man ihm ein Lieblings-Design zurück, baut es sinnvoll darauf auf, statt bei jedem Versuch neu zu würfeln. Fable 5 gilt als stärkstes „One-Shot“-Modell für aufwändige Landingpages samt Scroll-Animationen (GSAP, three.js), schwächelt aber bei sach-logisch komplexer UX wie Flows und Diagrammen.

Die Gegenpole: Gemini liefert die größte gestalterische Vielfalt, aber „some of it is garbage“ – es braucht viele Rerolls und ignoriert oft Folge-Anweisungen. GPT-5.x ist stark im Coding, aber schwach im Design („card sickness“: immer dasselbe Karten-Layout). Geht es nicht ums Neuerstellen, sondern um den sauberen Umbau eines bestehenden Frontends, gilt Sonnet 4.6 als verlässliche, günstigere Wahl. Die Lehre dahinter: Modelle „gestalten“ nicht, sie pattern-matchen Templates – und ob ein Modell deine Vorgaben und Korrekturen aufnimmt, zählt am Ende mehr als der erste Wurf.

MerksatzFür treffsichere, iterierbare UIs greifen Praktiker zu Opus 4.8, für den spektakulären ersten Wurf zu Fable 5. Entscheidend ist nicht der schönste Erst-Entwurf, sondern wie gut ein Modell deine Korrekturen aufnimmt.

Opus 4.8 im Modellkatalog →Fable 5 im Modellkatalog →

Bilder, Icons & Assets

Neben der Oberfläche selbst hilft KI bei dem, was sie füllt: Bildmodelle erzeugen Illustrationen, Hintergründe, Moodboards oder Platzhalter-Grafiken und bearbeiten vorhandene Assets per Anweisung. Für Webdesignerinnen ersetzt das nicht die Bildsprache einer Marke, beschleunigt aber Entwürfe und Varianten.

Gerade hier ist der Abstand zum Frontend aber noch groß: Laut Figma-Report nutzen nur 31 % der Designer KI in der Kern-Gestaltung (Asset-Erzeugung). Wie diese Bildmodelle funktionieren – und woran man generierte Bilder erkennt – steht im Artikel zur multimodalen KI.

Wie Bild-, Audio- und Video-KI funktioniert →

Wo es heute klemmt

Der schnelle Anfang täuscht über den schweren Rest hinweg. Addy Osmani (Chrome-Team bei Google) nennt es das „70-%-Problem“: KI liefert rasch etwa 70 % – Gerüst, naheliegende Muster, eine Oberfläche, die funktionsfähig aussieht –, doch die letzten 30 % (Randfälle, Integration, Sicherheit, Wartbarkeit) bleiben so hart wie zuvor. Sein Bild dazu: Es könne „hinter den Kulissen mit Klebeband zusammengehalten“ sein.

Zwei Fallstricke sind für Oberflächen besonders relevant. Erstens Barrierefreiheit: Generierter Code ist nicht automatisch zugänglich. Vergleichsstudien finden gemischte Ergebnisse – Modelle können solide Strukturen liefern, produzieren aber auch neue Fehler (etwa nicht eindeutige ARIA-Attribute); Zugänglichkeit muss geprüft, nicht angenommen werden. Zweitens der Einheitslook und das Abdriften vom Design-System: Ohne klare Vorgaben entsteht generisches „KI-Standard“-Design, das die Markenidentität verfehlt.

Dieser „KI-Look“ hat wiederkehrende Verräter, an denen geübte Augen generierte Oberflächen erkennen: lila-pink-blaue Verlaufsflächen, Rausch-Texturen im Hintergrund, die immergleiche „Pille mit Punkt“, kursiv oder farblich abgesetzte Einzelwörter, „Es ist nicht X, es ist Y“-Sprache, dazu schwache Kontraste und abgeschnittener Text. Erfahrene Designer warnen zugleich vor einem Trugschluss: KI hebt vor allem die Mitte – fast jeder Entwurf wird „okay“ –, doch genau deshalb gilt „good enough is no longer good enough“. Wer sich abheben will, muss die Handarbeit dort investieren, wo die KI auf den Durchschnitt zieht: Strategie, Sachlogik und eine Hierarchie, die den Nutzen vor das Feature stellt.

KI liefert schnell …

~ 70 % – der Rest bleibt hart

MerksatzDie letzten 30 % – Randfälle, Barrierefreiheit, Wartbarkeit – sind die eigentliche Arbeit. Eine hübsche Oberfläche ist noch kein fertiges Frontend.

Praxis: das Design-System als Leitplanke

Aus der Praxis haben sich einige Hebel herausgebildet, um die KI auf gutes – statt durchschnittliches – Design zu ziehen (Erfahrungswissen, kein hartes Studienergebnis). Der erste: Gib ihr dein Design-System als Leitplanke. Tokens (Farben, Abstände, Radien), Typografie, Komponenten und Beispiele im Prompt halten das Ergebnis konsistent – Werkzeuge wie Bolt oder Figma Make können bestehende Systeme sogar direkt einlesen.

Der zweite Hebel überrascht und ist in A/B-Tests der wirkungsvollste: ein Gestaltungs-Leitfaden, den man dem Modell zusätzlich zu den Tokens mitgibt. Eine schlichte Markdown-Datei mit Geschmacks-Regeln – verbiete Standard-Schriften wie Inter oder Roboto und generische Lila-Verläufe, verlange eine charaktervolle Display-Schrift, eine klare Typo-Skala und genau ein einprägsames „Signature“-Element – hebt die Qualität aller Modelle sichtbar; ohne sie rutscht selbst Opus nach unten. In Coding-Agenten ist das ein Skill (in Claude Code etwa der mitgelieferte „/frontend-design“): eine wiederverwendbare Anweisungs-Datei, die der Agent in seinen Kontext lädt. Tokens sagen dem Modell, welche Werte es nehmen soll; der Leitfaden sagt ihm, welchen Geschmack.

Der dritte Hebel ist Iteration statt Würfeln. Füttere Referenzbilder und deinen eigenen Geschmack mit, statt den Default zu akzeptieren – der ist per Konstruktion „average“. Ein nützlicher Trick: Lass dir in einem Lauf gleich mehrere Varianten („Design 1 bis 5“) erzeugen; das Modell hält sie im Kontext auseinander und zwingt sich zu echten Unterschieden. Und: Behandle jede Ausgabe als Entwurf, nicht als Endstand – vieles lässt sich danach in reinem CSS nachschärfen. Barrierefreiheit, Responsive-Verhalten und Markentreue prüft und verantwortet weiterhin der Mensch. So wird KI zum Beschleuniger der gestalterischen Arbeit, nicht zu ihrem Ersatz.

/* Auszug aus dem Design-System, das man dem Werkzeug mitgibt */
:root {
  --signal: #6647cf;       /* Primärakzent (CTA, Marke) */
  --radius: 20px;          /* Eckradius der Karten */
  --font: "Rubik", system-ui, sans-serif;
}

# Frontend-Design – Hausregeln (wird zusätzlich zu den Tokens mitgegeben)
- KEINE Standard-Schriften als Display (Inter, Roboto, system-ui), KEINE lila/pink Verläufe.
- Eine charaktervolle Display-Schrift, sparsam eingesetzt; klare Typo-Skala mit Absicht.
- Genau EIN einprägsames Signature-Element; alles drumherum ruhig und diszipliniert.
- Quality-Floor ohne Ankündigung: Reduced-Motion respektieren, sichtbarer Fokus-Ring, AA-Kontraste.

MerksatzDrei Hebel für gutes statt durchschnittliches Design: Tokens als Leitplanke, ein Gestaltungs-Leitfaden für den Geschmack, Iteration mit eigenem Auge. KI beschleunigt das Gestalten – verantworten muss es weiter der Mensch.

Das Gegenstück: KI-Coding mit Agenten →Frontend- & Design-Werkzeuge ansehen →

DESIGN.md: das Design-System als Datei für den Agenten

Die Leitplanke-Idee bekommt gerade ein offenes Format. Google Labs hat im April 2026 DESIGN.md open-sourced (Apache 2.0) – herausgelöst aus Googles Design-Werkzeug Stitch – eine Datei, die einem Coding-Agenten ein ganzes Design-System maschinenlesbar beschreibt. Statt die Ästhetik bei jedem Prompt neu zu erklären, liegt sie als eine Datei im Projekt, die der Agent dauerhaft liest. Der Aufbau ist zweiteilig: ein YAML-Frontmatter mit den Tokens (Farben, Typografie, Abstände, Eckradien, Komponenten) und darunter ein Markdown-Teil mit der Begründung – die Tokens geben dem Agenten die exakten Werte, der Fließtext sagt ihm, warum sie so sind und wie er sie anwendet.

Das ist die visuelle Schwester eines Musters, das im KI-Coding längst Alltag ist: Projekt-Kontext als versionierte Datei. Wie eine CLAUDE.md einem Coding-Agenten die Konventionen eines Projekts mitgibt oder ein Skill eine wiederkehrende Aufgabe kapselt, gibt eine DESIGN.md ihm das Design-System – und ist damit die offene, herstellerneutrale Gegenform zu geschlossenen Werkzeugen wie Anthropics Claude Design, das ein Design-System direkt aus Codebasis und Design-Dateien lernt. Mitgeliefert wird eine CLI (das npm-Paket @google/design.md) mit Linter, die Tokens gegen die Spezifikation prüft (nicht auflösbare Referenzen, Zirkelbezüge, ungültige Werte) und nach Tailwind oder ins W3C-DTCG-Format exportiert.

Ein Vorbehalt gehört dazu: Das Format trägt selbst die Versionsmarke „alpha“ und wird aktiv weiterentwickelt – die Spezifikation kann sich noch ändern. Tragfähig ist heute deshalb weniger die feste Syntax als die Disziplin dahinter: Tokens und ihre Begründung an einem Ort, versioniert, maschinenlesbar. Genau das ist die Leitplanke aus dem vorigen Abschnitt, nur formalisiert.

---
# DESIGN.md – maschinenlesbare Tokens (Auszug, illustrativ)
colors:
  signal: "#6647cf"      # Primärakzent: CTA, Marke
  papier: "#fbf7ee"
typography:
  fontFamily: "Rubik, system-ui, sans-serif"
rounded:
  karte: 20px
components:
  knopf:
    background: signal   # verweist auf das Farb-Token oben
    rounded: karte
---
## Komponenten — der Markdown-Teil erklaert das „Warum": signal nur fuer CTAs, nie fuer Fliesstext.

MerksatzDESIGN.md macht aus der Leitplanke ein Format: das Design-System als eine Datei, die der Agent liest – die visuelle Schwester von CLAUDE.md. Noch Alpha, aber die Disziplin trägt schon heute.

Projekt-Kontext für Coding-Agenten: KI-Coding →Depesche: Google Labs open-sourct DESIGN.md →