Vom Prompt zur Anwendung: Warum der Designschritt zählt

Wer heute mit KI-gestützten Coding-Assistants arbeitet, kennt das Versprechen: Eine Beschreibung eingeben und wenige Sekunden später steht ein funktionierendes Interface. Tools wie Cursor, Claude Code oder GitHub Copilot liefern dabei zunehmend beeindruckende Ergebnisse. Doch was in einer isolierten Demo überzeugt, offenbart in der Projektpraxis schnell eine strukturelle Lücke.

Professionelle Anwendungen entstehen nicht im Vakuum. Sie bewegen sich innerhalb definierter Farbskalen, Typographien, Komponentenbibliotheken und Corporate-Design-Vorgaben. Ein per Prompt direkt generiertes UI kennt davon nichts. Technisch korrekt, visuell abweichend und der Nachbearbeitungsaufwand landet trotzdem beim Team.

Die bessere Frage lautet also nicht: Wie kann KI schneller Code erzeugen? Sondern: Wie kann KI im Designprozess unterstützen, bevor überhaupt Code entsteht?

Design Tokens als Einstieg

Das zentrale Problem bei KI-gestützter UI-Generierung ist Kontextlosigkeit. Das Tool weiß nicht, wie das bestehende System aussieht.

Ein praktikabler erster Schritt: Das Design-System in eine Form bringen, die KI-Tools verarbeiten können. Hier haben sich Design Tokens bewährt. Sie beschreiben visuelle Eigenschaften wie Farben, Abstände und Typografie in strukturierter, codeähnlicher Form und sind damit deutlich näher an Entwicklungsartefakten als an klassischen Figma-Dateien.

In der Praxis lässt sich dieser Schritt mit einem LLM beschleunigen. Bestehende, oft inkonsistent dokumentierte Styles aus einem Design-System werden in konsistente Token-Strukturen überführt. Das Ergebnis ist noch kein Design, sondern ein Vokabular, ein klar definierter Gestaltungsraum, innerhalb dessen KI tatsächlich konsistente Ergebnisse liefern kann.

Ohne diesen Schritt tendieren KI-generierte Interfaces dazu, generisch zu sein. Mit ihm entsteht Konsistenz, auch bei automatisierter Generierung. Soweit die konzeptuelle Grundlage. Die entscheidende Frage ist, wie gut aktuelle Tools diesen Ansatz bereits unterstützen und wo sie an ihre Grenzen stoßen.

Was die Tools heute können

Auf Basis dieser Überlegungen habe ich drei Tools evaluiert, die aktuell KI-gestützte Designgenerierung anbieten: Google Stitch, Figma mit seinen integrierten KI-Funktionen und Claude Design von Anthropic.

Google Stitch

Von den getesteten Tools bietet Stitch den niedrigsten Einstieg. Ein Prompt genügt und das Tool generiert einen strukturell soliden ersten Entwurf. URLs lassen sich als visuelle Referenz hinterlegen, was die Orientierung an bestehenden Produkten erleichtert. In Abbildung 1 ist dieser Workflow sichtbar: Links erklärt der KI-Assistent seine Designentscheidungen, in der Mitte zeigt Stitch das extrahierte Design-System mit Typografie und Farbpalette, rechts ein daraus generiertes Blog-Layout im codecentric-Stil. Die Markenfarbe, die Schrifthierarchie, das Grid, all das leitet Stitch aus der hinterlegten URL ab. Wie tief diese Integration tatsächlich reicht, zeigt ein Blick auf die technische Grundlage.

Abb. 1: Stitch-Canvas mit KI-Chat (links), extrahiertem Design-System (Mitte) und generiertem Blog-Layout (rechts)

Stitch setzt dabei auf DESIGN.md, ein Markdown-basiertes Format, das Farben, Typografie, Spacing und Komponenten-Patterns in einer für KI-Agents lesbaren Struktur beschreibt. Die Datei lässt sich unter anderem aus einer URL extrahieren und ist als Open-Source-Spezifikation auch außerhalb von Stitch einsetzbar. In der Praxis bleibt die Integration allerdings eingeschränkter als es zunächst wirkt: DESIGN.md beschreibt Regeln und Tokens, doch Stitch erzeugt daraus keine wiederverwendbaren Komponenten im Sinne eines klassischen Design-Systems. Die generierten Elemente bleiben eigenständige Layer. DESIGN.md übernimmt damit konzeptuell die Rolle von Design Tokens, bleibt aber auf der Ebene von Regeln und visueller Orientierung, ohne daraus echte, wiederverwendbare Komponenten zu erzeugen. Das eignet sich für schnelle Exploration und frühe Prototypen, aber nicht als dauerhafter Baustein in einem komponentenbasierten Designprozess.

