How-To: Scenario-based Design

Damit Software erfolgreich ist, genügt es längst nicht mehr, dass sie gut funktioniert. Sie muss sich gut anfühlen. Erfolgreiche Firmen, wie Google, Facebook und IBM verankern deshalb Design Thinking tief in ihrer Firmenkultur, um dieses gute Gefühl beim Kunden zu gewährleisten. Sie nutzen umfangreiche Daten von Nutzern, führen A-B-Tests durch und wägen Schritte ab, die User Experience noch weiter zu verbessern. Doch wie beginnt man?

Scenario-based Design, kurz SBD, ist eine Methode des nutzerzentrierten Designs. Es nutzt einen einfachen Werkzeugkasten aus Personas, Szenarios und Claims, um höchst unterschiedliche Nutzergruppen und Situationen bei der Interfacegestaltung zu beachten. SBD ist ein iterativer Prozess. Der Ablauf ist in drei grobe Phasen gegliedert, allerdings können Szenarios und Claims aus früheren Phasen ohne Weiteres überarbeitet werden, so sich neue Erkenntnisse bilden.

Der Ablauf gliedert sich wie folgt:

• Analyse
  • Nutzeranalyse, Erstellen der Personas
  • Problemszenarios – Was geschieht momentan?
• Design
  • Aktivitätsszenarios – Was möchte der Nutzer?
  • Informationsszenarios – Was zeige ich dem Nutzer?
  • Interaktionsszenarios – Wie interagiert der Nutzer?
• Prototyp
  • Implementierung
  • Evaluierung anhand von Nutzerfeedback

Für diesen Post zeige ich an einem einfachen Beispiel die Bedeutung der Begriffe auf. Meine (fiktive) Firma möchte einen Fitnesstracker entwickeln, um Kunden zu einem gesünderen Lebensstil zu animieren. Der Tracker soll die täglichen Schritte aufzeichnen, es erlauben, Tagesziele zu setzen, und über den Fortschritt informieren. Die Ergebnisse unserer Nutzeranalyse liegen uns in diesem Dokument vor.

Personas – Greifbare Nutzerdaten

Grundlage für den Designprozess ist die Persona. Personas sind fiktive Persönlichkeiten und verkörpern die Charakteristika von Nutzergruppen. Sie sind detailliert ausgearbeitet, um Nutzerdaten greifbar zu machen und ein Gesicht zu geben. Sie können Fehler machen, wie jeder normale Mensch, und besitzen nur unvollkommenes Wissen über das System.

Personas sind wichtig, weil sie dem Team die Möglichkeit geben, sich in die Position unterschiedlicher Nutzer hineinzuversetzen, um ihre Wünsche und Bedürfnisse besser zu verstehen. Ein Entwicklerteam hat andere Erwartungen an einen Fitnesstracker als ein passionierter Läufer oder eine Hausfrau. Genauso hat es andere Fertigkeiten. Beispielsweise hat das Team statistisch gesehen wesentlich bessere Computerkenntnisse als 60-90% aller deutschen Nutzer. Diese Nutzer könnten den Tracker frustriert beiseitelegen, wenn er zu kompliziert gestaltet wird.

In unserer Nutzeranalyse sind mehrere einfache Personas beschrieben. Es ist wichtig, mehrere Personas zu entwerfen. Zum einen erkennt das Team so die Bedürfnisse verschiedener Nutzergruppen, statt sich auf eine einzelne zu fokussieren. Zum anderen verringert es die Versuchung, die Persona zu allgemein zu halten oder auf Designwünsche zurecht zu schneidern.

Eine Persona benötigt folgende Eigenschaften

• Name und Portrait
• Motivation
• Charaktereigenschaften, Gewohnheiten, soziales Umfeld
• Fertigkeiten oder Behinderungen (Einschränkungen)

Alle diese Daten dienen dazu, die Persona zu einem Charakter zu gestalten, mit dem das Team sich identifizieren kann.

