Die Persona-Methode ist im nutzerzentrierten Gestaltungsprozess durchaus bekannt. Stellvertretend für echte Anwender werden Produkte für diese Personas entwickelt und man fragt sich immer, wie passt das Produkt für diese Persona. Da sie für eine ganze Zielgruppe steht, deckt man also direkt eine größere Gruppe von echten Nutzern ab. Der Vorteil der Personas ist, anstelle von „dem Anwender“ zu reden, fokussiert man sich auf einen Pseudo-Anwender. Die Schwierigkeit liegt schließlich darin, dass fehlende Eigenschaften dieses „Anwender“ in unseren Köpfen unterschiedliche gefüllt werden und so reden wir in einem Projekt nicht vom gleichen „Anwender“ sondern jeder von seinem ganz eigenen Bild eines möglichen Anwenders.
In vielen Entwicklungsprozessen, die mir in den letzten Jahren untergekommen sind, werden User Storys verwendet um Anforderungen aus Sicht einer Rolle zu definieren und Platz für Diskussionen zu lassen. Kern der User Story ist die Beschreibung, die immer nach einem festen Muster zu erstellen ist. Daher wird oft das Muster „Als <Rolle> möchte ich <Funktion>, damit <Grund>.“ verwendet. Die „Rolle“ wiederum bewegt sich je nach Produkt in anderen Bereichen. Bei einem Verwaltungsprogramm können Administrator, Abteilungsleiter und Mitarbeiter passen, währen in einem Verein Vorstand und Mitglied ausreichen könnten. Neben der kurzen Beschreibung gehören auch Akzeptanzkriterien zu der User Story, die als leicht nachvollziehbare Eigenschaften feststellen lassen, ob eine Story bereits vollständig umgesetzt wurde. Da die Akzeptanzkriterien selten vollständig und umfangreich genug definiert sind, kommt es zu Nachfragen bei den Entwicklern. Entscheidungen aus dieser Diskussion werden bei der Story vermerkt und zählen zu den Anforderungen dazu.
Nehmen wir ein Beispiel:
Als Anwender möchte ich von unterwegs das Licht zuhause einschalten können, damit ich mich beim nach Hause kommen sicher fühle.
Dazu verwenden wir nun die (zugegeben sehr kurze) Persona Gerda. Sie ist 43 Jahre alt und lebt in einem kleinen ländlich gelegenen Haus mit ihrem Mann zusammen. Ihr Mann ist beruflich häufiger auf Dienstreise, weshalb sie sich häufiger alleine ist. Nachdem in ihrer Umgebung in letzter Zeit häufiger eingebrochen wurde, fühlt sie sich etwas unsicher.
Kombinieren wir die Persona als Anwender eines Hausautomationssystems bekommen wir die Persona-driven User Story:
Gerda möchte von unterwegs bereits das Licht zuhause einschalten können, damit sie sich beim nach Hause kommen sicher fühlt.
In dieser Version kommen zwei Elemente der Persona zum Tragen. Sie übernimmt die Rolle des Anwenders, was zu einer verbesserten Nutzung der Personas führt. Sie werden immer wieder verwendet und bleiben so in Erinnerung. Auch bei der Diskussion, die entscheidendes Element einer User Story ist, bleibt die Persona im Fokus. Das zweite Element ist das Aufgreifen im Grund. Warum ist die Anforderung wichtig? Gerda kann durch das ferngesteuerte Licht sich das Sicherheitsbedürfnis befriedigen, da Unsicherheiten in der Dunkelheit verringert werden können. Dies im Hinterkopf erschwert es unsinnige User Storys zu schreiben. Wenn man das versucht, wird man ein „Das ist doch Gerda egal!“ zu hören bekommen. Genau dafür nutzt man Persona-driven User Stories!
Weiterführendes
Holt, Eva-Maria; Winter, Dominique; Thomaschewski, Jörg (2011): Personas als Werkzeug in modernen Softwareprojekten. Die Humanisierung des Anwenders. In: Henning Brau, Andreas Lehmann, Kostanija Petrovic und Matthias C. Schroeder (Hg.): Usability Professionals 2011. Chemnitz, 10.-14.09.2011. Stuttgart: German UPA e.V., S. 40–44.
Cooper, Alan; Reimann, Robert; Cronin, David (2007): About face 3. The Essentials of Interaction Design. Indianapolis (Ind.): Wiley.
Persona driven user stories for Agile UX (2010): http://www.disambiguity.com/persona-driven-user-stories-for-agile-ux/
0 Kommentare
Trackbacks/Pingbacks