KI-Prototyping für UX Designer: Wie ich meinen eigenen Workflow entwickelt habe

Transparenzhinweis: Dieser Artikel wurde auf Basis meiner eigenen Erfahrungen und der Entwicklung von red-create-prototyp-project mit Unterstützung von Claude (Anthropic) verfasst. Die Inhalte, Bewertungen und Einschätzungen stammen von mir – die Formulierung hat die KI übernommen.

KI-Prototyping klingt verlockend: interaktive Prototypen in Stunden statt Wochen, ohne auf Entwickler-Kapazitäten zu warten. Als UX Designer habe ich das selbst erlebt – und bin dabei auf ein Problem gestoßen, das erst sichtbar wird, wenn man es zum zweiten Mal versucht.

Interaktive Prototypen sind für viele UX-Designer ein blinder Fleck – nicht weil sie nicht wissen, was sie brauchen, sondern weil sie es schlicht nicht selbst bauen können. Zu komplex für Figma. Zu banal für echte Entwickler. Genau da steckt man fest – immer dann, wenn es wirklich darauf ankommt.

Ich habe Frontend-Erfahrung aus einem früheren Berufsleben. Ich verstehe, was ein Component ist, ich kann HTML und CSS schreiben, ich weiß, warum State-Management wichtig ist. Genug, um zu beurteilen, was realistisch ist. Nicht genug, um selbst interaktive Prototypen zu bauen, die sich wie echte Software anfühlen. Jahrelang war meine Lösung: Entwickler fragen. Und jahrelang war die Antwort: „Gerade keine Kapazität."

KI öffnet die Tür zum Prototyping – aber löst nicht das eigentliche Problem

Anfang 2026 habe ich das erste Mal systematisch mit KI-gestütztem Prototyping experimentiert. Das Ergebnis war beeindruckend: eine vollständige interaktive Simulation in etwa drei Stunden – drei Nutzerpfade, Wizard-Flows, Mock-Daten, Feedback-System. Darüber habe ich hier ausführlich geschrieben.

Begeistert. Und dann kam das nächste Projekt.

Neue Session. Ich fange bei Null an. Gleiche Architekturentscheidungen treffen. Gleiche Fehler machen. Gleiche Fragen stellen. Das Wissen aus der letzten Session existiert nicht mehr – weder als strukturierter Workflow in meinem Kopf, noch in einem System, das es tragen könnte.

Das ist das eigentliche Problem mit KI-Prototyping: nicht die Qualität des Outputs. Sondern die fehlende Reproduzierbarkeit. Jede Session ist eine Einwegrakete.

Inspiration und ein anderer Ansatz für KI-Workflows im UX Design

Bei meiner Recherche bin ich auf Alex Sprogis' AI Coding Starter Kit gestoßen. Der Ansatz ist stark: Workflows selbst designen statt nur Werkzeuge benutzen. Statt jedes Mal neu anzufangen, einen strukturierten Rahmen aufbauen, der Wissen persistent macht. Genau das, was ich gesucht hatte.

Alex' Kit ist dabei konsequent auf sein Ziel ausgerichtet: production-ready Web-Apps für Entwickler und Founder, mit festem Tech-Stack, vollständiger Testabdeckung und Sicherheits-Audit. Das ist für dieses Ziel absolut richtig.

Mein Ziel als UX Designer ist ein anderes. Ich brauche keinen produktionsfähigen Code – ich brauche einen überzeugenden Prototypen, den ich Testnutzern in die Hand geben kann. Was ich stattdessen brauche: KI-gestützte Anforderungsklärung auf Datenbasis, einen eigenen Schritt für UX-Entscheidungen im Workflow, und eine direkte Verbindung zwischen Research-Ergebnissen und Feature-Spezifikationen. Technologie ist dabei Mittel zum Zweck – kein fester Stack.

Das Kit von Alex zu nehmen und umzubauen hätte nicht funktioniert. Die Prioritäten sind zu verschieden. Also habe ich die Idee – einen strukturierten KI-Workflow zu designen – aus meiner Perspektive neu gedacht und von Grund auf selbst entwickelt.

Das red-proto Framework: KI-Prototyping-Pipeline aus UX-Perspektive

Was folgte, waren rund drei Wochen – abends nach der Arbeit, an Wochenenden. Zehn Tage davon intensiv in Code und Konzept. Von v0.1.0 bis v0.16.0, durch vier Entwicklungsphasen: Grundstruktur, Prozessoptimierung, Token-Optimierung, Restrukturierung. Das Ergebnis: red-create-prototyp-project, ein Open-Source-Framework für Claude Code, das eine vollständige KI-Prototyping-Pipeline aus UX-Perspektive abbildet.

Die Grundphilosophie ist einfach: Jeder Schritt ist ein eigener Command. Jeder Command liest den Output des vorherigen, ergänzt die gemeinsamen Artefakte – und wartet auf eine explizite Freigabe, bevor es weitergeht. Kein autonomes Durchlaufen. Kein Wissen, das in der nächsten Session verloren geht.

KI-Prototyping in der Praxis: So sieht der Workflow aus

Der Start: /red:proto-sparring. Du schreibst deine Idee in natürlicher Sprache in den Chat. Der Command ist ein kritischer Gesprächspartner – er stellt zwei, drei gezielte Rückfragen und zwingt dich, deine Idee zu schärfen. Das Ergebnis ist eine prd.md, ein strukturiertes Product Requirements Document, das als verbindliche Grundlage für alle weiteren Schritte dient.