Beispiel: Diana Haller – Competitive Couple

Diana Haller ist eine Medizinstudentin in München, und möchte Hirnchirurgin werden. Aktuell verwendet sie täglich einen alten StepTracker, und teilt ihre täglichen Schritte und Erfolge mit ihrem Volleyballteam und ihrer Familie. Sie würde einen neuen Tracker kaufen, sofern er bessere Features aufweist. Diana ist eine ehrgeizige Person, treibt viel Sport und konzentriert sich sehr auf ihr Studium. Sie fährt täglich mit dem Rad zur Uni, zum Schwimmen und zum Volleyballtraining.

Szenarien – Konkrete Erzählungen

Szenarien sind fiktive Geschichten über Personas, ihre Ziele und Aktivitäten, meistens im Zusammenhang mit der Anwendung. Ein Szenario kann einen konkreten Tagesablauf von Diana und dem Umgang mit ihrem aktuellen StepTracker beschreiben.

Ein Szenario hebt folgende Aspekte hervor:

• Wie beeinflusst die Anwendung die Ziele des Nutzers?
  Spornt der Fitnesstracker zum Beispiel dazu an, mehr Treppen zu nehmen und kürzere Wege zu gehen, oder fühlt die Persona sich frustriert, weil die Batterie auf einem langen Spaziergang ausgefallen ist?
• Welche Dienste sucht der Nutzer von der Anwendung?
  Möchte die Persona für ein oder zwei Wochen nach Weihnachten die Schrittzahl heben, um die Feiertagspfunde loszuwerden, oder einstellen, dass sie jeden Tag um 12 Uhr über den aktuellen Fortschritt informiert wird?
• Welche Interpretation folgt auf das Feedback der Anwendung?
  Wie interpretiert der Nutzer die Daten, wenn ich sie als Schritte, Kalorien oder Minimuffins darstelle? Wie reagiert die Persona, wenn der Tracker sie wie ein drillender Bundeswehroffizier anspricht, oder wie ein motivierender Personal Trainer?

Stärken von Szenarien sind leicht zu benennen. Man benötigt wenig, um ein Szenario zu schreiben und sie sind schnell geschrieben, wodurch sie flexibel und leicht zu verfeinern sind.  Sie spezifizieren die Funktionalität eines Systems im tatsächlichen Anwendungskontext, der erhebliche Auswirkungen auf die Anforderungen an das User Interface haben kann, aber von klassischen Methoden wie Use Cases nicht abgedeckt wird. Und sie legen den Fokus auf Ziele, Pläne und Verständnis der Nutzer, statt auf reine Funktionalität.

Arten von Szenarien

Es gibt vier verschiedene Arten von Szenarios, die teilweise eine sehr unterschiedliche Fülle an Details aufweisen.

• Problemszenarien erkunden die aktuelle Praxis. Sie dienen dazu aktuelle Probleme aufzudecken, allerdings auch positive Aspekte in aktuellen Prozessen zu finden. Das eigentliche Produkt kommt noch nicht vor.
• Aktivitätsszenarien beschreiben, welche typischen und kritischen Dienste Nutzer von der Anwendung erwarten. Sie fokussieren sich auf die reine Funktionalität und lassen Details über Feedback und Bedienung der Anwendung außen vor.
• Informationsszenarien bauen auf den Aktivitätsszenarien auf und verfeinern sie. Sie beschreiben, auf welche Weise die Daten der Anwendung dem Nutzer präsentiert werden, und wie diese Informationen vom Nutzer interpretiert werden.
• Interaktionsszenarien sind vollständige Designspezifikationen, die die Ergebnisse von Aktivitäts- und Informationsszenarien beinhalten. In ihnen sind unterstützte Aufgaben, die Kodierung der Information und das Feedback der Anwendung spezifiziert, sowie der Einfluss auf den eigentlichen Anwender.

