← Blog

Zwölf Wochen UX for AI: was learning by doing mir gebracht hat

TL;DR: Zwölf Wochen UX-for-AI-Training, ein selbstgebautes KI-Produkt und eine Lektion, die am Ende größer war als jede einzelne Methode: Ich will mich von der KI nicht abhängen lassen, doch das passiert bei der neuen Geschwindigkeit super schnell. Ich habe als Ein-Frau-Team, mit KI als Unterstützung, ein KI-getriebenes Produkt konzipiert, gebaut und getestet. Hier kommt der Rückblick auf den Ansatz und die Methoden. Was mich das Bauen über Verantwortung in regulierten Health-Produkten gelehrt hat, folgt in einem weiteren Post.

Der Ansatz

Gearbeitet habe ich entland des Trainings mit dem Snowball Sprint Framework von Greg Nudelman: Problem Framing, Prototyping, Testing und Vibe Coding, end-to-end bis zum eigenen RAG-Prototyp.

UX for AI — Buch von Greg Nudelman

Vieles war altbekannt, aber bekommt durch die direkte Kollaboration mit einer AI einen neuen Dreh. Storyboarding und Wireframing kannte ich längst, aber als Kontext für Claude waren meine Scribbles nochmal anders nützlich. Die echte Überraschung war der Digital Twin: Dieses Mapping von Input, Schema und Output hätte in früheren Projekten ganze Teams sehr viel schneller auf einen gemeinsamen Stand gebracht. Die Value Matrix dagegen fand ich wackelig, definite Zahlen auf einem ganzen Berg von Annahmen versprechen eine falsche Form von Sicherheit.

Und das Prototyping ist am Anfang absurd schnell. Fast zu schnell. Claude baut schon den ersten Prototyp, während ich eigentlich noch dabei bin herauszufinden, welches Problem ich überhaupt lösen will. Der schwierige Teil kommt danach: auf Kurs zu bleiben.

Eine spezifische Variante, nicht das Evangelium

Gregs Mischung aus Hands-on-KI, Scribble-Prototyping und schnellem Testen mochte ich wirklich. Trotzdem ist es eine sehr spezifische Lean-Variante, und das sollte man dazusagen. Seine zentrale These lautet: Die UX-Zunft hängt zu sehr an Figma, das ohnehin gerade irrelevant wird. Den Punkt verstehe ich. Nur deckte er sich nicht mit dem, was ich im Kurs gesehen habe. Die Teilnehmenden waren durch die Bank breit aufgestellt, alles andere als pixelverliebt.

Das Produkt: ein Responsible Digital Health Checker

Wer das Tool nutzt, gibt die Beschreibung eines KI-Health-Features ein und bekommt eine Einschätzung zu den rechtlichen Anforderungen zurück, auf Basis von EU AI Act, MDR, DiGA-Leitlinien und weiteren Normen. Dazu sucht ein kleiner Websearch-Agent nach aktuellen Debatten und hängt sie als „Diskussionen, die man verfolgen sollte” an.

Output des Responsible Digital Health Checkers: Feature Summary, Regulatory Signals (EU AI Act, MDR, DiGA) und DSGVO-Pflichten

Und so sieht der Checker als schematischer Digital Twin aus:

Digital Twin: Input, LLM-Schematic, LLM-Output, Agent-Layer und Overall Output des Responsible Digital Health Checkers

Doch ich habe nicht nur zu meinem eigenen Workflow mit AI etwas gelernt. Auch in Bezug auf AI bei regulierten Produkten habe ich etwas mitgenommen: Hier ist es besonders wichtig, dass der Mensch in Führung bleibt, denn die finale Entscheidung kann (oder sollte) AI nicht treffen. Das macht Transparenz zum wichtigsten UX-Prinzip. Dazu mehr in einem neuen Post.

Alle Artikel dieser Serie

Die einzelnen Schritte habe ich während des Trainings dokumentiert — auf englisch und in chronologischer Reihenfolge:

  1. From Problem Finding to Prototyping too fast
  2. Evaluating some ideas
  3. Creating a Storyboard and Digital Twin
  4. Creating the Value Statement
  5. Grounding the idea on RAG
  6. From Wireframe Scribble to Prompt Template
  7. Vibe Coding: Give it a try by creating a Kanban board
  8. Vibe Coding an LLM-based demo project: Life Clock
  9. Vibe Coding my Responsible Digital Health Checker as a local prototype
  10. RAG Refactoring: Better Results Start With Better Context
  11. Adding the agentic layer: a web-lookup agent for live regulatory context