User Journey Testing mit Claude

Wenn Testing plötzlich qualitativ wird

Lass mich eine Idee skizzieren.

Letzte Woche hat Claude einen Bug in unserer Checkout-Seite gefunden, den weder unser QA-Team noch unsere automatisierten Tests entdeckt hatten. Nicht weil der Code fehlerhaft war, sondern weil die UX für eine bestimmte Nutzergruppe verwirrend war.

Claude testete unsere Anwendung aus der Perspektive von „Martha, 67, technikaffin aber ungeduldig“ – und stolperte genau dort, wo auch echte User stolpern würden. Der Unterschied: Wir wussten es diesmal vor dem Release.

Das war kein Zufall. Das war User Journey Testing mit KI-generierten, datenbasierten Personas.

Das Problem mit traditionellem Testing

Dein automatisierter Test sagt: „Checkout funktioniert“
Dein User denkt: „Wo zur Hölle ist jetzt der Weiter-Button?“

Genau hier liegt der fundamentale Bruch. Klassisches Testing prüft, ob etwas funktioniert – aber nicht, wie es sich für echte Menschen anfühlt. Selenium klickt auf Buttons, füllt Formulare aus und prüft Assertions. Aber es sagt dir nicht, ob beispielsweise die Navigation für ältere User verständlich ist oder ob Fachbegriffe für Nicht-Experten verwirrend sind.

UX-Tests und User Research könnten diese Lücke schließen. In der Praxis passieren sie jedoch oft spät, sind teuer und organisatorisch aufwendig. Häufig finden sie erst statt, wenn die Software bereits live ist und sich Probleme bereits in Support-Tickets materialisieren. Das Ergebnis ist bekannt: Optimierungen kommen zu spät und Tests bleiben am tatsächlichen Nutzungskontext vorbei.

Die zentrale Frage

Die eigentliche Frage lautet daher nicht, wie wir noch mehr technische Tests schreiben, sondern ob sich Software auch aus der Perspektive realer Nutzer systematisch testen lässt. Was wäre, wenn ein LLM eine Anwendung nicht nur korrekt bedienen kann, sondern sie bewusst aus der Rolle eines bestimmten Nutzertyps erlebt und bewertet?

Genau das ermöglicht Claude in Kombination mit dem Skill Superpowers und Chrome DevTools MCP.

In diesem Artikel zeige ich dir eine Methode, die echte Daten (Umfragen, Analytics) in testbare Personas verwandelt, daraus User Journeys generiert, diese automatisiert durchspielt und qualitatives Feedback zurückgibt, das direkt in die Entwicklung fließt.

Wie ich zu dieser Methode kam

Klassisches Problem: Wir hatten Analytics-Daten, Umfrageergebnisse und Support-Tickets – aber diese Erkenntnisse landeten in Präsentationen und verstaubten dann in Confluence. Testing? Das war ein separates Thema, mit Selenium-Scripts und technischen Testfällen, die prüften, ob Buttons funktionieren.

Die Nutzer-Insights und das Testing lebten in getrennten Welten.

Bis ich mir dachte: Was wäre, wenn die Nutzer-Insights selbst zu Tests werden?

Was wäre, wenn „Sabine, 52, Grundschullehrerin, wird von technischen Fachbegriffen überfordert“ nicht nur eine Persona in einer Präsentation ist – sondern ein lebendiger Testfall, der automatisiert meine Software durchläuft und mir zeigt, wo Sabine stolpern würde?

Der Workflow: Vom Umfrageergebnis zum automatisierten Test

So funktioniert die Methode in vier Schritten:

1. Persona-Generierung aus echten Daten

Ich füttere Claude mit allem, was ich über meine Nutzer weiß:

• Analytics: Welche User-Typen haben wir? Welche Geräte nutzen sie?
• Umfrageergebnisse: Was frustriert sie? Was schätzen sie?
• Support-Tickets: Wo scheitern sie? Welche Fragen tauchen immer wieder auf?
• Demografie-Daten: Alter, technische Affinität, Nutzungskontext

Mit Claude und den Superpowers-Skills erstelle ich daraus konkrete Personas – keine Marketing-Fiktion à la „Technik-Tommy, 25, liebt Gadgets“, sondern datenbasierte Profile mit realistischen Bedürfnissen, Frustrationen und technischen Fähigkeiten.

Das Wichtigste: Ich speichere sie als Markdown, damit Claude später direkt damit arbeiten kann.

2. User Journeys ableiten

Aus den Personas entstehen konkrete Journeys. „Sabine, 52, möchte ein Geschenk für ihren Enkel kaufen“ wird zu einer Schritt-für-Schritt-Reise durch meinen Shop:

1. Einstieg über Google-Suche
2. Orientierung in der Produktkategorie
3. Produktvergleich und Bewertungen lesen
4. Entscheidung und in den Warenkorb legen
5. Checkout mit Zahlungsmethode und Lieferadresse

Auch diese Journeys dokumentiere ich als Markdown – strukturiert, lesbar und versionierbar.

3. Automatisiertes Testing mit Chrome DevTools MCP

Jetzt kommt der Clou: Claude bekommt drei Dinge, nämlich die Persona, die User Journey und Zugriff auf die Chrome DevTools via MCP.

Er spielt die Journey durch – wie ein echter User. Nur dass er dabei die WCAG-Konformität prüft, Auffälligkeiten notiert und die Reise bewertet.

Das Feedback ist nicht „Test failed“ – sondern: „Als Sabine wäre ich an dieser Stelle unsicher, weil der Begriff ‚Wassersäule‘ für mich nicht verständlich ist.“

4. Der geschlossene Kreislauf

Die Erkenntnisse fließen direkt ins Backlog. Wir fixen. Und dann – und das ist elegant – lassen wir Claude die gleiche Journey nochmal durchspielen. Die Persona und Journey existieren ja bereits als Markdown. Sofortiges Feedback: Hat der Fix funktioniert?

Die Personas und Journeys bleiben „lebendige Testfälle“, die bei jedem Feature mitlaufen.

Konkretes Beispiel: Sabine kauft ein Familienzelt

Lass mich dir zeigen, wie das konkret aussieht. Für einen fiktiven Outdoor-Shop „GreenTrail“ habe ich mehrere Personas erstellt. Eine davon stelle ich dir hier vor:

1. Die Persona: Sabine Berger

# Persona: Sabine Berger

## Demografie
- Alter: 52
- Beruf: Grundschullehrerin
- Wohnort: Freiburg
- Technik-Affinität: Mittel (nutzt Smartphone täglich, aber kein Digital Native)

## Bedürfnisse & Ziele
- Sucht Campingausrüstung für Wochenendtrips mit ihrem Partner
- Legt Wert auf Nachhaltigkeit und Qualität
- Hat Zeit zum Stöbern, aber wenig Geduld bei komplizierten Prozessen

## Frustrationen
- Überfordert von zu vielen technischen Details
- Verunsichert bei unklaren Produktbeschreibungen
- Bricht ab, wenn Checkout zu kompliziert wird

## Technische Einschränkungen
- Nutzt Lesebrille (Kontrast und Schriftgröße wichtig)
- Bevorzugt klare Navigation über clevere Interaktionen

2. Die User Journey

Aus dieser Persona leite ich eine konkrete Journey ab:

# User Journey: Sabine kauft ein Familienzelt

## Kontext
Sabine plant einen Camping-Wochenendtrip im Schwarzwald. Sie braucht ein
wetterfestes Zelt für 2-3 Personen.

## Schritte
1. **Einstieg**: Öffnet GreenTrail-Startseite, sucht nach "Familienzelt"
2. **Orientierung**: Schaut sich Filtermöglichkeiten an, ist unsicher
   bei "Wassersäule" und "Gestänge-Typ"
3. **Produktauswahl**: Vergleicht 2-3 Zelte, liest Kundenbewertungen
4. **Entscheidung**: Legt ein Zelt in den Warenkorb
5. **Checkout**: Gibt Lieferadresse ein, wählt Zahlungsmethode

## Erwartete Stolpersteine
- Fachbegriffe in der Produktbeschreibung
- Zu kleine Schrift bei Versandinformationen
- Unklarer Checkout-Prozess

3. Der Test-Prompt für Claude

Wie genau instruiere ich Claude? Hier der Prompt, den ich verwende:

Du bist Sabine Berger (siehe Persona in personas/sabine-berger.md).
Nutze Chrome DevTools MCP, um folgende User Journey durchzuführen:
- Lies die Journey in journeys/sabine-familienzelt.md
- Führe jeden Schritt aus der Perspektive von Sabine aus
- Verhalte dich authentisch: Wenn Sabine bei Fachbegriffen unsicher
  wäre, zeige das in deinem Vorgehen

**Während des Tests:**
- Notiere UX-Auffälligkeiten (unklare Navigation, verwirrende Texte)
- Prüfe WCAG-Konformität (Kontrast, Schriftgröße, Alt-Texte)
- Bewerte jeden Schritt: Würde Sabine hier weitermachen oder abbrechen?

