Stellen wir uns vor, wir arbeiten daran, das Reservierungssystem des Kundenservices einer größeren internationalen Hotelkette zu verbessern. Folgende Ausgangssituation liegt vor:
Angelique, eine erfolgreiche Vertriebsmitarbeiterin für die westliche Region der USA, hat für nächste Woche eine Reservierung für den Standort Denver vorgenommen, um am jährlichen Vertriebsmeeting ihrer Firma teilzunehmen. Nun hat sie sich dazu entschieden, zwei zusätzliche Tage zu bleiben, um Kunden aus der Gegend um Denver zu besuchen. Sie muss ihren Aufenthalt also verlängern.
Sie wählt die Servicenummer für Platin-Kunden. Das System verbindet sie mit Eduardo (mit 18 Jahren Erfahrung ein Callcenter-Veteran), Angeliques Account-Informationen und ihre Reservierung für nächste Woche erscheinen automatisch auf seinem Bildschirm.
Als Angelique um eine zweitätige Verlängerung ihrer Reservierung bittet, stellt Eduardo fest, dass das Hotel ausgebucht ist, weil ein weiteres Event stattfindet, für das der reservierte Block jedoch noch nicht vollständig zugeteilt wurde.
Während Angelique noch am Telefon wartet, kontaktiert Eduardo den Eventmanager des Hotels und erhält die Freigabe, ein Zimmer im reservierten Block an Angelique weiterzugeben. Er richtet es auch so ein, dass sie ihr Zimmer nicht unter der Woche wechseln muss.
In Szenarien muss es auf jedes Detail ankommen
Wenn wir mit unseren Kunden Szenarien wie dieses entwickeln, sind wir darauf bedacht, sicherzustellen, dass jedes beschriebene Detail in gewissen Aspekten wichtig für das Interaktionsdesign ist. Beispielsweise haben wir zwei Personen genannt, nämlich Angelique, die Vertrieblerin mit einer Platin-Treuekarte (was bedeutet, dass sie mindestens 75 Nächte pro Jahr in unserem Hotel verbringt), und Eduardo, den langjährigen Kundenservicemitarbeiter.
Eduardo weiß, dass Angelique eine Platin-Kundin ist. Das heißt, dass er praktisch alles Menschenmögliche tun muss, um einen perfekten Aufenthalt zu gewährleisten. Indem wir Eduardo als Mitarbeiter mit 18 Jahren Callcenter-Erfahrung identifizieren, zeigen wir dem Team, dass er sich auskennt und sämtliche größeren Umstellungen am Reservierungssystem überlebt hat, darunter den Relaunch vor zwei Jahren, der ein komplettes Usability-Desaster war. (Er führte beinahe zum Streik.) Wir müssen sicherstellen, dass die neuen Features für Eduardo einfach sind, damit er tun kann, was immer nötig ist, um Angelique glücklich zu machen.
Es ist auch wichtig, die Dinge zu erwähnen, die in dem Szenario nicht aufgezeigt werden. Zum Beispiel gibt es keine Persona für den Eventmanager des Denver-Hotels, weil dieser nicht mit der Kundenoberfläche arbeitet. Das könnte zwar ein Bestandteil einer künftigen Design-Initiative werden, aber was für eine Entscheidung im Rahmen unseres aktuellen Projekts nicht nötig ist, lassen wir im Szenario außen vor. Das macht die Szenarien kurz und konzentriert.
Die Verhaltensformel: User + Interaktionsdesign + Kontext
Als Interaktionsdesigner ist unser Medium das Verhalten. Drei Elemente haben Einfluss auf das Ergebnis der Nutzung unseres Interaktionsdesigns: Der User, das Design selbst und der Kontext. Wir können zwei dieser Aspekte konstant halten, ändert sich aber der dritte, hat dies höchstwahrscheinlich Auswirkungen auf das Verhalten.
Ein Beispiel: Würden wir an Angeliques Situation und am Interaktionsdesign nichts ändern, aber Eduardo zu einem neuen Mitarbeiter im Kundenservice machen, wüsste er vielleicht nicht, dass er die Blockzuteilung des Events überprüfen oder den Eventmanager kontaktieren muss. Bliebe andererseits beim Interaktionsdesign und bei Eduardo alles gleich, aber Angeliques Anliegen würde dahingehend variieren, dass sie mit ihrer Familie Urlaub machen will, für den sie noch ein zusätzliches Zimmer benötigt, müssten wir uns um ein Nachbarzimmer für die Extratage kümmern.
Teams sind normalerweise sehr gut darin, Design-Unterschiede und User-Unterschiede zu katalogisieren. Probleme kriegen sie, wenn sich der Kontext ändert.
Bei jeder anspruchsvollen Herausforderung in Sachen Interaktionsdesign gibt es in der Regel eine Vielzahl von Kontextvariationen, die überwältigend sein können. Manche sind erfolgskritisch, manche sind nur Grenzsituationen, die selten vorkommen und keine großen Auswirkungen auf den Projekterfolg haben. Die große Herausforderung für das Team besteht darin herauszufinden, was was ist.
Den Happy Path identifizieren
Der Happy Path ist für den User der einfachste Weg zum Erfolg, die Zufriedenheitsgarantie also. Er sollte bei jedem Schritt eindeutig erkennbar sein und die geringste Anzahl von Schritten erfordern. Den Happy Path festzulegen, ist ein erfolgskritischer Faktor. Wenn wir das nicht richtig hinbekommen, wird jede alternative Nutzung unseres Interaktionsdesigns umso schlechter sein.
Um den Happy Path zu identifizieren, müssen wir alle inhaltlichen Variablen vereinfachen. Für das Verlängerter-Hotelaufenthalt-Szenario könnte das bedeuten, dass man alle Komplikationen durch das neue Event streicht. Wenn es im Hotel in Denver jede Menge freie Zimmer gibt, sollte es für Eduardo sehr einfach sein, Angeliques Aufenthalt zu verlängern.
Wie viele Klicks ist das Happy-Path-Szenario lang und wie viel Zeit nimmt es in Anspruch? Wie weit können wir es zusammenkürzen? Darauf müssen wir uns zuerst konzentrieren.
Wir arbeiten bevorzugt als allererstes am Happy-Path-Szenario, ehe alles kompliziert wird. Wenn wir anderen Leuten aus der Firma unser Interaktionsdesign vorstellen, begehen wir immer erst den Happy Path. Da wir natürlich ganze Arbeit dabei geleistet haben, ihn super-einfach zu machen, ist er schnell und simpel und bereitet das Publikum auf die komplexen Dinge vor, die wir nun einführen wollen.
Kontextvariationen spezifizieren
Sobald wir unser Happy-Path-Szenario klar identifiziert haben, beginnen wir damit, Kontextvariationen zu sammeln.
- Was ist, wenn die zusätzlichen zwei Nächte auf eine andere Kreditkarte gehen müssen, weil das Vertriebsmeeting nur für die ersten drei Nächte aufkommt?
- Was ist, wenn sich eine Kollegin oder ein Kollege Angelique für die zusätzlichen Tage anschließen will, aber nicht am Vertriebsmeeting teilnimmt, wobei Angelique aber beide Zimmer mit derselben Karte bezahlen möchte?
- Was ist, wenn Angelique sich nicht mit ihren Kunden trifft, sondern einen Familienurlaub mit ihrem Ehemann und ihren kleinen Kindern macht? (Das macht ein King-Size-Bett statt eines Doppelbetts und ein angrenzendes Zimmer für die Kinder nötig und verkompliziert Eduardos Bestreben, ihr einen Zimmerwechsel während ihres Aufenthalts zu ersparen.)
- Was ist, wenn Angelique am vierten Tag runter nach Colorado Springs fahren muss, aber am fünften Tag wieder ins Denver-Hotel zurückkehren möchte?
Jede dieser Variationen ist eine einfache Veränderung des ursprünglichen Szenarios. Jede einzelne impliziert Funktionalitäten des Interaktionsdesigns, die wir womöglich integrieren müssen. Hier kommt die Frage auf, welche sich im Rahmen unseres aktuellen Projektes bewegen und welche wir vorerst für später aufheben sollten.
Szenarien mithilfe von Nutzerforschung priorisieren
Wenn wir die Variationen umrissen haben, ist es nicht mehr schwer ein Nutzerforschungsprojekt aufzusetzen, um herauszufinden, wie häufig jede einzelne vorkommt.
In diesem Beispiel könnten eine einfache Tagebuchstudie oder Interviews mit Kundenservicemitarbeitern schnell Auskunft über die Frequenz geben. Es könnte hilfreich sein, die Leute eine Strichliste führen zu lassen. Zu einer guten ersten Schätzung können wir sogar kommen, indem wir erfahrenen Mitarbeitern einfach die Frage stellen: „Kommt dieses Szenario oft vor?“
Wenn wir die Hochfrequenzvariationen kennen, können wir eine Schwelle definieren, um zu entscheiden, welche Szenarien im Projektumfang berücksichtigt werden sollen. Vielleicht arbeiten wir nur an den Variationen, die häufiger als ein Mal pro 100 Anrufe auftreten? Oder eher an denen, die jeden Tag vorkommen?
Doch dabei sollten wir es nicht belassen. Manchmal gibt es Variationen, die strategisch wichtig sind, aber nicht sehr oft eintreten.
Um zu identifizieren, welche dieser Variationen im Projekt berücksichtigt werden sollten, bietet sich häufig die KJ-Analyse an. Wenn wir fertig sind, haben wir die kritischsten selten vorkommenden Kontexte aufgedeckt, die ins aktuelle Projekt integriert werden müssen.
Indem wir mit einem kontextreichen Szenario beginnen, den Happy Path identifizieren und dann die anderen Variationen spezifizieren, kristallisieren sich langsam die großartigen Nutzererlebnisse heraus, die wir anstreben.
Die Anwendung von Techniken aus der Nutzerforschung, um die Kontextvariationen zu priorisieren, die wir zuerst in Angriff nehmen müssen, machen das Projekt steuerbar und handlich. Steuerbare und handliche Projekte führen zu tollen Ergebnissen und Sie wissen ja, wie sehr wir es lieben, tolle Ergebnisse zu produzieren.
Dieser Artikel wurde im Original am 8. August 2012 unter dem Titel Context-Rich Scenarios Make UX Projects Manageable
