Wir waren perplex, als wir erkannten, dass wir uns so dermaßen vergaloppiert hatten. Bis gerade eben hatte es noch so ausgesehen, als wären unsere Entscheidungen immer die richtigen gewesen. Doch nun, da wir echten Nutzern beim Interagieren mit unserer Entwicklung zuschauten, blieb uns als Entschuldigung nur zu sagen, dass wir offenbar nicht wussten, was wir da taten.
Dieses kleine Stück der Anwendung war nicht wirklich wichtig für das gesamte System. Das Team hatte lediglich eine kleine Funktionalität eingebaut, praktisch in letzter Minute vor der Auslieferung.
Nun aber, direkt vor unseren Augen, frustrierte dieses Detail den Betreiber des Online-Shops. In den vergangenen Wochen war es gleich fünf Shop-Besitzern so ergangen, und für Frust hatte immer die gleiche Funktion gesorgt. Für das Team war es schwer, dabei zuzusehen, noch schwerer war es allerdings, nicht hinzuschauen.
Das Problem, das wir lösen wollten, ist schnell dargestellt: Der Inhaber des kleinen Shops, in dem nicht mal 100 Produkte angeboten werden, hatte gerade eine neue Warenlieferung erhalten. Nun wollte er die Produkte ins System einspeisen und das Inventar aktualisieren, damit die Rechnungsabteilung auf dem aktuellen Stand ist, wenn Leute den Kram bestellen.
Nun, es war kompliziert, die 15 neuen Produkte hinzuzufügen, die sich in diesem Pappkarton befanden. Hier klicken, dies eintippen, jenes bestätigen, dieses Feld deaktivieren. Das Problem: Der Betreiber muss die Aktualisierung unabhängig von der Bestellung bzw. dem Wareneingang durchführen, aus einem simplen Prozess sind zwei Schritte geworden. Die meisten Shop-Betreiber, denen wir zugeschaut haben, taten nicht, was sie eigentlich sollten. Stattdessen fummelten sie am Bestandswert herum, und das häufig auch noch inkorrekt. Fehlerhafte Inventuren und Bilanzen waren vorprogrammiert.
Was eigentlich ein Fünf-Minuten-Prozess sein sollte, dauerte jetzt eine Viertelstunde. Noch schlimmer: Wir haben Shop-Betreiber gesehen, die den ganzen Prozess einfach übersprungen haben mit der Folge, dass künftige Berichte inkorrekt sind und der Finanzabteilung das Leben schwer gemacht wird.
Dieses kleine Stück Software brauchte eine gründliche Überholung. Und dieses Mal sollte das Team seine Arbeit viel besser machen.
Usability-Engineering in der agilen Welt
Im Rahmen des Wandels weg vom Wasserfall-Projektmanagement hin zu agileren und schlankeren Methoden beobachten wir, dass das Stadium Big Design Up Front, in dem alles komplett durchdacht wird, wegfällt. Tatsächlich kommt in diesem Stadium auch nie etwas wirklich Tolles heraus, also können wir mit Fug und Recht von einer Befreiung sprechen.
Dennoch hat der Wegfall dieses Ansatzes eine Lücke hinterlassen: Es fällt Teams schwer, sich das große Ganze vorzustellen. Das Ergebnis ist eine Zerlegung des Konzeptions- und Entwicklungsprozesses, alles besteht aus winzig kleinen Stücken, die, wenn man sie am Ende zusammensetzt, mitunter zu solch frustrierenden Nutzererlebnissen führen.
Viele Teams haben ihre liebe Mühe mit diesem Prozesswandel, andere haben die Hürde erfolgreich genommen: Sie produzieren wunderbare, produktive Nutzererlebnisse. Diesen Teams haben wir über die Schulter geschaut, um zu lernen, was sie anders machen.
Die User-Story-Ebene
Bei den meisten agilen Prozessen steht die User-Story im Zentrum der Anstrengungen. Hier führen Teams Stories ein, die einem Muster wie diesem folgen: "Als [User] will ich [Aufgabe]." Eine typische Story könnte also so aussehen: „Als Shop-Betreiber will ich neue Produkte ins Inventar eingeben.“ Die Teammitglieder, die am Inventar-Checkin arbeiten, gehen nun her und erstellen eine Funktion, mit der genau dies möglich ist.
Wir haben entdeckt, dass Teams über die User-Story hinaus denken müssen. Es hat sich herausgestellt, dass viele Teams weitere Ebenen berücksichtigen.
Die Szenario-Ebene
Die gerade angesprochene User-Story ist eine von vielen, die unter dem Dach der Nutzerszenarien zusammengefasst werden. Szenarien sind spezifische Geschichten, die Nutzern passieren. Eine solche Geschichte könnte sich wie folgt lesen:
Armando, unser Shop-Betreiber, hat zehn Packungen nahrungsergänzender Vitaminpräparate bestellt, um den abverkauften Bestand wieder aufzufüllen. Er hat sie direkt auf der Website des Großhändlers bestellt und mit der Kreditkarte des Unternehmens bezahlt. Zwei Tage später ist die Bestellung eingetroffen und Armando will sie so schnell wie möglich elektronisch ins Inventar einpflegen. Erstens will er sie verkaufen, zweitens hasst er es, ungeöffnete Kartons herumstehen zu haben.
Ein Szenario wie dieses kann aus mehreren User-Stories bestehen: Man stellt fest, dass ein Produkt ausgeht, die Inventar-Software benachrichtigt den Einkauf, es wird ein Bericht generiert usw. Im Idealfall denkt sich das Team ein Szenario nicht einfach aus, sondern stellt sicher, dass es auf gemeinsamen Beobachtungen realer Nutzer basiert. Aus diesen Erkenntnissen lassen sich adrett, ordentlich und schnell die entsprechenden User-Stories extrahieren.
Die Persona-Ebene
In der Geschichte oben haben wir Armando erwähnt, den Shop-Betreiber. Armando steht für einen bestimmten Typ von Leuten, die mit dem Inventarsystem arbeiten. In Wirklichkeit kennen wir überhaupt niemanden namens Armando, er ist einfach eine Fusion aus mehreren Shop-Besitzern, denen wir begegnet sind.
Armando ist eine Persona, die das Team erstellen könnte, um die Szenarien für diese Nutzergruppe festzuhalten. In Projekten gibt es viele dieser Personas, für die das Team entwickelt, und für jede Persona gibt es mehrere Szenarien.
(Einige Fachleute vertreten die Ansicht, dass man, statt prototypische Nutzer mit fiktiven Namen und Geschichten zu entwickeln, besser einfach reale Nutzer beschreiben solle. Beide Techniken bringen tolle Ergebnisse hervor, beide Methoden sind bewährte Ansätze. Sie unterscheiden sich lediglich in dem Maße, wie sich eine Salatgabel von einer normalen Gabel unterscheidet. Sie nehmen diejenige, die sich im konkreten Fall am besten eignet. Wählen wir die falsche, gibt es wahrscheinlich gar keinen wahrnehmbaren Effekt.)
Personas wie Szenarien funktionieren am besten, wenn sie auf Nutzerforschung basieren. Im Idealfall ist jedes Teammitglied zahlreichen Leuten begegnet, die dann die Personas beeinflusst haben. Weil sie die echten Menschen und somit die wirklichen Aktivitäten hinter den Personas und Szenarien kennen, können sie die Erkenntnisse aus der Nutzerforschung leicht in Entscheidungen übersetzen.
Die Ebene der Usability-Prinzipien
Im Falle des oben beschriebenen Checkin-Problems konnte das Team einige Schlüsselfaktoren identifizieren, auf die die Probleme zurückzuführen sind. Erstens: Der Fokus lag auf einer Lösung für große Unternehmen, in denen Bestellung/Wareneingang und Inventaraufnahme getrennte Prozesse bilden. Zweitens: Die Funktion hat dem emsigen Leben des Shop-Betreibers nur unzureichend Rechnung getragen und ihn genötigt, sich durch für ihn unnötige Schritte zu arbeiten. Und letztens: Aufbau und Anordnung der Formularfelder waren nicht logisch, es gab viele Felder, die die meisten Nutzer niemals benötigen.
Aus diesen drei Schlüsselfaktoren konnte das Team ein paar einfache, aber effektive Usability-Prinzipien ableiten, die sich bei künftigen Auslieferungen als hilfreich erweisen werden:
- Denke klein und schnell. Drücke kleinen Unternehmen keine Prozesse für große Unternehmen auf.
- Ermögliche Unterbrechungen und Schnelleinstiege. Der Nutzer soll mittendrin anhalten können, ohne alle Eingaben zu verlieren.
- Setze die interessantesten Sachen an den Anfang. Nutze fortschrittliche Techniken, um weniger wichtige oder selten genutzte Funktionen nur dann anzuzeigen, wenn der Nutzer es wünscht.
Das Team hat diese Prinzipien direkt aus der Nutzerforschung und den beobachteten Usability-Problemen gezogen. Es ist anzunehmen, dass in anderen Projekten ganz ähnliche Prinzipien anwendbar sein werden. Auf dieser Ebene richten wir unser Augenmerk auf eine Menge unterschiedlicher Personas, Szenarien und User-Stories und erhalten so einen kohärenten Blick aufs große Ganze.
Die Ebene der UX-Vision
Als allgemeinste unserer Ebenen ermöglicht die UX-Vision einen Blick auf das Big Picture: Wie könnte das Nutzererlebnis in Zukunft aussehen, sagen wir in fünf Jahren? Die Vision hilft dem Team, geeignete Prinzipien auszuarbeiten, Personas und Scenarios feinzuschleifen und die richtigen User-Stories aufzustellen, um die bestmögliche Anwendung zu entwickeln.
Wie auch die anderen Ebenen basiert die Vision im Idealfall auf Nutzerforschung. Wenn das Team eine Reihe von Usern trifft und die Gesamtheit der Nutzeraktivitäten betrachtet, erhält es einen guten Eindruck von den erfreulichsten und frustrierendsten Elementen der aktuellen Auslieferung. Das Team kann seine UX-Vision entwerfen, indem es über die Einschränkungen des Altsystems und der widerspenstigen Code-Basis hinaus in eine Zeit blickt, in der die frustrierenden Teile sich in zusätzliche erfreuliche Elemente verwandelt haben (oder komplett entfernt worden sind).
Wie sieht das Nutzererlebnis aus, wenn die frustrierenden Faktoren ausgebügelt sind? Welche Kernattribute bilden die Grundlage für das tolle Nutzererlebnis? Diese Fragen bringen die UX-Vision voran.
Alle im selben Boot
Als wir die Unterschiede zwischen den erfolgreichen Teams und denen, die sich mit den neuen Methoden schwer tun, untersucht haben, sind uns die voneinander abweichenden Herangehensweisen an die beschriebenen Ebenen aufgefallen. Die Teams mit Problemen diskutieren alle Ebenen kurz – oftmals zu Projektbeginn –, konzentrieren sich dann aber fast ausschließlich auf die Arbeit mit den User-Stories, um durch den Entwicklungsprozess zu eilen.
Die erfolgreichen Teams diskutieren alle Ebenen während des gesamten Entwicklungsprozesses. Erstellt ein Teammitglied eine Funktion oder ein Design-Element, das nicht zu der Richtung passt, die sich die übrigen Beteiligten vorstellen, geht das Team einen Schritt zurück, spricht über die anderen Ebenen und versucht herauszufinden, worauf die Abweichung zurückzuführen ist. Weil das Team die Ebenen in Gemeinschaftsarbeit und auf der Grundlage von Nutzerforschung etabliert hat, fällt es ihm leicht, gemeinsam auf kohärente Nutzererlebnisse hinzuarbeiten, von denen sich die Nutzer immer wieder begeistern lassen.
Dieser Artikel wurde im Original am 11. Mai 2011 unter dem Titel Essential UX Layers for Agile and Lean Design Teams von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.
