Personas (User Personas)
Die Muster aus der Forschung in wenige Menschen verwandeln, die sich das ganze Team vorstellen und für die es gestalten kann.
- Zeit
- 45 Min.
- Personen
- 3–6
- Art der Arbeit
- Rahmen
Kurz gesagt
Eine Persona ist ein kurzes, realistisches Profil eines Personentyps, für den ein Service da ist, gebaut aus Mustern in der Forschung statt aus der Vorstellung. Dafür die Ergebnisse aus Interviews und Daten sammeln, die Verhaltensweisen und Bedürfnisse finden, die gemeinsam wiederkehren, jedem Cluster einen Namen und ein Ziel geben und jedes Detail mit einem Beleg verknüpfen.
Worum es geht
Eine Persona beschreibt eine Gruppe von Menschen mit gemeinsamen Zielen, Verhaltensweisen und Problemen so, als wäre sie eine einzige Person. So kann ein Team darüber sprechen, „was Haya hier bräuchte“, statt über „den Nutzer“. Eine nützliche Persona enthält, was die Person erreichen will, wie sie heute vorgeht, was ihr im Weg steht, in welchem Kontext sie handelt, und einige Worte, die sie tatsächlich benutzt hat. Sie ist eine Zusammenfassung der Forschung in einer Form, die sich leicht merken und gut diskutieren lässt.
Personas sind im Service- und Produktdesign weit verbreitet, und Teams im öffentlichen Sektor, darunter UK Policy Lab in seinem Open Policy Making Toolkit, nutzen sie, um die Menschen im Blick zu behalten, die eine Maßnahme oder ein Service betrifft. Ihr Wert hängt vollständig von den Belegen dahinter ab. Eine in einem Meeting erfundene Persona, gebaut vor allem aus Alter, Geschlecht und Berufsbezeichnung, gibt einem Team falsche Sicherheit und wiederholt oft nur die bestehenden Annahmen. Eine in der Forschung verankerte Persona, geordnet nach Verhalten und Bedürfnissen, bewirkt das Gegenteil: Mit ihr kann das Team seine Entscheidungen an Menschen prüfen, die es wirklich gibt.
Wann sie passt
Geeignet, wenn
- Wenn eine Runde Interviews oder Beobachtungen abgeschlossen ist und eine gemeinsame Sprache für die verschiedenen Menschen gebraucht wird, denen das Team begegnet ist.
- Wenn ein Team immer wieder für einen gedachten Durchschnittsnutzer gestaltet, den es nicht gibt.
- Wenn verschiedene Gruppen denselben Service sehr unterschiedlich nutzen und entschieden werden muss, für wen zuerst gestaltet wird.
- Wenn neue Teammitglieder, Dienstleister oder die Leitung eingewiesen werden und die Nutzenden schnell verstehen sollen.
- Wenn eine Checkliste für Designprüfungen gebraucht wird: Könnte jede Persona das hier abschließen?
Ungeeignet, wenn
- Wenn noch keine Forschung vorliegt. Zuerst Interviews führen oder Daten sammeln, statt Personas aus Meinungen zu schreiben.
- Wenn ein bestimmter Moment im Detail verstanden werden soll. Eine Empathy Map oder Experience Map ist dann genauer.
- Wenn die Entscheidung von Zahlen abhängt, etwa wie viele Menschen betroffen sind. Personas beschreiben Typen von Menschen, nicht ihre Anteile.
Was es braucht
- Zeit
- Etwa 45 Minuten für eine oder zwei Personas, sobald die Forschung ausgewertet ist, dazu vorab Zeit, um die Ergebnisse zu gruppieren.
- Personen
- 3 bis 6 Personen, darunter diejenigen, die die Forschung durchgeführt haben, und mindestens eine Person, die direkt mit Nutzenden des Service arbeitet.
- Material
- Interviewnotizen, Affinitätscluster oder Empathy Maps, vorhandene Servicedaten wie Mengen oder Kanalnutzung, das Persona-Arbeitsblatt und Haftnotizen.
So läuft es ab
Schritt 1: Die Belege sammeln
Jede verfügbare Quelle mitbringen: Interviewnotizen, Beobachtungen, Empathy Maps, Anrufgründe aus dem Callcenter, Beschwerdethemen und Kanaldaten. Alles so auslegen, dass die ganze Gruppe es sieht. Vereinbaren, dass jede Zeile der fertigen Persona auf etwas in diesem Stapel zurückverweisen muss.
Schritt 2: Die Verhaltensunterschiede finden
Auflisten, worin sich die Menschen, denen das Team begegnet ist, in ihrem Tun und ihren Bedürfnissen unterschieden, etwa „erledigt alles online“ gegenüber „verlässt sich auf ein Familienmitglied“ oder „plant Wochen im Voraus“ gegenüber „handelt zur Frist“. Jeden Unterschied als Skala zwischen zwei Polen notieren. Verhalten und Bedürfnisse zählen hier mehr als Alter oder Beruf, denn sie verändern das Design.
Schritt 3: Menschen auf den Skalen platzieren
Für jede Person aus der Forschung grob markieren, wo sie auf jeder Skala steht. Dann nach Menschen suchen, die auf mehreren Skalen gleichzeitig beieinanderliegen. Jeder wiederkehrende Cluster ist eine mögliche Persona. Die meisten Services landen bei drei bis fünf; sind es mehr als sechs, lassen sich einige vermutlich zusammenlegen.
Schritt 4: Ziel und Frustrationen schreiben
Für jeden Cluster das Hauptziel in den Worten der Person notieren, wie sie heute vorgeht und die zwei oder drei Frustrationen, die am häufigsten auftauchen. Wo möglich Zitate aus der Forschung verwenden. Beim Service bleiben, an dem gearbeitet wird, nicht beim ganzen Leben der Person.
Schritt 5: Kontext und Namen ergänzen
Nur den Kontext ergänzen, der beeinflusst, wie die Person den Service nutzt: Geräte, Sprache, wer ihr hilft, Zeitdruck, Barrierefreiheitsbedarf. Der Persona einen realistischen Namen und ein kurzes Etikett für ihr Verhalten geben, etwa „der Delegierende“ oder „die Last-Minute-Handelnde“. Ein Foto nur ergänzen, wenn es nicht zu Stereotypen verleitet; eine einfache Illustration funktioniert oft besser.
Schritt 6: Gegen die Belege prüfen
Jede Persona laut vorlesen und diejenigen fragen, die die Forschung durchgeführt haben: Sind wir solchen Menschen begegnet? Ist hier etwas geraten? Vermutungen deutlich markieren oder entfernen. Notieren, auf wie vielen Forschungsteilnehmenden jede Persona beruht, damit Lesende wissen, wie belastbar sie ist.
Schritt 7: Die primäre Persona wählen
Vereinbaren, für welche Persona die nächste Arbeit zuerst gestaltet wird, und warum. Meist ist es die Gruppe, deren Bedürfnisse am schwersten zu erfüllen sind oder die den Service am meisten nutzt. Die Entscheidung auf dem Arbeitsblatt festhalten, damit spätere Designprüfungen daran gemessen werden können.
Praxisbeispiel
Eine nationale Rentenbehörde zahlt rund 640.000 Rentnerinnen und Rentnern ihre Bezüge und bearbeitet etwa 9.000 Anrufe am Tag. Ein neuer digitaler Service, um Bankverbindung und Angehörige zu aktualisieren, hatte eine Abschlussquote von 31 %, und die Leitung wollte wissen, wen er im Stich ließ. Das Forschungsteam hatte 22 Rentnerinnen, Rentner und Angehörige interviewt und einen Monat Anrufgründe ausgewertet.
Fünf Personen trafen sich für 50 Minuten: zwei Forschende, eine Teamleiterin aus dem Callcenter, ein digitaler Produktmanager und eine Referentin für Grundsatzfragen. Sie begannen mit den Affinitätsclustern, die schon an der Wand hingen.
Sie zeichneten vier Skalen: erledigt es selbst oder über jemand anderen; online sicher oder zuerst am Telefon; plant voraus oder handelt erst, wenn eine Zahlung ausbleibt; eine Rente oder mehrere Einkommensquellen.
Die Platzierung der 22 Teilnehmenden ergab drei klare Cluster. Der größte waren Rentner, die ihre Angelegenheiten über ein erwachsenes Kind regeln, das sich in ihrem Namen anmeldet. Er stützte sich auf neun Interviews und deckte sich mit dem häufigsten Anrufgrund: „Ich rufe für meinen Vater an.“
Das Team nannte diese Persona Abu Khalid, „der Delegierende“, mit seiner Tochter als der Person, die den Service tatsächlich nutzt. Sein Ziel: „dass meine Rente weiter ankommt, ohne jemandem zur Last zu fallen“. Die wichtigsten Frustrationen waren, dass der Service seine Tochter nicht für ihn handeln ließ und dass Briefe nur an seine alte Adresse gingen.
Ein vorgeschlagenes Detail, dass Delegierende überwiegend über 75 seien, wurde gestrichen, weil das nur auf vier der neun zutraf. An seine Stelle trat das Verhalten, das zählte: „hat sich im vergangenen Jahr nicht selbst angemeldet“.
Das Team wählte den Delegierenden als primäre Persona für das nächste Release, und die erste Designfrage lautete, wie ein Familienmitglied berechtigt werden kann, Angaben im Namen eines anderen zu aktualisieren.
Zur VeranschaulichungTipps und typische Fehler
Tipps
- Mit Zielen und Verhalten beginnen. Alter und Beruf, falls überhaupt, ans Ende setzen.
- Jede Persona auf eine Seite begrenzen. Kann sich nach einem Meeting niemand an sie erinnern, ist sie zu lang.
- Notieren, auf wie vielen Forschungsteilnehmenden jede Persona beruht, damit ihre Belastbarkeit sichtbar ist.
- Personas bei neuer Forschung überarbeiten. Eine Persona, die sich nie ändert, passt irgendwann nicht mehr zu den Menschen, die sie beschreibt.
Typische Fehler
- Personas im Workshop aus den Überzeugungen des Teams erfinden und sie dann als Forschung behandeln.
- Personas um demografische Merkmale bauen, sodass zwei Menschen mit gleichem Alter und Beruf, aber gegensätzlichem Verhalten in einem Profil landen.
- So viele Personas erstellen, dass das Team sie nicht mehr im Kopf behalten oder zwischen ihnen wählen kann.
- Einen idealisierten Nutzer beschreiben, der schon alles tut, was der Service sich erhofft, und damit die Menschen verdecken, an denen er scheitert.
Was am Ende vorliegt
Am Ende stehen drei bis fünf einseitige, forschungsbasierte Personas, jede mit Ziel, heutigem Verhalten, Frustrationen, relevantem Kontext, Zitaten und einem Hinweis auf die Belege dahinter, dazu eine vereinbarte primäre Persona für die nächste Arbeit. Als Nächstes diese Persona durch den Service begleiten. Eine Experience Map zeigt, wo sie sich schwertut, und Wie-könnten-wir-Fragen machen aus ihren Frustrationen Herausforderungen für das Team.
Häufige Fragen
Wie viele Personas sollte ein Service haben?
Meist drei bis fünf. Weniger können wichtige Unterschiede verdecken; mit mehr als sechs kann ein Team kaum arbeiten. Für jede Arbeit eine als primäre Persona wählen.
Was ist der Unterschied zwischen Persona und Empathy Map?
Eine Empathy Map hält fest, was eine Person oder ein Personentyp sagt, denkt, tut und fühlt, oft direkt nach einem Interview. Eine Persona ist breiter und langlebiger: Sie verbindet viele Interviews zu einem Profil eines wiederkehrenden Nutzertyps.
Können wir Personas ohne Forschung erstellen?
Es lassen sich Entwürfe davon schreiben, wer die Nutzenden vermutlich sind, aber sie sollten klar als zu testende Annahmen gekennzeichnet sein. Für Designentscheidungen taugen sie erst, wenn Forschung sie bestätigt oder ersetzt.
Werkzeugkarte
Das Arbeitsblatt, das das Team ausfüllt, ein Kästchen pro Feld.
- Name und Etikett
- Ziel
- Wie sie es heute tun
- Frustrationen
- Relevanter Kontext
- In ihren Worten
- Belege dahinter