Was ist eine Persona und wie erstellt man sie?

Kurz gesagt

Eine Persona beschreibt ein Verhaltensmuster, das Sie in der Nutzerforschung sehen, so, als wäre es eine einzelne Person. Die Nielsen Norman Group (NN/g) definiert die Persona als „erfundene, aber realistische Beschreibung eines typischen oder Zielnutzers“.

Erfunden ist die Präsentation: Name, Foto, vielleicht ein Alter. Echt sein muss der Inhalt. Was die Person erledigen will und wo sie hängen bleibt, kommt aus der Forschung.

Nutzer-Persona, UX-Persona und Nutzerprofil werden oft gleichbedeutend verwendet. Auch Marketingteams schreiben Personas, aber mit einem anderen Ziel.

Kim Flaherty von NN/g erklärt das an einem Bankbeispiel. Die Marketing-Persona hilft, möglichen Kunden den Nutzen des Produkts zu vermitteln. Die UX-Persona lenkt das Interaktionsdesign; um diese geht es in diesem Ratgeber.

Wofür eine Persona taugt und wofür nicht

Eine Persona sorgt dafür, dass das Team beim Nutzer auf dasselbe Bild schaut. Der Satz „Der Nutzer will das“ lässt in jedem Kopf eine andere Person entstehen. Der Satz „Sabine kann das nicht, während Kundschaft vor ihr steht“ bindet die Diskussion an eine konkrete Lage.

Der Persona-Artikel von NN/g nennt weitere Aufgaben. Eine Persona bremst Design, das allen dienen will. Sie hilft bei Expertenprüfungen, bei der Auswahl von Testpersonen und dabei, Analytics-Daten in Segmente zu teilen.

Am häufigsten nutze ich sie bei der heuristischen Evaluation. Fange ich an, ohne zu fragen, mit wessen Augen ich auf einen Screen schaue, übertrage ich meine eigenen Gewohnheiten auf den Nutzer. Die Persona legt die Antwort auf diese Frage von Anfang an auf den Tisch.

Die Persona ist eines der praktischen Werkzeuge des nutzerzentrierten Designs. Sie trägt, was Sie in der Forschung gelernt haben, zu Teammitgliedern, die nicht dabei waren. So sprechen Entwicklung und Vertrieb von derselben Person.

Wofür sie nicht taugt

• Sie ersetzt keinen Nutzertest. Auch NN/g schreibt das ausdrücklich. Die Persona sagt, was Sie testen sollten; ob ein Screen funktioniert, zeigt nur ein Usability-Test.
• Sie sagt nicht, wie viele Ihrer Nutzer dieser Person ähneln. Eine Persona aus Interviews trägt keine Anteile. Wollen Sie das wissen, braucht es eine statistische Studie.
• Sie entscheidet nicht allein. Die Persona ist ein Bezugspunkt. Ob eine Funktion gebaut wird, entscheiden weiterhin Geschäftsziel und Daten.

Was in eine Persona gehört

Die Liste von NN/g ist lang: Name, Alter, Geschlecht und Foto, eine kurze Tagline, Beruf und Erfahrung mit dem Produkt. Dazu kommen Nutzungskontext, Verhalten, Ziele, Sorgen und ein Zitat, das die Haltung der Person zeigt.

Ich teile diese Liste in zwei Gruppen. Die erste ändert Designentscheidungen, die zweite macht die Persona leichter zu merken.

• Was Entscheidungen ändert: Kontext, Ziel, Hindernis, Verhalten, Erfahrung mit dem Produkt. Wer ein Produkt nutzen muss, erträgt einen schlechten Screen, hasst ihn aber.
• Was im Gedächtnis hilft: Name, Foto, Tagline, Zitat. Damit erinnert sich das Team an die Persona wie an eine Person. NN/g empfiehlt, die Tagline nicht zu witzig zu machen, sonst wirkt die Persona nicht wie ein ernsthaftes Werkzeug.

Der Nutzungskontext ist die am häufigsten übersprungene Zeile. NN/g öffnet ihn mit einigen Fragen: Wie oft und mit welchem Gerät wird das Produkt genutzt, freiwillig oder weil der Job es verlangt? Dieselbe Person ist am Schreibtisch im Büro eine andere Nutzerin als mit dem Handy im Bus.

Page Laubheimer von NN/g spricht in einem Artikel von 2022 auch vom Archetyp. Der Archetyp zeigt dieselbe Forschung ohne Namen und Foto, mit einem Etikett, das das Verhalten beschreibt. Statt eines Menschennamens etwa „stellt Rechnungen für mehrere Mandanten aus“.

Der Inhalt ist derselbe, nur die Präsentation ändert sich.

Arten von Personas