Danach – optional, aber an jeder Stelle im Workflow nachholbar – /red:proto-research. Das Command generiert auf Basis vorhandener Unterlagen oder der PRD einen Katalog mit Forschungsfragen, der als Leitfaden für Nutzerinterviews dient. Wer die Interviews danach geführt hat, legt die Ergebnisse im Research-Ordner ab und führt das Command erneut aus. Wer keine Interviews führen kann, hat auch die Möglichkeit, die Fragen direkt im Chat zu beantworten – mit dem klaren Bewusstsein, dass die entstehenden Personas dann eher Arbeitshypothesen sind.

Diese Erkenntnisse fließen direkt in /red:proto-requirements. Das Command analysiert alle vorhandenen Dokumente und schlägt vor, welche Features gebraucht werden und wie sie geschnitten werden sollten. Die Feature-Spezifikationen werden nach GitHub versioniert – das ist der Moment, in dem das KI-Prototyping aufhört, eine Einwegrakete zu sein.

Was mir als UX Designer besonders wichtig war: UX-Entscheidungen bekommen ihren eigenen Schritt. /red:proto-ux erweitert jede Feature-Spezifikation explizit um Designentscheidungen – entlang eines integrierten Design Systems mit Tokens, Komponenten und Patterns – und definiert dabei auch den Nutzerfluss zwischen Screens. Diese Entscheidungen sind danach dokumentiert und versioniert.

Die Umsetzungsphase läuft als kontrollierter Loop: /red:proto-dev implementiert ein Feature. Bei Bedarf starten dabei zwei Subagenten parallel – ein Frontend-Developer und ein Backend-Developer. Sind sie fertig, folgt /red:proto-qa. Hier laufen zwei Perspektiven gleichzeitig: ein QA Engineer prüft technische Qualität, ein UX-Reviewer prüft Nutzerfluss, Interaktionsmuster, Accessibility und visuelle Konsistenz. Jeder Fehler landet als priorisierter Bug-Report. Du entscheidest, ab welcher Schwelle Bugs behoben werden.

Das Entscheidende: Du kannst nach jedem Schritt aussteigen. Kein Zwang zur vollständigen Pipeline. Der KI-Workflow passt sich dem Projektziel an – nicht umgekehrt.

Was ich beim Entwickeln des KI-Frameworks gelernt habe

Um jeden Command zu schreiben, musste ich erst selbst wissen, was ich eigentlich tue, wenn ich einen Prototypen entwickle. In welcher Reihenfolge? Welche Entscheidungen gehören zu UX, welche zu Tech, welche zum Business? Das Designen des Frameworks hat meinen eigenen Workflow sichtbar gemacht – und damit erst wirklich teilbar.

Das ist, glaube ich, der eigentliche Mehrwert für UX Designer: nicht dass KI die Arbeit übernimmt, sondern dass die Auseinandersetzung mit KI zwingt, den eigenen Workflow zu explizieren. Und was explizit ist, kann geteilt, kritisiert und verbessert werden.

Ein wichtiger Hinweis: Das Framework ersetzt echte Nutzerforschung nicht. Es unterstützt sie. Wer Interviewdaten mitbringt, bekommt fundiertere Feature-Spezifikationen. Wer wenig Daten hat, kann trotzdem starten – dann eben mit expliziten Hypothesen statt gesicherten Erkenntnissen. Der Prototyp wird zum Testinstrument, das genau diese Hypothesen überprüft. Beides ist legitim. Der Unterschied sollte bewusst sein.

KI-Prototyping ohne strukturierten Workflow ist eine Einwegrakete. Mächtig. Einmalig. Nicht reproduzierbar.

Grenzen und nächste Schritte für KI-Prototyping

Das Framework ist ein erster Stand – und das bewusst. Zwei Punkte, die ich noch weiterentwickeln möchte:

Aktuell kann ich dem Framework grob vorgeben, welche Features der Prototyp haben soll. Wie eine neue Interaktion im Detail funktionieren soll – also ein konkretes Nutzungskonzept mit spezifischen Bedienmustern – lässt sich bisher noch nicht präzise steuern. Für Fälle, in denen das Nutzungskonzept selbst der Kern des zu testenden Prototypen ist, braucht es noch gezieltere Eingriffsmöglichkeiten.

Außerdem wurde noch nicht systematisch erprobt, wie das Framework mit Low- und High-Fidelity-Screens umgeht. Das ist ein Bereich, den ich gezielt testen und dokumentieren möchte.

Beides sind keine Blocker – aber ehrliche Grenzen des aktuellen Stands. Feedback dazu ist ausdrücklich erwünscht.

red-proto ausprobieren: KI-Prototyping in wenigen Minuten

Das Framework ist Open Source und in wenigen Minuten einsatzbereit:

npx red-proto@latest

Danach: Projektordner erstellen, claude starten, mit /red:proto-sparring beginnen. Es läuft in Claude Code, ist technologieoffen – kein fester Stack, die Technologieempfehlung basiert auf den Anforderungen des jeweiligen Projekts.

Ende April stelle ich es beim UX Stammtisch Franken vor. Ich freue mich auf alle, die es vorher ausprobieren und mir sagen, was fehlt, was nicht passt, oder was überraschend gut funktioniert.

KI-Prototyping für UX Designer ist heute absolut machbar. Es braucht nur einen Rahmen – und den kannst du jetzt haben.

Dieser Artikel wurde mit Unterstützung von Claude (Anthropic) verfasst. Grundlage waren meine eigenen Erfahrungen mit der Entwicklung des Frameworks sowie drei Wochen Abend- und Wochenendarbeit.