Figma mit KI-Funktionen

Figma hat den Vorteil, dass man sich bereits in der Umgebung befindet, in der Designs tatsächlich gepflegt und weiterentwickelt werden. Aktuell bietet Figma zwei KI-gestützte Zugänge: First Draft generiert direkt auf dem Design-Canvas erste Layouts aus Beschreibungen. Dabei nutzt es Figma-eigene Wireframing- und Design-Bibliotheken als Grundlage und eignet sich vor allem für schnelle visuelle Explorationen. Figma Make hingegen ist ein separater AI App Builder, der funktionale, klickbare Prototypen erzeugt. Die Ergebnisse sind kein statisches Design, sondern lauffähige Anwendungen mit Interaktionen und Navigation. Figma Make-Prototypen lassen sich anschließend in Figma Design einbetten und dort weiterbearbeiten.

Für eine vollständige Integration erfordert der Einstieg allerdings mehr Vorbereitung als bei Stitch. In meinem Test sah der Workflow so aus: Zunächst ein Design-System in Figma Make generieren lassen, das Ergebnis in Figma Design überführen und dort als Bibliothek aufbereiten, und anschließend dieses Design als Referenz für neue Projekte in Figma Make nutzen. Abbildung 2 zeigt das Ergebnis dieses Prozesses: Drei separate Figma-Dateien, ein Blog-Design, ein Design-System und eine strukturierte Token-Sammlung, die angelegt und gepflegt werden müssen, bevor die KI-gestützte Generierung konsistente Ergebnisse liefern kann.

Abb. 2: Figma-Projektübersicht mit den drei Dateien, die für einen KI-gestützten Blog-Design-Workflow vorbereitet werden mussten

Figmas zweiter KI-Zugang, First Draft arbeitet direkt auf dem Design-Canvas und eignet sich für schnelle Layoutexplorationen. Eine wichtige Einschränkung: KI-gestützte Änderungen lassen sich ausschließlich auf Elemente anwenden, die initial von der KI generiert wurden. Sobald ein Element manuell bearbeitet wurde, scheidet es aus dem KI-Workflow aus.

Anders als Stitch kann Figma keine Webadressen als Referenz abfragen. Wer ein bestehendes Produkt als visuelle Vorlage nutzen möchte, ist auf manuelle Screenshots oder zuvor erstellte Design-Tokens angewiesen.

Beide Tools haben also denselben strukturellen blinden Fleck: Sie generieren Interfaces, aber die Ergebnisse sind eigenständige Layer ohne Verbindung zu echten Komponenten des bestehenden Systems.

Claude Design: ein anderer Ansatz

Während dieser Artikel entstand, veröffentlichte Anthropic Claude Design. Das Tool setzt konzeptionell an genau der Stelle an, die bei Stitch und Figma offen bleibt.

Statt das Design-System als nachgelagerte Importoption zu behandeln, macht Claude Design es zur Grundlage jedes Projekts. Beim Onboarding liest das Tool bestehende Informationen, wie etwa eine Codebase oder vorhandene Design-Dateien und leitet daraus ein Design-System ab, inklusive Farben, Typografie und Komponenten-Patterns. Abbildung 3 zeigt diesen Schritt: Claude Design hat die codecentric-Website analysiert und daraus ein vollständiges Design-System extrahiert, inklusive der verwendeten Markenschriften. Im Chat links ist sichtbar, wie das Tool Font-Probleme eigenständig erkennt und korrigiert. Wo Lücken im System bestehen, etwa fehlende Schriftarten oder unvollständige Farbdefinitionen, weist Claude Design aktiv darauf hin und bietet an, diese zu schließen. Jedes nachfolgende Projekt kann automatisch auf dieses System zurückgreifen.

Abb. 3: Design-System-Onboarding in Claude Design. Das Tool hat Farben, Typografie und Layout-Patterns aus der codecentric-Website extrahiert und als projektübergreifendes System bereitgestellt

Das ist der entscheidende konzeptionelle Unterschied zu Stitch und Figma: Claude Design muss nicht wissen, was Design Tokens sind, weil es die Informationen direkt aus dem Code bezieht. CSS-Variablen, Tailwind-Konfigurationen, bestehende Komponentendefinitionen, all das liest das Tool und baut daraus implizit ein kohärentes System auf. Design Tokens als manueller Eingabeschritt entfallen, aber das Konzept dahinter, nämlich dass visuelle Eigenschaften strukturiert und benannt vorliegen müssen, bleibt die Voraussetzung. Wer eine sauber strukturierte Codebase mitbringt, profitiert sofort. Wer das nicht tut, bekommt auch hier kein konsistentes System aus dem Nichts.