Laubheimer teilt Personas in einem anderen Artikel von 2020 in drei Arten. Sie unterscheiden sich in den Daten, auf denen sie beruhen, und im Aufwand, den sie brauchen.

Proto-Persona (leichte Persona)

Es wird keine neue Forschung gemacht. Das Team schreibt in einem Workshop auf, was es über Nutzer weiß oder vermutet.

Laut Laubheimer dauert der Workshop 2 bis 4 Stunden. Jede teilnehmende Person schreibt 2 bis 5 Entwürfe, die Gruppe fasst sie zu 3 bis 6 Personas zusammen.

Der Nutzen: Die stillen Annahmen des Teams werden sichtbar. Diese Annahmen werden zu Hypothesen, die später mit Forschung geprüft werden. Das Risiko nennt der Artikel ebenfalls klar: Proto-Personas liegen oft falsch und können zur Echokammer werden, die die falschen Annahmen des Teams zurückwirft.

Qualitative Persona

Sie beruht auf erkundender Forschung wie Interviews, Usability-Tests oder Feldforschung. Laubheimer empfiehlt Interviews mit 5 bis 30 Nutzern. Sie beginnen mit 5 Personen je Gruppe und machen weiter, bis neue Interviews kaum noch Neues bringen.

Die Interviewprotokolle werden in Themen geteilt, dann sucht man in den Themen nach Mustern, die sich decken. Der Artikel empfiehlt diese Art für die meisten Teams als beste Balance. Die Schwäche: Sie kann nicht sagen, wie viele Nutzer jede Persona vertritt.

Statistische Persona

Zuerst werden mit qualitativer Forschung Themen gefunden, dann folgt mit diesen Themen eine große Umfrage. Laubheimer verlangt mindestens 100, idealerweise 500 oder mehr Antworten. Die Antworten werden mit Clusterverfahren gruppiert.

So können Sie den Anteil jeder Persona an der Nutzerbasis messen. Der Artikel hält das Verfahren aber für teuer und zeitaufwendig. Außerdem ähneln die Ergebnisse den qualitativen Personas oft sehr.

Welche Sie wählen

Haben Sie gar keine Daten, können Sie mit einer Proto-Persona beginnen. Schreiben Sie nur „Annahme“ darauf und prüfen Sie sie bei der ersten Gelegenheit mit Interviews. Für die meisten Teams ist die qualitative Persona das richtige Ziel.

Die statistische Persona braucht eine große Nutzerbasis und jemanden, der Statistik beherrscht. Bestimmt die Frage „Welcher Anteil unserer Nutzer ist diese Gruppe?“ eine Investitionsentscheidung, sind die Kosten gerechtfertigt.

Eine Persona Schritt für Schritt erstellen

Die Schritte unten gelten für die qualitative Persona. Ein MVP-Team kann in derselben Reihenfolge vorgehen wie ein großes Unternehmen. Was sich ändert, ist die Zahl der Interviews.

1. Schreiben Sie den Umfang auf. Für welche Entscheidung braucht es die Persona? Eine Persona für alle Produkte einer Bank ist nicht dieselbe wie eine nur für den Screen zum Bezahlen von Rechnungen. Flaherty schreibt, dass eine Persona, die nicht zu Ziel und Umfang des Projekts passt, nichts nützt.

2. Sammeln Sie die vorhandenen Daten. Supportanfragen, Analytics, Notizen des Vertriebs, alte Testaufzeichnungen. Sie sagen Ihnen, was Sie im Interview fragen sollten. Um die Persona allein darauf zu bauen, reichen sie nicht.

3. Sprechen Sie mit Nutzern. Reden Sie mit Menschen, die das Produkt wirklich nutzen oder nutzen werden. Richten Sie Ihre Fragen nicht auf die Funktionen des Produkts, sondern auf die Arbeit der Person und darauf, wo sie dabei Mühe hat.

4. Teilen Sie die Notizen in Themen. Schreiben Sie die Beobachtungen aus jedem Interview auf eigene Karten. Gruppieren Sie dann ähnliche Karten: Ziele, Hindernisse, Kontext, genutzte Werkzeuge.

5. Finden Sie Muster. Menschen mit demselben Ziel, die an derselben Stelle hängen bleiben, bilden eine Gruppe. Demografische Angaben wie Alter oder Stadt sind nicht die Grundlage der Gruppierung. Auch Laubheimer schreibt, dass die Cluster nicht nach Demografie gebildet werden.

6. Schreiben Sie die Persona. Eine Seite je Gruppe. Beginnen Sie mit Kontext, Ziel, Hindernis und Verhalten. Name und Foto kommen ganz zum Schluss. NN/g empfiehlt, jedes Detail zu streichen, das keine Entscheidung beeinflusst.

7. Schreiben Sie die Quelle dazu. Fügen Sie unter der Persona an, auf welcher Forschung sie beruht. Wer diese Seite in einem Jahr öffnet, sollte wissen, worauf er sich verlassen kann.

