Nutzerszenario

Zweck

Ein Nutzerszenario erzählt die Geschichte einer bestimmten Person, die die vorgeschlagene Lösung in einem realistischen Kontext nutzt. Anders als Feature-Listen oder Wireframes bettet es das Konzept in die chaotische Realität menschlichen Lebens ein — die Emotionen, die Ablenkungen, die Einschränkungen. Das Schreiben des Szenarios zwingt das Team zu konfrontieren, ob ihre Lösung wirklich passt.

Auf einen Blick

• Gruppengröße: 2–8
• Dauer: 30 Minuten
• Schwierigkeit: Niedrig bis mittel
• Moderationsstil: Angeleitetes narratives Schreiben
• Setting: Beliebiger Raum; Einzel- oder Paararbeit

Ablauf

1. Persona wählen (5 Min): Eine spezifische Nutzer-Persona oder reale nutzende Person als Anker des Szenarios auswählen.
2. Kontext setzen (5 Min): Definieren, wann, wo und warum die nutzende Person auf die Lösung trifft. Was ist gerade passiert? Wie ist die Gefühlslage? Was ist das Ziel?
3. Szenario schreiben (15 Min): Die Schritt-für-Schritt-Reise erzählen: was die nutzende Person tut, sieht, denkt und fühlt bei jeder Etappe. Reibungspunkte und Momente der Freude einbeziehen.
4. Lesen und kritisieren (5 Min): Das Szenario laut vorlesen. Andere hören auf: "Ist das realistisch?" "Wo bricht es?" "Welche Annahmen stecken drin?"

Material

• Persona-Karten oder Nutzerprofile
• Vorlage: Kontext > Auslöser > Schritt 1 > Schritt 2 > … > Ergebnis > Gefühl
• Papier und Stifte oder gemeinsames Dokument

Stolperfallen & häufige Fehler

• Nur Happy Path: Das Szenario sollte Reibung, Fehler und Unterbrechungen enthalten — nicht nur den idealen Ablauf.
• Generische Nutzende: "Ein Nutzer öffnet die App" ist kein Szenario. Eine spezifische Person mit Name, Kontext und Emotion verwenden.
• Zu viele Schritte: Auf den kritischen Pfad fokussieren. Ein 30-Schritte-Szenario ist eine Spezifikation, keine Geschichte.
• Keine emotionale Ebene: Wenn das Szenario nicht erwähnt, wie sich die Person fühlt, ist es ein Prozessdiagramm, kein Nutzerszenario.

Inklusion & Barrierefreiheit

• Szenarien für diverse Nutzende schreiben, einschließlich Menschen mit Behinderungen, unterschiedlicher Technikkompetenz und verschiedenen kulturellen Kontexten.
• Mündliches Erzählen statt geschriebener Szenarien erlauben.
• Barrierefreiheits-Touchpoints im Szenario selbst einbeziehen (Screenreader-Interaktion, Sprachbefehle etc.).

Varianten

• Video-Szenario: Ein Teammitglied filmen, das das Szenario durchspielt, statt es zu schreiben.
• Tages-Szenario: Die Lösungsnutzung in eine ganze Tageserzählung einbetten.
• Fehlerszenario: Ein Szenario schreiben, in dem alles schiefgeht — den Wiederherstellungspfad testen.

Wann NICHT einsetzen

• Wenn das Konzept zu abstrakt ist, um es Schritt für Schritt zu erzählen — zuerst prototypen.
• Wenn quantitative Validierung benötigt wird — Szenarien sind qualitative Werkzeuge.
• Wenn das Team so tief im Problem steckt, dass Szenarien zu Echokammern bestehender Annahmen werden.

Quelle & Weiterlesen

• Carroll, John M. — *Making Use: Scenario-Based Design of Human-Computer Interactions* (MIT Press, 2000)
• Cooper, Reimann & Cronin — *About Face: The Essentials of Interaction Design* (Wiley, 2014)
• Rosson & Carroll — *Usability Engineering* (Morgan Kaufmann, 2002)