Problemszenarien gehören wie der Aufbau der Personas zur Analyse einer Anwendung, während die anderen drei Szenarien zum Entwurf der Anwendung herangezogen werden.

Beispiel: Problemszenario

Diana Haller ist Studentin und steht um 7 Uhr morgens auf. Sie macht sich rasch frisch, isst eine Schale Haferflocken zum Frühstück und fährt dann zum Schwimmen. Die Schwimmhalle ist einige Kilometer von ihrem Wohnheim entfernt, also fährt sie mit dem Fahrrad dorthin. Nach dem Schwimmen fährt sie zur Universität, um ihren Vorlesungen für den Montag zuzuhören.

Auf dem Weg zur Vorlesung überprüft sie ihren Tracker. Da Diana wenige Schritte an diesem Tag gelaufen ist, sondern mehr Fahrrad fuhr, zeigt er eine frustrierend kleine Zahl. Also läuft Diana gezielt über die Treppen in den Hörsaal und nimmt auch einige Umwege in Kauf. Um ihre Schritte zu erhöhen, schiebt sie das Fahrrad sogar zur Bibliothek, wo sie an einer Lerngruppe teilnimmt.

Am Abend trainiert Diana mit ihrem Volleyballteam. Sie und ihre beste Freundin vergleichen die Schritte, die sie an diesem Tag geschafft haben. Noch immer ist Dianas Zahl wesentlich kleiner als üblich, und Diana ist frustriert, weil ihre Kilometer auf dem Rad und ihre Schwimmzüge nicht mitgezählt werden. Nachdem sie von ihrer Freundin aufgezogen wird, gibt sie ihr Bestes, um die Volleyballrunde zu gewinnen.

Claims – Pro und Kontra

Claims sind die Merkmale des Szenarios, die den Nutzer auf positive oder negative Art und Weise beeinflussen. Zu jedem Szenario werden Claims aufgelistet. Am Ende entsteht eine Liste aus Tradeoffs, die zur Diskussion über Features, Situationen und Anforderungen herangezogen werden können.

Eine Claim Analyse für das oben aufgeführte Problemszenario würde wie folgt aussehen:

• Das Teilen der Schrittzahl mit Freunden ist eine soziale Aktivität, und erhöht Dianas Bindung an den Fitness Tracker.
• Das Tracken und Prüfen der Schrittzahl führt bei Diana zu gesundem Verhalten (Treppensteigen, Laufen).
• Die Limitierung ihres Schrittzählers frustriert Diana. Sie bewegt sich langsamer als notwendig, um die Schrittzahl zu erhöhen (gehen statt Fahrradfahren), um ihren objektiven Fortschritt zu erhöhen.

Wie es weiterginge …

Anhand des Problemfalls und der groben Nutzeranalyse haben wir eine Persona entwickelt und ein Problemszenario geschrieben, in dem wir die aktuelle Praxis beleuchten. Das Szenario haben wir Claims analysiert. Wie allerdings bereits geschrieben, wären mehrere Personas benötigt, mit denen wir dann ebenfalls die aktuelle Praxis betrachten können. Im Anschluss können wir diese auf Claims überprüfen und unsere Erkenntnisse in Entwürfe einfließen lassen. Wer üben möchte, ist gern dazu eingeladen, eine Persona für zum Beispiel den Steady Stepper (Slide Nr. 7) zu erstellen und mit uns zu teilen.

Weiterführende Lektüre:

• UX Without User Research Is Not UX – Weshalb die Nutzer mit an den Tisch geholt werden sollten.
• Design Thinking 101 – Um tatsächliche Substanz hinter den Werbebegriff „Design Thinking“ zu bringen.
• The 5 best guides for creating customer personas – Um mehr Anleitung für das Erschaffen von Personas zu erhalten.
• The Design Sprint Kit by Google – Um weitere Designframeworks kennen zu lernen.