**Am Ende:**
Erstelle einen Test-Report mit:
1. Durchgeführte Schritte (was hast du getan?)
2. UX-Bewertung (wo würde Sabine stolpern?)
3. WCAG-Findings (konkrete Verstöße mit Positionsangabe)
4. Positive Aspekte (was funktioniert gut?)
5. Prioritäten (was sollte zuerst gefixed werden?)

Das Test-Ergebnis

Dann lasse ich Claude diese Journey durchspielen. Mit Chrome DevTools MCP steuert er den Browser, klickt, scrollt, füllt Formulare aus – wie Sabine es tun würde.

Was kommt zurück? Nicht nur „Test passed“ oder „Test failed“, sondern qualitatives Feedback:

• „Der Filter-Bereich verwendet Fachbegriffe wie ‚Wassersäule‘ und ‚Gestänge-Typ‘ ohne Erklärung – als Sabine wäre ich hier unsicher und würde wahrscheinlich einfach blind ein mittelteueres Produkt wählen.“
• „WCAG-Warnung: Der Kontrast der Preis-Anzeige liegt bei 3.2:1, sollte aber mindestens 4.5:1 sein. Mit Sabines Lesebrille könnte das problematisch werden.“
• „Im Checkout fehlt eine Fortschrittsanzeige – Sabine würde nicht wissen, wie viele Schritte noch kommen. Das erhöht die Wahrscheinlichkeit eines Abbruchs.“
• „Positiv: Der ‚Hilfe‘-Button ist gut sichtbar platziert und verwendet ein erkennbares Icon. Das gibt Sabine Sicherheit.“

Das sind Erkenntnisse, die ich direkt ins Backlog übernehmen kann. Nicht abstrakt, sondern konkret und priorisierbar.

Der geschlossene Kreislauf: Wie Erkenntnisse zurückfließen

Das Spannende an dieser Methode ist nicht nur das Testing selbst – sondern was danach passiert. Die Erkenntnisse verschwinden nicht in einem Test-Report, der in irgendeinem Confluence-Space verstaubt.

1. Test-Findings → Backlog

Claudes Feedback landet direkt als Issues oder Stories im Backlog:

• „WCAG: Kontrast Preisanzeige auf 4.5:1 erhöhen“ (Priority: High)
• „UX: Filter-Begriffe ‚Wassersäule‘ und ‚Gestänge-Typ‘ mit Tooltips erklären“ (Priority: Medium)
• „WCAG: Alt-Text bei Produktbildern fehlt“ (Priority: High)
• „UX: Fortschrittsanzeige im Checkout ergänzen“ (Priority: Medium)

2. Implementierung & Fix

Das Team arbeitet die Issues ab – priorisiert nach Impact und Schweregrad. Die Tooltip-Erklärungen werden ergänzt, der Kontrast wird angepasst, die Fortschrittsanzeige implementiert.

3. Retest mit der gleichen Persona

Hier wird’s elegant: Die Persona und Journey existieren bereits als Markdown. Ich lasse Claude einfach die gleiche Journey nochmal durchspielen – und sehe sofort, ob die Fixes funktionieren.

„Sabine kauft ein Familienzelt – Take 2“

4. Neue Erkenntnisse entstehen

Oft entstehen beim erneuten Testen neue Insights:

• „Der Kontrast ist jetzt besser, aber die Schrift könnte für Sabine noch etwas größer sein“
• „Die Erklärung der Filter-Begriffe hilft – aber der Tooltip ist auf Mobile schwer zu treffen“
• „Die Fortschrittsanzeige ist gut, aber Schritt 3 (‚Zahlungsdaten‘) klingt bedrohlicher als nötig – ‚Zahlung auswählen‘ wäre freundlicher“

Diese neuen Erkenntnisse fließen wieder ins Backlog. Der Kreislauf schließt sich.

Die größten Learnings

Nach drei Monaten mit dieser Methode habe ich vier zentrale Erkenntnisse gewonnen.

Das Wertvollste ist nicht nur „Fehler gefunden“, sondern: „Ich sehe, wie jemand anderes meine Anwendung bedient.“ Claude zeigt mir Nutzungsmuster, die ich nicht erwartet hätte. Er hinterfragt Dinge, die mir selbstverständlich erscheinen. Er stolpert über Stellen, die ich für intuitiv hielt. Das inspiriert nicht nur Fixes – sondern neue Features. „Warum zeigen wir nicht direkt bei jedem Zelt, für wie viele Personen es geeignet ist?“ – das kam aus einer Beobachtung von Claude während eines Tests. Das LLM wird zum Design-Sparringspartner.