8. Beziehen Sie das Team ein. Arbeiten Sie mit dem Team an einem Entwurf, bevor Sie die Persona präsentieren. Flaherty sieht eine Persona, die abseits des Teams entsteht, als größtes Hindernis.

Warnung vor der erfundenen Persona

Die Persona, die ich am häufigsten sehe, wurde in einem Meeting geschrieben und an die Wand gehängt, ohne dass mit jemandem gesprochen wurde. Darauf stehen ein schönes Foto, ein Zitat und eine Liste mit Hobbys. Nichts davon kommt aus der Forschung.

Eine solche Persona ist auch nicht harmlos. Sie sagt dem Team, was es ohnehin glaubt, als „So ist der Nutzer“ zurück. Sie wird wie ein Beweis benutzt, der die Diskussion beendet, dabei gibt es keinen Beweis.

Können Sie keine Forschung machen, schreiben Sie eine Proto-Persona und nennen Sie sie offen so. Es reicht, „Annahme, nicht bestätigt“ auf die Karte zu schreiben. Das eigentliche Problem ist, eine Proto-Persona als qualitative Persona auszugeben.

Ein Persona-Beispiel

Die Persona unten ist erfunden. Sie beruht auf keiner echten Forschung, ich habe sie nur geschrieben, um zu zeigen, wie man eine Persona schreibt. Das Produkt ist eine Web-App, mit der kleine Unternehmen E-Rechnungen ausstellen.

Erfundenes Beispiel

Jonas arbeitet in einem kleinen Steuerbüro

Kontext

Er stellt am Desktop-Rechner im Büro Rechnungen für mehrere Mandanten aus. Zum Monatsende stapelt sich die Arbeit, tagsüber wird er oft durch Telefonate unterbrochen.

Ziel

Die Rechnung jedes Mandanten mit den richtigen Firmendaten in einem Durchgang senden.

Hindernisse

Beim Wechsel zwischen Mandanten verliert er den Überblick, auf wessen Screen er gerade ist. Die Fehlermeldung sagt nicht, welches Feld falsch ist.

Verhalten

Vor dem Senden lädt er die Rechnung als PDF herunter und prüft sie. Weil er der App nicht ganz traut, führt er zusätzlich eine Tabelle.

Was er sagt

„Eine Rechnung an die falsche Firma ist wie eine Überweisung an die falsche Person. Das rückgängig zu machen, kostet mich einen Tag.“

Zugrunde liegende Forschung

Keine, erfundenes Beispiel. In einer echten Persona stünden hier Zahl und Datum der Interviews.

Wie Sie sehen, fehlen in dieser Persona Alter, Hobbys und Familienstand. Sie ändern keine Entscheidung auf dem Rechnungsscreen. Der eigentliche Designhinweis steckt in den Hindernissen: eine Überschrift, die ständig zeigt, bei welchem Mandanten man ist, und eine Fehlermeldung direkt am Feld.

Auch das Zitat ist kein Schmuck, es zeigt, wie Jonas die Kosten eines Fehlers abwägt. Das rechtfertigt einen Zusammenfassungsscreen vor dem Button „Senden“. Ob ein solcher Screen zum mentalen Modell des Nutzers passt, sehen Sie wieder im Test.

Würde ich diese Karte in einem echten Projekt nutzen, würde ich zuerst die Quelle ändern. Ich würde mit einigen Menschen sprechen, die in Steuerbüros arbeiten, und neben jedes Hindernis das Interview schreiben, aus dem es stammt. Eine Zeile, die in keinem Interview vorkam, würde ich von der Karte streichen.

Ausprobieren: Persona-Generator

Der Kern einer Persona sind vier Zeilen: wer, in welchem Kontext, was will die Person erledigen und wo bleibt sie hängen. Ich ergänze eine weitere Zeile: Woher stammen diese Angaben? Füllen Sie die Felder unten mit Ihren eigenen Forschungsnotizen.

Persona-Generator

Erfundenes Beispiel

Sabine, Inhaberin einer Apotheke im Viertel

Kontext

Am Tresen, auf dem Handy, oft bestellt sie, während Kundschaft vor ihr wartet.

Ziel

Ein ausverkauftes Medikament bestellen, bevor die Kundin die Apotheke verlässt, und ihr die Lieferzeit nennen.

Hindernis

Die Suche erkennt den abgekürzten Namen des Medikaments nicht. Um den Barcode zu scannen, muss sie die Packung aus dem Regal holen.

Zugrunde liegende Forschung

Erfundenes Beispiel. Es beruht auf keiner echten Forschung.

Das ist eine Beispielkarte. Mit JavaScript können Sie die Felder selbst ausfüllen und den Text kopieren.

