Meine Coworkerin, Produktmanagerin für einen Berliner Online-Modehändler, wollte in AI eintauchen. "Reden ist Silber, Bauen ist Gold" haben wir gesagt und kurzerhand mit Claude ihre erste eigene AI-Anwendung gebaut - ein personalisierter Alpen-Tour-Finder mit Anbindung an Bahn, Komoot und Wetterdaten. Nach 90 Minuten hatten wir einen mega coolen Prototypen gebaut, der genau ihr Problem löst.
Diese Art zu arbeiten hat einen Namen: Protostorming. Brainstorming meets Prototyping. Das Ping-Pong zwischen Produkt, UX und Nutzern, das sonst Sprints frisst, passiert jetzt in einem Aufwasch.
Die Idee ist 25 Jahre alt, aber jetzt ist das Material schnell genug
Der Begriff Protostorming kommt aus einer Welt (um das Jahr 2000 rum), als agil noch der hippe Gegenentwurf zu Spezifikationsdokumenten war, wo auf hunderte Seiten haarklein alles geplant wurde, was später dann doch wieder verworfen wurde. Geprägt hat ihn Rich Gildersleeve, die Idee: kleine Teams, die brainstormen, indem sie was bauen - damals mit Pappe, Klebeband und Bauteilen. Ist ein alter Hut, in den letzten 20 Jahren sollte jedes Team gelernt haben, genau so zu arbeiten. Als bessere Tools wie Figma oder Balsamiq die Papier-Mockups ablösten wurden aus Wochen Tage - nice. Aber jetzt hat die Evolution einen gewaltigen Sprung gemacht und die Design-Tools von vor zwei Jahren sehen auf einmal ganz schön alt aus. Denn mit AI liegt die Zeitspanne zwischen Denken (bzw. Sprechen) und einem unglaublich funktionalen Prototypen jetzt bei Minuten. Colin Matthews führt das in Lennys Newsletter mit Demos vor, und Uber beschreibt einen PM, der sechs verschiedene Konzepte in 20 Minuten exploriert hat.
„Zwei Stunden Prototyping haben vier Wochen Diskussion aufgelöst.“
Uber Engineering Blog, April 2026
Schneller Lernen geht nicht
Der klassische Weg von der Nutzerbeobachtung zum getesteten Prototyp ist in Organisationen erfahrungsgemäß oftmals nicht der Flotteste und manchmal eine furchtbare Flüsterpost-Maschinerie: POs oder Business Analysten schreiben auf, was sie von Nutzern verstanden zu haben glauben. Die UXler bauen, was sie aus den Beschreibungen rausgelesen haben. Ein paar Wochen später sehen die Nutzer einen Prototypen, den sie nicht gut finden - und so geht die Zeit dahin. Jetzt stellt euch mal vor, man könnte diese Übergaben, diese langen Zeitspannen des Wartens, einfach komplett abschaffen...
„Es ist sehr schwer, Produkte mit Fokusgruppen zu entwerfen. Oft wissen die Leute nicht, was sie wollen, bis man es ihnen zeigt.“
Steve Jobs, BusinessWeek, Mai 1998
Wenn das die Lösung ist, hätte ich gerne mein Problem zurück
Ein Freund hat sich für sein letztes Vorstellungsgespräch vor einem großen Gremium letzte Woche mit Claude seine Folien erstellen lassen. Das Ergebnis war ganz und gar grauenhaft, kein Flow, keine Struktur, nichtssagende Allgemeinplätze, Billo-Design. Am Sonntag vormittag haben wir uns zu zweit hingesetzt. Ich habe ihn gefragt, was er sagen will, was ihm wichtig ist, was den Leuten aus dem Gremium wichtig ist, ein wenig nachgebohrt hier und dort. Und diesen ganzen Kontext haben wir Claude gegeben. Zwei Stunden und 8 oder 10 Iterationen später hatten wir einen sauberen Spannungsbogen, klare Storyline, Firmen-Branding. Gleiches Modell, gleicher Mensch, komplett anderes Ergebnis.
Die Leute wissen erst, was sie nicht haben wollen, wenn sie sehen, was sie bekommen. Das "noch total daneben" der ersten Touren-Finder-Version war also kein Scheitern, sondern der Auftakt zu einem inkrementellen Discovery-Prozess. "Was klappt, was nicht?" im 10-Minuten-Takt. Das ist die schnellstmögliche Lernschleife. Nicht mehr Monate oder Jahre zum User Feedback (klassische Softwareentwicklung), nicht mehr Wochen (agile Produktentwicklung), sondern Minuten. Mit Nutzern Lernen hat noch nie mehr Spaß gemacht, da kullern mir fast die Freudentränchen aus den Augen.
So läuft eine Protostorming-Session
Das Setup ist unspektakulär. Man braucht kein Base44 und keine Spezialplattform - Claude oder Codex reichen völlig, plus ein Mikrofon. Der Ablauf:
PO/PM und Nutzer setzen sich vor einen Laptop, starten z.B. die Claude Desktop App - und schalten das Mikro ein.
0. Ein initialer Prompt, damit Claude weiß, was auf ihn zukommt und welche Rolle er spielen soll:
Wir machen eine Protostorming-Session: ich bin Product Owner, neben mir sitzt ein Nutzer mit seinem Problem, und wir sprechen über Mikrofon - du bekommst also Gesprächsfetzen mit. Erklär uns zum Start in drei Sätzen, wie die Session ablaufen wird, und halte dich danach zurück: wir führen das Gespräch, du hilfst, wenn wir dich fragen. Sobald wir "bau mal" sagen, erstellst du die kleinstmögliche Version als eine einzige HTML-Datei, die wir sofort im Browser öffnen können. Unser Feedback kommt mündlich und in kleinen Schritten; wir sagen dir dazu, wo im Prototyp wir gerade sind. Schreib nebenbei User Stories mit Akzeptanzkriterien mit - die gibst du uns am Ende der Session aus.
- Erst den Problemraum abklappern, nicht sofort anfangen zu bauen. Die ersten Minuten sind ein ganz natürliches Gespräch: was willst du erreichen, wie tust du das heute, wo klemmt es, was hast du schon probiert. Am besten ohne Nuscheln.
- Ab in den Lösungsraum. Wie könnte eine Lösung aussehen, was wäre eine erste kleine Version, um zu sehen, ob's in die richtige Richtung geht. Die AI bekommt also kein Feature-Wunschkonzert, sondern verdichteten Kontext.
- Bauen lassen, weiterreden. Während die AI baut - das dauert schon ein paar Minuten - trinken wir Kaffee und/oder reden weiter. Die wichtigsten Erkenntnisse aus diesem Weiterreden fließen in den nächsten Audio-Prompt.
- Challengen, nicht bewundern. Wenn der erste Wurf da ist: Mikro an und der Nutzer klickt, kommentiert, verwirft. Jedes "nee, so nicht" ist ein Ergebnis. Hier wichtig: ihr müsst der AI schon sagen, wo ihr gerade seid, z.B. "also beim Login-Screen, da fehlt mir völlig ...".
In zwei Stunden schafft man zehn Iterationen, von "noch total daneben" bis "beeindruckend gut". Der Touren-Finder aus dem Einstieg ist genau so entstanden. Und so mache ich das immer: als ich einer großen Apotheke geholfen habe, Informationen über ihre 1500 Medikamente sauber aufzubereiten (das hätte den Praktikanten über eine Woche gekostet); wenn wir mit der Steuerberaterin herausfinden, wie sie bei ihrer Mandantenkorrespondenz wöchentlich einige Stunden sparen; aber auch wenn ich mit meinen Kids eine Gartenapp baue.
Das Nebenprodukt: User Stories mit Akzeptanzkriterien .. bis hin zum Code
Wer seine AI zu Beginn der Session entsprechend instruiert, bekommt am Ende nicht nur den Prototyp, sondern User Stories mit Akzeptanzkriterien, direkt aus dem, was der Nutzer gesagt, gezeigt, verbessert hat. Dass AI aus Interview-Material brauchbare User Stories erzeugen kann, ist inzwischen sogar akademisch untersucht. Der Unterschied zu herkömmlich geschriebenen Stories: diese hier sind gegen einen Prototyp validiert, den der Nutzer selbst mitgeformt hat. Sie beschreiben ein Problem, das nachweislich existiert, und eine Lösung, die dem Nutzer schon beim Entstehen gefallen hat. Wenn's also darum geht, aus dem Prototypen ein Produkt zu bauen, das production ready ist, dann sind diese User Stories für eure Entwickler (oder deren AIs) so gut, dass man schon ernsthaft darüber nachdenken könnte, ob man nicht den Rest auch gleich von AI entwickeln lassen will. Aber da scheiden sich momentan (Stand: Juli 2026) noch die Geister. Mein AI-Workflow jedenfalls generiert aus den Akzeptanzkriterien automatisierte Akzeptanztests & baut dann so lange, bis die Tests grün sind. Und Hand aufs Herz: die Qualität der Software ist besser als die meisten Projekte, in denen ich als Entwickler drin war.
Wie sehr man sich mit Interviewtechniken auskennen sollte
Die Interview-Klassiker gelten beim Protostorming unverändert. Rob Fitzpatrick bringt die Arbeitsteilung im "Mom Test" auf den Punkt:
„Sie besitzen das Problem, du besitzt die Lösung.“
Rob Fitzpatrick, The Mom Test
Was er damit meint: lasst euch vom Nutzer nicht sofort in den Lösungsraum drängeln, sondern versucht die ersten Minuten, auch durch wiederholtes Nachbohren, erstmal zu verstehen, was im Problemraum los ist. Das ist das mit Abstand Allerwichtigste für eine ordentliche Discovery - und damit für ein ordentliches Produkt.
Übung macht den Meister, und ich bin selbst auch eher ein mittelmäßiger Interviewer. Deswegen die naheliegende Frage: muss ich das alles selbst können, oder kann mich die AI durchs Interview führen? Ein Stück weit kann sie es. Es gibt inzwischen eine ganze Tool-Kategorie für AI-moderierte Interviews, und auch im Protostorming kann man die AI anweisen, Nachfragen vorzuschlagen, bevor sie baut. Meine Erfahrung: hilft, aber ihr müsst schon selbst ein Gespür für euer Gegenüber aufbauen, vor allem weil AI nur den Textkanal mitbekommt, aber alle anderen Kanäle wie Körpersprache, Mimik, Sprachduktus komplett ignoriert. Selbst wer AI verwendet, muss verstehen, was er da tun sollte und was nicht - genau dieses Fundament bauen wir übrigens in der AI-Produkt-Lernreise auf.
UX wird nicht ersetzt. Sie wird gezielter eingesetzt.
An dieser Stelle kommt verlässlich der Einwand: heißt das, UXler dürfen jetzt wieder nur den Scherbenhaufen aufkehren, statt vorgelagert wichtige Entscheidungen mitzuprägen? Nein: was PO, AI und Nutzer im Protostorming klären, ist der Problemraum und die grobe Richtung - Arbeit, für die UX-Kapazität in den meisten Organisationen eher selten reicht. Die Interaktions- und Gestaltungsentscheidungen, die das Produkt am Ende ausmachen, kommen danach, mit schnell validiertem Material als Grundlage statt Vermutungen. Die Nielsen Norman Group hat AI-Prototyping-Tools in realen Design-Kontexten untersucht und kommt zu einem nüchternen Schluss:
„AI-Prototyping-Tools können Layouts entwerfen, Komponenten zusammensetzen und vertraute Muster nachbilden - aber es braucht weiterhin menschliches Urteilsvermögen, um Zielkonflikte abzuwägen und Bedeutung zu schaffen.“
Nielsen Norman Group, Oktober 2025
Die zweite UX-Aufgabe liegt vor der Session: die besten Teams machen ihr Design-System LLM-lesbar. Figma streamt über seinen MCP-Server Komponenten, Tokens und Layout-Regeln direkt in den Kontext von AI-Werkzeugen, Vercel beschreibt, wie man Design-Systeme so aufbereitet, dass AI-Prototypen "on-brand" herauskommen. Der Effekt für Protostorming: schon der Wegwerf-Prototyp hat halbwegs den Look&Feel des fertigen Produkts, weil die AI im Design-System der Firma baut statt im Claude Code Design von der Stange. UX gestaltet damit die Spielregeln, nach denen alle anderen prototypen.
Und jetzt du
Nimm den Start-Prompt aus der Box oben, schnapp Dir einen Menschen mit einem Problem, ein gutes LLM und zwei Stunden. Mikro an und los gehts. Die ersten Sessions können holprig werden - gutes Fragen stellen ist nicht easy. Aber hey - better done than perfect. Probier's einfach aus. Und wenn du das Fundament systematisch legen willst, vom Problemraum-Interview bis zum eigenen AI-Workflow: genau das üben wir in der AI-Produkt-Lernreise und im AI-Powered-Product-Owner-Training.
Quellen
- Rocky Peak Leadership Center: ProtoStorming - Begriffsprägung durch Rich Gildersleeve (DJO Global), frühe 2000er.
- Colin Matthews: A guide to AI prototyping for product managers, Lenny's Newsletter, Januar 2025.
- Uber Engineering: AI Prototyping at Uber, April 2026. Original: "Two Hours of Prototyping Unblocked Four Weeks of Discussion".
- Barry Boehm: Requirements that Handle IKIWISI, COTS, and Rapid Change, IEEE Computer, Juli 2000.
- Steve Jobs, BusinessWeek-Interview, 25. Mai 1998. Original: "It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them."
- Rob Fitzpatrick: The Mom Test, 2013. Original: "They own the problem, you own the solution."
- Nielsen Norman Group: Good from Afar, But Far from Good: AI Prototyping in Real Design Contexts, Oktober 2025. Original: "AI prototyping tools can draft layouts, assemble components, and echo familiar patterns, but it still takes human judgment to balance tradeoffs and create meaning."
- Figma: Design Systems And AI: Why MCP Servers Are The Unlock, August 2025.
- Vercel: AI-powered prototyping with design systems, August 2025.
- Springer: AI-Generated User Stories Supporting Human-Centred Development.