Der Workflow zur gewünschten Anwendung (in unserem Beispiel der codecentric Blog) läuft dann iterativ. Grundlage ist das zuvor erstellte Design-System. Claude greift automatisch auf die extrahierten Farben, Schriften und Komponenten zurück. In Abbildung 4 ist dieser Prozess sichtbar: Links arbeitet Claude eine strukturierte Aufgabenliste ab, vom Projekt-Setup über den HTML-Build bis zur finalen Politur. Rechts entsteht das Blog-Design "Aus dem Maschinenraum" im codecentric-Stil. Das Tweaks-Panel ermöglicht dabei gezielte Anpassungen an Brand-Modus, Card-Layout und Highlight-Verhalten, ohne den gesamten Entwurf neu generieren zu müssen.

Abb. 4: Claude Design Canvas mit iterativem Workflow (links: Aufgabenliste und Chat) und generiertem Blog-Layout (rechts). Das Tweaks-Panel erlaubt gezielte Anpassungen an Layout und Branding

Ein weiterer Unterschied ist der integrierte Handoff-Mechanismus: Ist ein Design bereit zur Implementierung, kann es als Bundle direkt an Claude Code übergeben werden. Das Bundle ist für Claude Code optimiert und unterstützt dementsprechend besonders gut bei der Überführung von Design zu Code. Für Teams, die nicht ausschließlich im Anthropic-Ökosystem arbeiten, gibt es Exportmöglichkeiten nach Canva, als PDF, PPTX oder standalone HTML.

Einschränkungen: Claude Design befindet sich noch in Research Preview. In meinen Tests sind Inline-Kommentare gelegentlich verloren gegangen, und bei größeren Codebasen kommt es zu merklichen Lags. Zudem ist die System-Integration, die das Tool verspricht, stark davon abhängig, wie gut die eigene Codebase und die Design-Dateien strukturiert sind. Wer kein gepflegtes Design-System mitbringt, bekommt auch hier nur begrenzte Konsistenz. Das Tool löst das Grundproblem also nicht von selbst, es setzt voraus, dass das System bereits existiert.

Der Übergang von Design zu Code

Unabhängig vom Tool bleibt der Übergang von Design zu Code ein kritischer Moment.

In der Praxis funktioniert dieser Übergang besser, wenn das Design strukturelle Informationen trägt, nicht nur visuelle. Design Tokens, klar benannte Komponenten und definierte Variablen helfen KI-Tools dabei, den Intent hinter einem Design zu verstehen, nicht nur das Erscheinungsbild.

Ebenso wichtig ist der Übergabeprozess, welcher explizit gestaltet werden sollte. Ein Prompt wie „Implementiere dieses Design" ohne weitere Informationen führt zu inkonsistenten Ergebnissen. Wer das Design-System referenziert, spezifische Komponenten benennt und technische Constraints kommuniziert, bekommt deutlich bessere Ausgaben.

KI-generierter Frontend-Code sollte als Ausgangspunkt behandelt werden, nicht als Endprodukt. Review, insbesondere für Accessibility, Performance und Konsistenz mit bestehendem Code, bleibt notwendig.

Fazit

Die eigentliche Erkenntnis ist weniger technisch als strukturell: KI im Frontend entfaltet ihr Potenzial nicht durch freie Generierung, sondern durch geführte Exploration innerhalb definierter Systeme.

Design Tokens sind dabei ein zentrales Konzept, auch wenn sie nicht überall explizit als solche auftauchen. Bei manchen Systemen müssen sie manuell als Eingabe bereitgestellt werden, weil die Tools keinen Zugriff auf das bestehende System haben. Bei Claude Design stecken sie implizit in der Codebase, die das Tool beim Onboarding einliest. Das Format ändert sich, die Grundidee bleibt dieselbe: Visuelle Eigenschaften müssen strukturiert und benannt vorliegen, damit KI konsistente Ergebnisse liefern kann.

Die aktuelle Toollandschaft ist in Bewegung. Stitch für schnelle, systemunabhängige Exploration; Figma für den kollaborativen Designprozess, sobald die KI-Integration dort weiter ausgereift ist; Claude Design als konzeptuell interessantester Ansatz, der aber voraussetzt, dass das eigene System bereits in einem strukturierten Zustand ist. Kein Tool löst heute alle Anforderungen vollständig. Die relevante Frage ist nicht mehr „Kann KI ein Interface generieren?", sondern „Kann KI ein Interface generieren, das in mein System passt?"

Wer diese Frage für das eigene Projekt angehen will, sollte nicht mit der Anwendung beginnen, sondern mit dem Design-System.