Sabine ist eine erfundene Figur und stammt aus keiner echten Forschung. Ändern Sie die Felder, die Persona-Karte aktualisiert sich beim Schreiben. Ein leeres Feld wird auf der Karte als leer markiert. Der Button Text kopieren legt die Karte als einfachen Text in die Zwischenablage.

Sie können die Karte kopieren und in Ihr Teamdokument einfügen. Lassen Sie die Zeile „Zugrunde liegende Forschung“ bitte nicht leer. Ist sie leer, haben Sie eine Proto-Persona in der Hand.

Wie Sie die Persona nutzen

Eine Persona, die geschrieben und in einen Ordner gelegt wird, nützt nichts. Mit Flahertys Worten verstauben solche Personas auf einem geteilten Laufwerk. Es gibt einige Wege, die Persona in die tägliche Arbeit zu holen.

In der Designdiskussion. Kommt die Frage „Wer wird das nutzen?“, nutzen Sie den Namen der Persona. „Sieht Jonas auf diesem Screen, bei welchem Mandanten er ist?“ öffnet eine klarere Diskussion als das Wort „Nutzer“.

Bei der Auswahl von Testpersonen. NN/g empfiehlt, die Persona für die Auswahl von Testpersonen zu nutzen. Leiten Sie die Screening-Fragen aus Kontext und Erfahrung der Persona ab. Für Jonas suchen Sie jemanden, der Rechnungen für mehrere Mandanten ausstellt.

In der Expertenprüfung. Bei einem UX Audit gehe ich den Ablauf mit den Augen der Persona durch. Derselbe Screen kann für erfahrene Nutzer problemlos sein und für jemanden, der zum ersten Mal kommt, eine Sackgasse.

In Analytics. NN/g empfiehlt auch, Analytics-Daten nach Persona-Gruppen zu teilen. Entfernt sich das Verhalten einer Gruppe von der Persona, ist das laut Flaherty ein Signal, die Persona zu überprüfen.

Flaherty nennt weitere Signale. Dazu gehören, dass das Geschäft die Richtung ändert, eine neue Gruppe zur Nutzerbasis stößt und Testpersonen sich anders verhalten als die Persona. Kommen beim Support neue Arten von Fragen an, schauen Sie die Persona ebenfalls neu an.

Häufige Fehler

Die Persona ohne Forschung schreiben. Die erfundene Persona von oben. Die Annahmen des Teams verstecken sich hinter einem Foto.

Mit Demografie beginnen. „35 Jahre, weiblich, München“ ist ein Marketingsegment. Für das Design zählt, was die Person tun will und wo sie Mühe hat.

Unnötige Details hinzufügen. Lieblingsserie, Name des Hundes. NN/g schreibt, dass solche Details die wichtigen erdrücken.

Zu viele Personas schreiben. Entsteht in jedem Meeting eine neue Persona, wird keine genutzt. Bleiben Sie bei den Gruppen, die Designentscheidungen wirklich trennen.

Abseits des Teams erstellen. Laut Flahertys Artikel ist das das größte Hindernis dafür, dass Personas angenommen werden. Laut demselben Artikel kommen 90 % des Werts von Personas daher, sie zu haben und an sie zu glauben.

Nie aktualisieren. Produkt und Nutzer ändern sich. In Flahertys Umfrage von 2016 unter 156 UX-Fachleuten bewerteten diejenigen die Wirkung am höchsten, die ihre Personas vierteljährlich oder öfter aktualisierten.

Am Foto hängen bleiben. Laut Laubheimer kann ein Gesicht auf der Persona Nutzer stillschweigend ausschließen, die sich in diesem Gesicht nicht wiederfinden. Nutzen Sie ein Foto, machen Sie es nicht zur Grundlage von Designentscheidungen.

Meine Notiz

Öffne ich in der Arbeit mit Teams zum ersten Mal die Persona-Datei, schaue ich auf eine einzige Zeile: Woher stammt das? Meist gibt es keine Antwort. Dann lege ich die Persona beiseite und bitte das Team um die letzten fünf Supportanfragen.

Eine gute Persona ist kurz. Eine Persona, die nicht auf eine Seite passt, ist für mich eine, die niemand liest. Sind Ziel und Hindernis ausgefüllt und die Hobbyzeile leer, sind Sie auf dem richtigen Weg.

Die Persona ist auch eine Bremse dagegen, dass sich Designer für den Nutzer halten. Diese Neigung habe ich auch, und die Persona erinnert mich am Tisch daran.

Mein Rat an kleine Teams ist einfach. Beginnen Sie mit fünf Interviews, schreiben Sie eine einzige Persona und prüfen Sie sie im nächsten Test. Statt auf ein perfektes Set zu warten, arbeiten Sie mit einem Entwurf, dessen Fehler Sie schnell zeigen können.