Content also available in:

Die Persona als zentrales Element von User Stories

In der Software-Entwicklung hat sich bereits in den 1980er Jahren durch den Entwickler Alan Cooper der Begriff „Persona“ für einen repräsentativen User einer Software durchgesetzt. In der heutigen agilen Entwicklung sind Personas nunmehr de facto Standard für alle Planungen, die den Nutzer oder Kunden betreffen.

User Story

In erster Linie wird die Persona bei der User Story wichtig (weitere Verwendungen später in dieser Serie). User Stories haben in der Regel diese Struktur:

„Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen/Problemlösung>“

Der Grund dieser Struktur wird in einem gesonderten Beitrag zum Thema „User Story“ erklärt. Bei der Persona interessiert uns der Bereich <Rolle>

Die User Story ist eine kurze in Alltagssprache formulierte Softwareanforderung. Da wir sehr kundenzentriert arbeiten wollen, formulieren wir sie aus der Sicht eines Nutzers, der ein Problem gelöst oder ein Bedürfnis befriedigt haben möchte.

Beispiel:

„Als Kunde möchte ich eine große Auswahl an Zahlungsmöglichkeiten im Onlineshop haben, damit ich möglichst einfach nach meinen Wünschen bezahlen kann“

Diese Alltagssprache formuliert für Entwickler das „Was“ einer zu erstellenden Entwicklung. Das „Wie“ ist dem Entwickler überlassen. Diese Alltagssprache soll es einerseits erleichtern, die Anforderungen zu erheben, ohne dicke Lastenhefte zu schreiben. Andererseits soll sich jedes beteiligte Teammitglied in die Person hineinversetzen können und sich bei allen Entwicklungen fragen: „Würde das im Sinne dieses Kunden sein?“

Dieses Hineinversetzen würde schwierig werden, wenn wir – wie in der klassischen Nutzeranalyse – mit soziodemografischen Zielgruppen arbeiten. Unsere Zielgruppe ist männlich, 35-45 Jahre alt, gehobener Mittelstand, etc … – wenn wir aber nun eine „echte“ Person vor Augen haben, mit Bild, Name, Steckbrief und Geschichte, so kann man sich fast schon bildlich vorstellen, wie diese Person vor dem Rechner sitzt und dass benutzt, was wir gerade entwickeln.

Personas haben außerdem den Vorteil, dass sie nicht so beliebig sind, wie eine soziodemografische Gruppe. Es ist einfacher, einer kleinen Handvoll Personas ein Feature schmackhaft zu machen, als einer großen unspezifischen Gruppe. So verzettelt man sich weniger in einer beliebigen breiten und uninteressanten Ausgestaltung von Features.

Nachteile von Personas

Vielleicht fragt ihr euch: Wenn Personas so toll sind, warum nutzen nicht alle überall Personas?

Bei all diesen Vorteilen sollte man den einen großen Nachteil bedenken: Die Persona ist eine fiktive Einzelperson, die i.d.R. auf wenigen spezifischen Daten beruht – wenn überhaupt. Es sollte euch daher bewusst sein, dass es keine klaren direkten Bezug zu echten Kundendaten gibt und sie daher in Bereichen, wo es dieser Kundendaten bedarf, mit Vorsicht anzuwenden sind. Beispielsweise sollte bei wissenschaftlichen Analysen keine Persona als Ausgangspunkt angenommen werden.

Personas sind teil eines agilen Prozesses. D.h. Personas und deren Ergebnisse sollten iterativ und in kurzen Zeiträumen angewendet und dann geprüft und hinterfragt werden. Wendet nicht Personas als absolute Wahrheit an!

Beginnen wir mit der Erstellung einer Persona, indem wir sie zunächst klassifizieren.
Mehr dazu im nächsten Beitrag dieser Serie!

Andreas Poschen ist ein Spezialist für Konzeption, E-Commerce, UX und Digital Marketing aus Aachen. Er arbeitet als Product Owner Smart Home für Web, iOS und Android bei einem IT-Mittelständler und schreibt in diesem Blog über seine Arbeit als PO und seine Gedanken. Folgt ihm gerne auf:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.