Im dritten Artikel dieser Serie wurde an einem Beispiel beschrieben, wie effektiv und schnell Personas auf Basis der Ergebnisse von Feldstudien entwickelt werden können. Dieser vierte und letzte Artikel zum Thema widmet sich dem Vorgehen bei der Erstellung von Szenarien und Prinzipien.
Aktivität 3: Die Szenarien schreiben – anderthalb Stunden
Das Schreiben der Szenarien ist der einfachste Teil des Prozesses. Es erfordert selten mehr Aufwand, als die Aufzeichnungen aus der Nutzerforschung durchzugehen und Geschichten davon zu dokumentieren, was wir tatsächlich gesehen haben.
Für jede Persona schrieben wir zwei oder drei Szenarien auf. Das sind Stories, die beschreiben, was diese Persona mit unserem Projekt zu tun versuchen würde. Sie setzen den Kontext auf, beschreiben den Flow der Persona und umreißen, wie ein erfolgreiches Erreichen des Ziels aussähe.
Für eine unserer Personas – First-time-Freddy – entwarfen wir das folgende Szenario:
Vor ein paar Wochen fing Freddy als Manager dieser Gruppe an. In seinem Management-Mitarbeiter-Meeting erfuhr er, dass das Unternehmen plant, am anderen Ende der Firma einen zweiten Callcenter zu eröffnen. Dort würden Trainer benötigt, und Freddy will nachvollziehen, wer die am besten geeigneten Repräsentanten an seinem Standort sind, um ein Elite-Training-Team empfehlen zu können.
Er muss die Kriterien identifizieren, die jemanden zu einem guten Trainer machen, und in seinem Team diejenigen Leute ermitteln, die diese Kriterien exzellent erfüllen. Das möchte er alle paar Wochen tun, sodass er mit den Daten fertig ist, wenn die Zeit gekommen ist.
Dieses Szenario war einfach zu schreiben, weil wir gesehen hatten, dass es in der realen Welt existiert. Es kam direkt aus dem echten Leben.
Wieder nahmen wir uns am Ende dieses Stadiums die Zeit, um unsere Szenarien mit denen der anderen Teams zu vergleichen. Wie so oft wiesen diese bemerkenswerte Übereinstimmungen mit dem auf, was wir aufgeschrieben hatten, waren aber leicht abgewandelt, damit sie zu den entsprechenden Projekten passten.
Aktivität 3: Die Prinzipien entwickeln – zweieinhalb Stunden
Die letzte Aktivität des Tages bestand darin, unsere UX-Design-Prinzipien zu entwickeln. Das sind spezielle Faustregeln, die helfen, die richtigen Design-Entscheidungen zu treffen. Die Idee dahinter ist die, dass Teams, die eine schwere Entscheidung zwischen zwei Möglichkeiten treffen müssen, diejenige wählen können, die dem Prinzip am nächsten kommt. Prinzipien können auch helfen, das Team anzutreiben, sich in einer bestimmten Dimension noch mehr anzustrengen, und die Grenze zwischen einer Lösung, die okay ist, und einer ausgezeichneten Lösung zu überschreiten.
Unser Ziel war es, mit vier Prinzipien aufzuwarten, die spezifisch für unser Projekt waren – der Entwicklung eines Tools zum regelmäßigen Sammeln der Performance-Daten von Mitarbeitern. Wir starteten mit einem simplen Trick: Wir würden wir die mieseste Version dieses Tools machen?
Ein paar Minuten lang brainstormten wir alle Möglichkeiten, eine Version unsers Tools zu erschaffen, die fürchterlich zu nutzen wäre. Wir begannen mit den offensichtlichen Dingen: Die Anweisungen wären schwer zu verstehen. Es würde wirklich langsam sein. Es würde nur auf einem veralteten Hardware-System laufen, etwa einem Apple Newton.
Nach dieser ersten Salve wurde das Team still. Hatten wir alles abgedeckt? Augenscheinlich nicht, denn plötzlich kamen die wirklich interessanten Ideen heraus: Es würde einen nicht speichern lassen, sodass man alles auf einmal fertigstellen müsste. Es würde einen nicht von Mitarbeiter zu Mitarbeiter springen lassen, stattdessen müsste man das gesamte Team durchgehen. (Für Freddy mit seinen 18 direkten Reports wäre das höllisch.)
Mit der Zeit hatten wir ungefähr 20 verschiedene Dinge zusammen, die jedes Tool, mit dem wir daher kämen, total mies machen würden. Und aus diesem Höllenfeuer, das wir erschaffen hatten, entstieg unser Verständnis davon, was wirklich wichtig war.
Als nächstes nahmen wir uns die Liste mit den grauenvollen Features erneut vor und versahen jedes mit Attributen. Ein langsames UX-Design bedeutete, dass Performance eine wichtige Eigenschaft war. Und den Nutzer nicht speichern zu lassen, hieß, dass unterbrechbar auch eine wichtige Eigenschaft war. Am Ende hatten wir 25 Attribute.
Wieder nutzten wir unsere Punkte und voteten für die Eigenschaften, die wir für die wichtigsten hielten. Von hieraus fingen wir an, die Top-Kandidaten näher zu erkunden. Welche würden uns in Richtung hervorragend vorantreiben?
Prinzipien als Kompromisse
Für jedes der Top-Attribute stellten wir zwei Fragen: Was würde uns über das hinausbringen, was wir heute liefern? und Was treibt uns in die schlechten Gewohnheiten von heute? Unser Ziel war es, Prinzipien zu bekommen, dank derer wir aus dem, was wir normalerweise tun, ausbrechen und etwas Besseres entwickeln können, als wir es bisher getan haben. Anhand der Antworten auf diese beiden Fragen arbeiteten wir Prinzipien aus, die wir als Kompromiss-Statements formulierten.
Damit ein Manager seine Arbeit speichern kann, ohne sie zu beenden, mussten wir die Anforderung aufgeben, dass alle Datenbank-Updates komplettierte Transaktionen sein müssen. Das Erlauben unvollständiger Transaktionen war etwas, was das Backend bisher nicht handhaben konnte, aber das ließe sich ändern. Von hieraus entstand das Prinzip Wir bevorzugen die Komplettierung über Sessions hinweg gegenüber dem Bestehen auf komplette Transaktionen.
Wir wählten vier Prinzipien aus unserer Liste mit Attributen. Nachdem wir fertig waren, hatten wir ein solides Verständnis davon, wie wir unsere Lösung über das hinausbringen konnten, was wir in der Vergangenheit ausgeliefert hatten.
Als wir unsere vier Prinzipien mit denen der anderen Teams verglichen, waren wir einmal mehr verblüfft von den Übereinstimmungen. Ein Prinzip tauchte auf jeder Liste auf, obwohl die Teams sich nicht untereinander ausgetauscht hatten. Einige andere standen auf mehr als einer Liste auf. Es war klar, dass die Nutzerforschung eine neue Philosophie im Hinblick auf das UX-Design beeinflusst hatte.
Fertig. Und nun?
Nach sieben Stunden hatten wir vier Personas, zehn Szenarien und vier UX-Design-Prinzipien für unser Projekt entwickelt. Die beiden anderen Teams waren in der gleichen Zeit auf eine ähnliche Ausbeute gekommen. Das ist schon eine Leistung.
Noch aufregender war, wie energetisiert das Team war, mit dem Design-Prozess zu beginnen. Sie fühlten, dass sie eine solide Idee davon hatten, wer ihre User waren, was diese Nutzer brauchten und wie das Team bessere Lösungen als je zuvor produzieren konnte.
Am nächsten Tag hielten wir einen zweitägigen Design-Studio-Workshop für unsere Projekte ab. Jedes Team nutzte die Prinzipien, Personas und Szenarien, die es erstellt hatte, als Guide. Am Ende hatten die Teams belastbare Design-Ideen entwickelt, die sie in den schnellsten Entwicklungsprozess vorantrieb, den sie je gesehen hatten.
Das Erschaffen leichtgewichtiger, nutzerforschungsbasierter Prinzipien, Personas und Szenarien ist eine zuverlässige Technik, um die User ins Zentrum des Prozesses zu stellen.
Dieser Artikel wurde im Original am 14. November 2013 unter dem Titel LiRPPS: Lightweight, Research-Based Principles, Personas, and Scenarios - Part 2