Ein weiterer Effekt: Statt einmaliger User Research sind Personas jetzt „lebende Testfälle“. Bei jedem neuen Feature stelle ich mir die Frage: „Wie würde Sabine das bedienen?“ Die Personas sind nicht mehr abstrakte Marketing-Dokumente, die nach der Erstellung verstauben, sondern Teil des täglichen Entwicklungsprozesses.

Was mich besonders überrascht hat: Accessibility ist kein nachträglicher Audit mehr, der kurz vor dem Release Panik auslöst. Claude prüft bei jedem Test automatisch WCAG-Konformität – Kontraste, Schriftgrößen, Alt-Texte, Tastaturnavigation. Barrierefreiheit wird Teil der Definition of Done, nicht mehr ein nachträglicher Checklistenpunkt.

Und schließlich: Ich kann Features bereits während der Entwicklung testen – nicht erst nach dem Deployment, wenn Kunden sich beschweren. Das Feedback kommt früh genug, um noch etwas zu ändern, ohne den Release-Zeitplan zu sprengen. Der Unterschied zwischen „wir müssen das jetzt so lassen“ und „wir können das noch fixen“ ist riesig.

Grenzen der Methode

Bevor du jetzt euphorisch loslegst: Diese Methode ist kein Ersatz für alles. Lass mich ehrlich sein, wo die Grenzen liegen.

Was diese Methode NICHT ersetzt

Claude simuliert Personas basierend auf Daten – aber echte Menschen überraschen dich immer noch auf eine Art, die kein LLM vorhersehen kann. Nutze die Methode ergänzend zur User Research, nicht als Ersatz.

Auch beim Testing gibt es klare Grenzen: Claude testet UX und Accessibility, aber keine Performance oder Skalierbarkeit. Ladezeiten, Datenbankperformance unter Last, Race Conditions, Memory Leaks – all das findet klassisches Testing besser. Technische Unit-Tests und Integration-Tests bleiben unverzichtbar.

Und schließlich: Claude kann „Sabine würde hier frustriert sein“ simulieren – aber echte Emotionen sind etwas anderes. Die emotionale Komponente echter User – Frustration, Freude, Verwirrung – fehlt. Ein LLM kann rational analysieren, aber nicht fühlen.

Best Practices aus der Praxis

Nach drei Monaten Erfahrung mit der Methode hier meine wichtigsten Tipps:

1. Starte klein: Beginne mit 2-3 Personas und je einer Journey. Nicht direkt alle möglichen User-Typen abbilden wollen. Qualität vor Quantität.
2. Markdown ist dein Freund: Strukturierte Personas und Journeys als Markdown machen sie für Claude leicht lesbar und für Menschen gut wartbar. Git-Versionierung inklusive.
3. Priorisiere deine Personas: Fokussiere auf die wichtigsten User-Typen – nicht auf jeden möglichen Edge-Case. Die 80/20-Regel gilt auch hier: 20% deiner Personas decken 80% deiner User ab.
4. Iteriere die Personas: Wenn neue User-Daten reinkommen (neue Umfragen, geänderte Analytics), update deine Personas. Sie sollten „leben“ und sich mit deinem Produktverständnis entwickeln.
5. Kombiniere mit traditionellem Testing: User Journey Testing ergänzt deine Test-Suite – es ersetzt sie nicht. Selenium, Unit-Tests und Integration-Tests bleiben wichtig.

Ein Wort zu den Kosten: Nicht für die CI/CD-Pipeline

Bevor du jetzt überlegst, diese Tests in deine CI/CD-Pipeline zu integrieren: Bitte nicht.

Es gibt zwei gute Gründe dagegen:

Was stattdessen funktioniert

Fazit: Testing neu denken

Drei Monate nachdem ich diese Methode eingeführt habe, hat sich mein Verhältnis zu Testing fundamental verändert.

Testing ist nicht mehr nur „Fehler finden“. Es ist „Verstehen, wie Menschen meine Software erleben“. Und dieses Verständnis fließt direkt zurück in bessere Produkte.

Claude hat Sabine nicht ersetzt – aber er hat mir gezeigt, wo Sabine stolpern würde, bevor sie es tut.

Was du brauchst, um zu starten

• Claude (mit API-Zugang oder Claude Code CLI)
• Chrome DevTools MCP Server
• Superpowers Skill für strukturierte Workflows
• Bereitschaft, Testing neu zu denken

Der Rest ist Iteration. Erstelle eine Persona. Definiere eine Journey. Lass Claude durchspielen. Beobachte. Lerne. Verbessere.

Und plötzlich ist Testing nicht mehr eine lästige Pflicht – sondern eine Quelle für Insights, die dein Produkt besser machen.