Management-Zusammenfassung dieses Beitrags:
Personas beschreiben Nutzer (potenzieller Produkte) und können bei der Entwicklung von Anforderungen eingesetzt werden.
Es wird in diesem Beitrag Personas und deren Einsatz dargestellt.
Personas sind ein etabliertes Konzept im → Agilen Requirements Engineering und helfen Anforderungen auf Basis “fiktiver Nutzer” zu erstellen. Sie unterstützen damit die Erstellung von → Use Cases (im klassischen Fall) und → User Stories (in der agilen Welt). Ursprünglich sind Personas Ende der 1990er Jahre von Alan Cooper /Cooper04/ entwickelt worden, um gezielt Anforderungen von Nutzern in die Entwicklung von Benutzeroberflächen (für PC-Software) einzubringen. Inzwischen werden Personas aber in verschiedenen Kontexten eingesetzt, da sie vergleichsweise schnell zu erstellen und einfach zu verstehen sind.
Personas sind inzwischen auch ein Bestandteil im → Requirements Engineering.
1. Einleitung und Grundlagen
Personas beschreiben Nutzer (potenzieller Produkte) und können bei der Entwicklung von Anforderungen eingesetzt werden. Aus (möglichen) Kunden- oder Zielgruppen werden hierbei einzelne, “fiktive” Nutzer mit konkreten Eigenschaften abgeleitet – diese Nutzer werden dann als Personas bezeichnet.
Besonders populär sind Personas in agilen Umfeldern: Sie helfen dort, die “richtigen” User Stories zu finden. Generell unterstützen damit Personas die Entwicklung von Produkten oder → Dienstleistungen.
Die Einsatzmöglichkeiten von Personas sind vielfältig – richtig eingesetzt können sie schnell zur Verdeutlichung von Sachverhalten beitragen. In dieser Ausarbeitung wird eine kurze Übersicht zu den Personas geliefert.
1.1 Definitionen
In der Wikipedia steht zur Persona /#Wiki-Personas/:
“Die Persona stellt einen → Prototyp für eine Gruppe von Nutzern dar, mit konkret ausgeprägten Eigenschaften und einem konkreten Nutzungsverhalten.”
In diesem Beitrag werden Personas in folgender Definition verwendet:
“Personas sind fiktive Nutzer, die über konkrete Eigenschaften beschrieben werden und Kundengruppen repräsentieren. Das Nutzungsverhalten wird ebenfalls erfasst, sodass sich ein umfassendes Bild ergibt.”
1.2 Zur Schreib- und Sprechweise
Laut Duden /Duden-Persona/ gilt für die Schreibweise:
“Grammatik: die Persona; Genitiv: der Persona, Plural: die Personae”.
Richtig wäre nach Duden von „der Persona“ und „den Personae“ zu sprechen. In diesem Beitrag wird jedoch abweichend von der Vorgabe des Dudens verwendet:
“Grammatik: die Persona; Genitiv: der Persona, Plural: die Personas”.
Bevorzugt wird hier der Plural benutzt und somit von “Personas” gesprochen.
1.3 Personas in verschiedenen Disziplinen
Personas kommen in verschiedenen Disziplinen zum Einsatz: Hier sind in erster Linie das Online-Marketing, das klassische → Requirements Engineering (RE, auch → Business Analysis – BA) und das Agile Requirements Engineering (ARE) zu nennen. Die Unterschiede bei der Verwendung in den einzelnen Disziplinen sind nur gering.
Abbildung 1.1: Personas in verschiedenen Disziplinen
1.4 Einordnung und Abgrenzung: Rollen – Personas – Stakeholder
Generell muss zwischen Rollen, Personas und Stakeholdern unterschieden werden: Rollen charakterisieren Funktionen oder Aufgaben und werden abstrakt definiert. Personas sind zwar fiktiv, benennen aber konkrete Eigenschaften. → Stakeholder werden allgemeiner gefasst und benennen Gruppen von Betroffenen, zu denen dann auch immer die (potenziellen) Nutzer gehören.
2. Von den Stakeholdern zu den Personas
In Projekten und auch in Requirements-→ Vorhaben werden häufig Stakeholder erfasst und beschrieben – dies sind Gruppen von Betroffenen (des Projekts oder Vorhabens). Um von den Stakeholdern zu Personas zu gelangen, können die erfassten Stakeholder auf die Nutzer des zu erstellenden Produkts (oder der Dienstleistung) eingeschränkt werden: Es entstehen so die Nutzergruppen, die dann häufig auch geclustert werden.
Aus den Nutzergruppen werden die relevantesten herausgenommen und für diese die Personas erstellt. Durch diese Reduzierung auf Personas wird das zu entwickelnde Produkt (Abbildung 2.1) ebenfalls eingeschränkt.
Abbildung 2.1: Von den Stakeholdern zu den Personas
Es können bei Personas eine Reihe von Eigenschaften oder Merkmalen erfasst werden – hierzu gehören (Abbildung 2.2):
- Name
- Alter
- Motto oder Zitat
- Beruf
- Einkommen
- Wohnort
- Wohnsituation
- Hobbys
- Bezug zum Produkt
- …
Abbildung 2.2: Personas-Attribute über ein Mindmap
Eine einfache, universelle Schablone mit vier Feldern zur Strukturierung der Persona-Daten ist in Abbildung 2.3 dargestellt. Diese Vier-Quadranten-→ Matrix nach Gothelf /Gothelf15/ weist sehr stark auf das zu entwickelnde Produkt hin, denn zwei der vier Felder beschäftigen sich mit Anforderungen an das Produkt.
Abbildung 2.3: Erfassung von Personas über eine Vorlage
Zur besseren Unterscheidung und Nachverfolgung bieten sich jedoch detailliertere Schablonen an (siehe Abbildung 2.4), die für das jeweilige Szenario erstellt oder angepasst werden müssen.
Abbildung 2.4: Erfassung von Personas über eine Schablone
3. Beispiele von Personas
Hier werden einige Beispiele von Personas vorgestellt, die die gleiche Schablone verwenden. Folgendes Szenario wird angenommen:
Es soll eine Kaffeemaschine (Kaffeevollautomat) entwickelt werden, die sich an Privatpersonen richtet und die “besonders einfach zu bedienen ist”.
Als Hauptkundengruppen wurden identifiziert:
- Nichtkaffeetrinker (aber Maschinenmitnutzer)
- Gelegenheitskaffeetrinker
- Vielkaffeetrinker
Pro Kundengruppe sollte mindestens ein Repräsentant abgebildet sein.
Abbildung 3.1: Persona-Beispiel: Rainer Ruhe
Abbildung 3.2: Persona-Beispiel: Meggie Ruhe
Abbildung 3.3: Persona-Beispiel: Silvie Ruhe
Abbildung 3.4: Persona-Beispiel: Sigi Schnell
In der Persona-Übersicht können alle Personas mit ihren wesentlichen Eigenschaften gegenübergestellt werden (Abbildung 3.5).
Abbildung 3.5: Persona-Beispiel: Übersicht in Tabellenform
4. Ergänzung und Weiterverwendung von Personas
Personas können ergänzt oder weiterverwendet werden. Hier werden einige Möglichkeiten aufgeführt.
4.1 “Was ist in deiner Reisetasche” oder “Ein Tag in deinem Leben”
Um Personas “lebendiger” zu gestalten, können zwei Ansätze ergänzend verwendet werden:
- “Was ist in deiner Reisetasche” (“What is in your bag”): Hierzu wird der Inhalt einer Reisetasche der Persona ausgebreitet, abfotografiert und die einzelnen Inhaltsteile werden beschrieben. Die Form ist dabei: “Das Buch nehme ich mit, weil …”, “Die Nackenstütze habe ich eingepackt, damit …”
- “Ein Tag in deinem Leben” (“A day in your life”): Hierzu wird ein (typischer) Tagesablauf der Persona als Geschichte erstellt und in “spannender Form” (mit Elementen aus dem Storytelling) wiedergegeben
Aus beiden Ansätzen lässt sich ein genaueres Bild von der Persona gewinnen und somit die → Motivation ableiten.
4.2 Die Customer Journey
Die Customer Journey (Map) beschreibt den Weg des potenziellen Nutzers „virtuell“ als eine Reise durch das zu entwickelnde Produkt. Personas können hier helfen, die einzelnen Wegstücke zu beschreiben.
4.3 User Stories
Sind die Personas erstellt, so können hieraus einfach User Stories gewonnen werden, denn der Bezug kann unmittelbar hergestellt werden: Aus …
- dem Beruf oder der Repräsentantengruppe kann der User abgeleitet werden und
- aus dem Profil in Verbindung mit dem Bezug zum Produkt ergeben sich Anforderungen.
Aus den vorgestellten Beispiel-Personas könnten sich folgende User Stories ergeben:
- Als Nichtkaffeetrinker möchte ich innerhalb von 2 Minuten geschäumte Milch aus der Maschine erhalten
- Als Wartungsverantwortlicher möchte ich mit weniger als 10 Tastendrücken das Wartungsprogramm der Maschine durchführen
Sind die Personas noch auf einer Ebene, die zu “grob granular” ist, so kann mit → User Story Mapping und Epics gearbeitet werden.
4.4 Use Cases
Aus den Personas können auch Use Cases abgeleitet werden. Hieraus können dann wiederum Klassen- und Aktivitätsdiagramme sowie Glossarareinträge abgeleitet werden.
4.5 Empathy Maps
Möchte man auf die Gefühle und Wünsche einer Person eingehen, so können Empathy Maps zum Einsatz kommen. Dabei werden in der Regel entsprechende, vorgefertigte → Vorlagen / Schablonen eingesetzt (Abbildung 4.1).
Abbildung 4.1: Die Empathy Map (Vorlage)
5. Weitere Aspekte von Personas
5.1 Der Aufwand zur Entwicklung von Personas
Das Entwickeln von Personas ist – insofern man sich nicht auf Proto-Personas beschränken kann – aufwendig. Pro → Zielgruppe sollen etwa 4–6 Personas erstellt werden, der → Aufwand pro Persona beträgt etwa 8–12 Stunden. Damit ergibt sich bei nur drei Zielgruppen bereits ein Aufwand von etwa 120 Stunden allein für den Ersteller, ohne dass der Aufwand für die Interviewten eingerechnet wäre (Abbildung 5.1).
Abbildung 5.1: Eine Aufwandsabschätzung für Personas
5.2 Arten von Personas
Es gibt eine Reihe von Arten von Personas, die einzelne Aspekte besonders herausstellen. Hier sind einige davon aufgeführt.
5.2.1 Primary- und Secondary-Personas
Es wird generell zwischen Primary- und Secondary-Personas unterschieden. Über Primary-Personas wird die Hauptzielgruppe erfasst – dies muss immer erfolgen, denn die Hauptzielgruppe sollte im Blick behalten werden. Die Secondary-Personas sind insbesondere dann interessant, wenn ein weiteres Kundenpotenzial erschlossen werden soll.
Abbildung 5.2: Primary- und Secondary-Personas
5.2.2 B2C- und B2B-Personas
Aus der Unterscheidung, ob Personas für den B2C- (Privatkunden) oder B2B-Bereich (Geschäftskunden) entwickelt werden, ergeben sich unmittelbar Änderungen bei der Merkmalserfassung (in der Schablone):
So ist es beispielsweise für den Privatbereich eher uninteressant, wie lange eine Persona in einer Firma ist, während es für den Geschäftsbereich wichtig sein kann.
Abbildung 5.3: B2C- und B2B-Personas
5.2.3 Buyer-Personas
In den letzten Jahren ist der Begriff Buyer-Personas häufiger in der Literatur zu finden. Generell sind alle Personas, die sich mit dem Einkauf von Dingen beschäftigen Buyer-Personas – somit sind Personas fast immer auch Buyer-Personas. Eine Unterscheidung in die drei Gruppen Buyer (Einkäufer), Influencer (Beeinflusser) und Decider (Entscheider) ist im B2B-Bereich wesentlich und sollte entsprechend (in der Schablone) berücksichtigt werden.
Abbildung 5.4: Buyer-Personas
5.2.4 Ist- und Soll-Personas
Personas bilden im Wesentlichen den Ist-Stand ab. Für die Produktentwicklung ist es jedoch wichtig, auch Merkmale zu erfassen, die in die Zukunft gerichtet sind – es entstehen Soll-Merkmale und Soll-Personas. Die Unterscheidung von Ist- und Soll-Merkmalen sollte deutlich (bei der Erfassung) vermerkt werden.
Abbildung 5.5: Ist- und Soll-Personas
5.2.5 Positiv- und Negativ-Personas
Möchte man bestimmte Kundengruppen nicht mehr bedienen, so sollte man diesen Umstand auch in Personas erfassen. So kann es beispielsweise hilfreich sein, den Verkaufsprozess so umzugestalten, dass es für nicht-erwünschte Kundengruppen nicht mehr attraktiv ist, den Verkaufsraum zu betreten.
Abbildung 5.6: Positiv- und Negativ-Personas
6. Stärken und Schwächen von Personas
Das Konzept der Personas hilft bei der Ermittlung und Verfeinerung von Anforderungen. Aufgrund der Einfachheit und Verständlichkeit “für jedermann” kommen Personas gerne in verschiedenen Kontexten zum Einsatz. Die Stärken und Schwächen des Einsatzes von Personas sind hier aufgeführt.
Stärken:
- In der Grundfassung können Personas schnell erstellt werden
- Bei Verwendung von Schablonen wird ein einheitliches, für jedermann gut verständliches Bild der Kunden- und Nutzergruppen erzeugt
- Personas fördern die Kommunikation zwischen Beteiligten, insbesondere dort, wo die Gruppen sehr heterogen sind
- Personas sind in vielen unterschiedlichen Bereichen einsetzbar
- Der Bezug zum → Minimum Viable Product (→ MVP – Produkt, welches minimale Anforderungen umsetzt, aber schon Nutzen erbringt) wird schnell erkennbar
Schwächen:
- Bei sehr vielen Personas kann die Übersicht verloren gehen
- Der Aufwand zur Ermittlung “genauer” Personas über Marktanalysen und Befragungen kann sehr groß und damit aufwendig / teuer werden
- Es besteht die Gefahr, dass “falsche Personas” herangezogen werden
- Personas reichen als alleiniges Mittel zur Anforderungsbestimmung nicht aus, sie sind als Ergänzung zu sehen
- Es besteht die Gefahr, dass “Fake-Personas” (bei schneller Erstellung) verwendet werden, die nur in geringem Maße die Realität widerspiegeln
7. Häufig gestellte Fragen und Antworten (FAQ) zu den Personas
Einige Fragen zu den Personas werden häufig gestellt – diese werden hier wiedergegeben.
- F: Fallen Lizenzgebühren für die Nutzung von Personas an?
A: Nein, die Nutzung der Personas erfolgt ohne Lizenzgebühren. - F: Wie starte ich mit Personas?
A: Es ist sinnvoll, sich aus der Stakeholderliste die “wichtigsten” Stakeholder herauszusuchen und aus diesen dann Personas abzuleiten.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
Die Personas werden in meiner Präsentation (zu den Personas) beschrieben.
| Inhalt | Typ |
|---|---|
| Agilität: Personas – Eine Übersicht | 
|
Diese Bücher beschreiben Personas oder deren Verwendung im Requirements-Kontext:
- /Adlin10/ Tamara Adlin, John Pruitt: The Essential Persona Lifecycle: Your Guide to Building and Using Personas, Morgan Kaufmann, San Francisco 2010, ISBN 978–0‑12–381418‑0
- /BBG15/ → IIBA: A Guide to the Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, Marietta, Georgia 3rd Edition 2015, ISBN 978–1‑927584–02‑6
- /BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
- /Cooper04/ Alan Cooper. The Inmates Are Running the Asylum, Sams Publishing, Indianapolis, Indiana 2nd Edition 2004, ISBN 978–0‑672–32614‑1
- /Gothelf13/ Jeff Gothelf: → Lean → UX. Applying Lean Principles to Improve User Experience, O’Reilly Media, Sebastopol, California, ISBN 978–1‑4493–1165‑0
- /Gothelf15/ Jeff Gothelf: Lean UX: Mit der Lean-Methode zu besserer User Experience, mitp, Frechen 2015, ISBN 978–3‑95845–159‑9
- /Häusel18/ Hans-Georg Häusel, Harald Henzler: Buyer Personas: Wie man seine Zielgruppen erkennt und begeistert, Haufe-Lexware, Freiburg 2018, ISBN 978–3‑648–10392‑0
- /IREB21/ siehe /Pohl21/
- /Nielsen12/ Lene Nielsen: Personas – User Focused Design, Springer, London 2012, ISBN 978–1‑4471–4083‑2
- /Nielsen19/ Lene Nielsen: Personas – User Focused Design, Springer, London 2nd Edition 2019, ISBN 978–1‑4471–7426‑4
- /PMG-BA17/ Project Management Institute: The → PMI Guide to Business Analysis, Project Management Institute, Philadelphia, Pennsylvania 2017, ISBN 978–1‑62825–198‑2
- /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach → IREB-→ Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
- /Pruitt05/ John Pruitt, Tamara Adlin: The Persona Lifecycle: A Field Guide for Interaction Designers. Keeping People in Mind Throughout Product Design, Morgan Kaufmann, San Francisco 2005, ISBN 978–0‑12–566251‑2
- /Steimle18/ Toni Steimle, Dieter Wallach: Collaborative UX Design. Lean UX und → Design Thinking: Teambasierte Entwicklung menschzentrierter Produkte, dpunkt, Heidelberg 2018, ISBN 978–3‑86490–532‑2
Folgende Weblinks liefern weitere Informationen zu Personas:
- /#Adamicus-Buyer-Personas/ Adamicus: Buyer Personas – Fünf typische Fehler (deutsch)
- /*Nielsen12/ Website von Lene Nielsen /Nielsen12/ (englisch, dänisch) mit dem “10-Steps-to-Personas”-→ Poster
- /#Wiki-Personas/ Persona in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 02.05.2021 © Peterjohann Consulting, 2005–2024
