Wenn ein Coding-Agent eine App entwickeln soll, könnte man ihm theoretisch einfach sagen:
„Baue mir einen Check-in-Screen für eine Zeiterfassungs-App.“
Wahrscheinlich würde dabei sogar etwas Brauchbares entstehen.
Für einen professionellen Entwicklungsprozess reicht mir das allerdings nicht.
Denn damit würde die KI zwei unterschiedliche Aufgaben gleichzeitig übernehmen:
Sie würde das Produkt gestalten und dieses Design unmittelbar implementieren.
Ich möchte diese Schritte bewusst voneinander trennen.
Mein Workflow sieht deshalb so aus:
Idee → Design → visuelles Review → Freigabe → Implementierung
Dafür braucht die KI Zugriff auf ein Design-Tool – und genau hier wird das Model Context Protocol (MCP) interessant.
Warum überhaupt ein Design-Tool?
Gerade mit KI könnte man sich fragen, warum der Zwischenschritt über Figma oder Penpot überhaupt noch notwendig ist.
Claude kann schließlich auch direkt Compose oder SwiftUI erzeugen.
Für mich gibt es darauf eine einfache Antwort:
Weil Code keine gute gemeinsame Grundlage für eine Designentscheidung ist.
Nehmen wir an, Claude erstellt einen Screen und grundsätzlich gefällt mir das Ergebnis. Ich möchte aber:
- den primären Button größer machen,
- die Farbe ändern,
- zwei Elemente anders anordnen,
- Abstände verändern,
- die Navigation überarbeiten.
Natürlich könnte ich Claude diese Änderungen direkt am Code vornehmen lassen.
Dann existiert das vereinbarte Design aber nur noch implizit innerhalb der jeweiligen Implementierung.
Noch problematischer wird das bei mehreren Plattformen.
Bei meinem Beispielprojekt existieren schließlich:
Jetpack Compose für Android und SwiftUI für iOS.
Welche davon ist dann die visuelle Referenz?
Deshalb möchte ich ein davon unabhängiges Design haben.
Das Design beschreibt, was gebaut werden soll. Der Code beschreibt, wie es auf der jeweiligen Plattform umgesetzt wird.
MCP: Die Verbindung zwischen Claude und dem Design-Tool
Damit Claude Code mit einem Design-Tool arbeiten kann, braucht der Agent eine Schnittstelle.
Hier kommt MCP ins Spiel.
MCP steht für Model Context Protocol und ermöglicht es einem KI-Agenten, externe Werkzeuge anzusprechen.
Statt dass ich beispielsweise selbst einen Screen in einem Design-Tool anlege, kann Claude über einen entsprechenden MCP-Server mit diesem Werkzeug kommunizieren.
Damit wird ein Auftrag wie dieser möglich:
„Erstelle einen Check-in-Screen für unsere Zeiterfassungs-App und lege das Design im Design-Projekt ab.“
Der entscheidende Unterschied:
Claude erzeugt nicht sofort App-Code.
Das Ergebnis ist zunächst ein Design, das ich überprüfen und verändern kann.
Figma war meine erste Wahl
Für diesen Workflow war Figma zunächst die naheliegende Lösung.
Figma ist etabliert, eignet sich hervorragend als visuelle Source of Truth und bietet eine MCP-Integration.
Die Idee war deshalb ziemlich simpel:
- Claude Code mit Figma verbinden.
- Claude ein UI entwerfen lassen.
- Das Ergebnis in Figma überprüfen.
- Änderungen am Design durchführen.
- Erst anschließend Compose und SwiftUI erzeugen lassen.
Technisch ließ sich die Verbindung auch herstellen.
In der praktischen Nutzung zeigte sich allerdings ein entscheidender Punkt:
Die MCP-Nutzung hängt stark vom verwendeten Figma-Plan und Sitz ab.
Das Problem mit den Figma-MCP-Limits
Bei meinem Test stand zunächst ein Figma-Starter-Plan zur Verfügung.
Das Problem dabei: Für bestimmte MCP-Aufrufe steht in dieser Konstellation nur ein sehr kleines monatliches Kontingent zur Verfügung.
Und ein Coding-Agent kann erstaunlich schnell mehrere Tool-Aufrufe benötigen.
Zum Beispiel, um:
- vorhandene Libraries zu untersuchen,
- Design-Systeme zu suchen,
- Dateien zu lesen,
- Komponenten zu analysieren,
- anschließend das eigentliche Design zu erzeugen.
In meinem Fall war das verfügbare Kontingent bereits durch wenige vorbereitende Aufrufe ausgeschöpft, bevor der eigentliche Screen vollständig erstellt werden konnte.
Das ist eine wichtige Erkenntnis für agentische Workflows:
Nicht nur die Existenz einer MCP-Schnittstelle ist entscheidend. Auch deren Nutzungsmodell muss zum Agenten-Workflow passen.
Das bedeutet ausdrücklich nicht, dass Figma für KI-gestützte Entwicklung ungeeignet ist.
Mit einem passenden Tarif kann Figma weiterhin eine sehr interessante Lösung sein.
Für meinen konkreten Workflow wollte ich jedoch zunächst einen Weg finden, der sich ohne ein zusätzliches Upgrade sinnvoll ausprobieren und einsetzen lässt.
Der überraschend gute Zwischenschritt: HTML und CSS
An diesem Punkt habe ich eine andere Möglichkeit genutzt.
Claude kann ein UI schließlich auch als HTML und CSS erzeugen.
Für meinen Zeiterfassungs-Screen entstand dadurch innerhalb kurzer Zeit ein kompletter Prototyp mit:
- White-Label-Branding
- Begrüßung
- aktuellem Arbeitsstatus
- großer Zeitanzeige
- Check-in-/Check-out-Button
- Beginn- und Pauseninformationen
- Buchungsliste
- Bottom Navigation
Der Screen lief direkt lokal im Browser.
Und für die erste Visualisierung einer Produktidee funktioniert dieser Ansatz erstaunlich gut.
Gerade für POCs und frühe Produktideen halte ich diesen Ansatz inzwischen für sehr interessant.
Bevor überhaupt ein Android- oder iOS-Projekt entsteht, kann man bereits beurteilen:
Ist das überhaupt die Richtung, in die wir wollen?
Warum HTML trotzdem nicht meine Source of Truth wurde
Der HTML-Prototyp hatte allerdings genau das Problem, das ich ursprünglich vermeiden wollte.
Er war zwar schnell erstellt und sah gut aus – aber für Designänderungen war er nicht ideal.
Natürlich könnte ich Claude sagen:
„Mach den Button größer und verschiebe die Statusanzeige weiter nach oben.“
Claude würde daraufhin HTML und CSS ändern.
Aber ich möchte ein Design auch selbst visuell bearbeiten können.
Element auswählen.
Verschieben.
Farbe ändern.
Abstand verändern.
Text anpassen.
Genau dafür sind Design-Tools wie Figma oder Penpot wesentlich angenehmer.
Der HTML-Prototyp ist deshalb für mich heute eher:
eine schnelle visuelle Skizze als ein endgültiges Design-Artefakt.
Penpot als Alternative
Damit kam Penpot ins Spiel.
Penpot verfolgt einen ähnlichen grundlegenden Ansatz wie Figma: Screens und Komponenten können visuell erstellt und bearbeitet werden.
Für meinen Workflow war vor allem entscheidend, dass ich Penpot mit Claude verbinden und anschließend weiterhin selbst im visuellen Editor arbeiten kann.
Damit war die gewünschte Trennung wieder hergestellt:
Claude erstellt → ich bewerte → ich ändere → Claude implementiert
Das Design ist dabei nicht nur ein Zwischenprodukt für den Agenten.
Es bleibt die gemeinsame visuelle Referenz.
So sieht mein aktueller Design-Workflow aus
Aus diesen Erfahrungen hat sich für mich ein relativ klarer Ablauf ergeben.
1. Produktidee beschreiben
Zunächst bekommt Claude die fachliche Aufgabe.
Zum Beispiel:
„Wir benötigen für unsere Zeiterfassungs-App einen Screen, auf dem ein Mitarbeiter seine bisherigen Arbeitszeiten nach Tagen einsehen kann.“
2. Design erstellen lassen
Claude erstellt zunächst ausschließlich das Design.
Noch keinen Compose-Code. Noch kein SwiftUI.
3. Design selbst prüfen
Jetzt kommt der wichtigste Schritt:
Ich sehe mir das Ergebnis an.
Dabei geht es nicht nur um Optik, sondern beispielsweise um:
- Informationshierarchie
- Bedienbarkeit
- Abstände
- Zustände
- Navigation
- Accessibility
- Plattformtauglichkeit
4. Änderungen durchführen
Änderungen können entweder direkt im Design-Tool erfolgen oder wieder über Claude angestoßen werden.
5. Design freigeben
Erst wenn das Design fachlich und visuell passt, wird es zur Grundlage der Implementierung.
6. Android und iOS implementieren
Nun bekommt Claude beispielsweise den Auftrag:
„Das Design ist freigegeben. Implementiere den Screen entsprechend unserem Engineering Contract für Android und iOS.“
Damit wechselt der Agent bewusst von der Rolle des Designers in die Rolle des Entwicklers.
Warum ich Design und Implementierung bewusst trenne
Das klingt zunächst vielleicht nach einem zusätzlichen Arbeitsschritt.
Eigentlich passiert aber das Gegenteil.
Änderungen sind im Designstadium billig.
Wenn eine Navigation nicht funktioniert oder der Aufbau eines Screens nicht überzeugt, möchte ich das erkennen, bevor zwei native Implementierungen existieren.
Das wird mit KI sogar noch wichtiger.
Denn weil KI sehr schnell Code produzieren kann, besteht die Gefahr, schlechte Entscheidungen ebenfalls sehr schnell zu implementieren.
Schneller Code ist nur dann ein Vorteil, wenn vorher klar ist, was gebaut werden soll.
Das ist für mich eine der wichtigsten Erkenntnisse beim Arbeiten mit Coding-Agenten.
Figma, Penpot oder HTML – was würde ich wann einsetzen?
Ich sehe die drei Varianten deshalb nicht unbedingt als direkte Konkurrenten.
HTML/CSS eignet sich hervorragend, wenn ich extrem schnell aus einer Idee etwas Sichtbares machen möchte.
Penpot ist für meinen aktuellen Workflow interessant, wenn Claude und ich gemeinsam an einem editierbaren Design arbeiten sollen, ohne dass ein kleines MCP-Kontingent den Workflow ausbremst.
Figma bleibt eine sehr interessante Lösung, insbesondere wenn es ohnehin bereits im Unternehmen eingesetzt wird und ein entsprechender Plan für die MCP-Nutzung vorhanden ist.
Die eigentliche Architektur meines Workflows hängt deshalb bewusst nicht an einem bestimmten Anbieter.
Das Design-Tool kann sich ändern.
Das Prinzip bleibt:
Ein editierbares und freigegebenes Design bildet die Brücke zwischen Produktidee und Implementierung.
Der nächste Schritt: Aus Design wird echter App-Code
Sobald das Design freigegeben ist, beginnt der technische Teil.
Und hier wird ein zweiter Baustein wichtig:
Claude muss wissen, wie ich Software entwickeln möchte.
Welche Architektur soll verwendet werden?
Wo gehört State hin?
Wie werden Dependencies injiziert?
Welche Teile gehören in Kotlin Multiplatform?
Wie sollen Compose und SwiftUI aufgebaut werden?
Dafür bekommt Claude in meinen Projekten einen eigenen Engineering Contract.
Fazit
KI kann heute problemlos einen Screen erzeugen.
Die spannendere Frage ist für mich inzwischen aber nicht mehr:
„Kann die KI ein UI bauen?“
Sondern:
„Wie integriere ich KI so in den Designprozess, dass das Ergebnis kontrollierbar, editierbar und später sauber implementierbar bleibt?“
Genau deshalb trenne ich Design und Implementierung bewusst voneinander.
Der Coding-Agent darf Designvorschläge erstellen.
Er darf sie nach Feedback verändern.
Und er darf das freigegebene Design anschließend implementieren.
Aber zwischen diesen Schritten gibt es weiterhin eine bewusste menschliche Entscheidung.
Figma, Penpot und selbst ein einfacher HTML-Prototyp können dabei unterschiedliche Rollen übernehmen.
Für meinen aktuellen Workflow hat sich vor allem ein Prinzip bewährt:
Erst sichtbar machen. Dann entscheiden. Dann implementieren.