Tiremesù
DE
Kundenerlebnis und DesignAnleitung8 Min. Lesezeit

Personas, die Teams wirklich nutzen (und solche, die in der Schublade verstauben)

Personas erstellen, die genutzt werden: aus Forschung ableiten, über Ziele und Verhalten definieren, wenige halten und in echte Entscheidungen einbauen.

Tiremesù-Redaktion

Personas, die Teams wirklich nutzen (und solche, die in der Schublade verstauben)

Eine Persona wird genutzt, wenn sie auf Forschung beruht, über das definiert ist, was Menschen erreichen wollen, statt über Demografie, wenn sie klein genug ist, um sie sich zu merken, und wenn sie in die Entscheidungen eingebaut ist, die ein Team jede Woche trifft. Personas verstauben, wenn sie in einem Workshop erfunden, mit Stockfotos und Hobbys dekoriert und als fertiger Liefergegenstand übergeben werden. Die folgenden Schritte bauen die erste Sorte.

Warum die meisten Personas in der Schublade landen

Eine Persona ist eine kurze, konkrete Beschreibung eines Personentyps, für den Ihr Service gedacht ist: ihr Ziel, ihr Verhalten, was ihr im Weg steht. Bekannt gemacht hat die Idee Alan Cooper in The Inmates Are Running the Asylum (1999), als Mittel dagegen, dass Softwareteams für einen imaginären „User“ gestalten, der jeder sein könnte. Ihre Aufgabe ist es, ein Team über eine bestimmte Person streiten zu lassen statt über einen vagen Durchschnitt.

Die meisten Personas scheitern aus vorhersehbaren Gründen. Sie werden aus dem zusammengesetzt, was das Team ohnehin glaubt, und bestätigen damit Annahmen, statt sie infrage zu stellen. Sie beschreiben Alter, Berufsbezeichnung und Lieblingskaffee – nichts davon hilft bei der Entscheidung, was gebaut werden soll. Es gibt zu viele, also merkt sich niemand eine. Und sie werden von einem Researchteam oder einer Agentur geliefert und danach nie wieder erwähnt, weil in keinem Prozess die Frage vorkommt: „Für welche Persona ist das?“

Personas, die genutzt werden – Schritt für Schritt

1. Bei den Entscheidungen beginnen, die sie unterstützen sollen. Fragen Sie das Team, was es in den nächsten sechs Monaten entscheiden wird: was zuerst gebaut wird, in welchen Kanal investiert wird, wie das Onboarding formuliert wird. Personas existieren, um diese Entscheidungen leichter zu machen. Wenn Sie die Entscheidungen nicht benennen können, sind Sie noch nicht bereit für Personas.

2. Zuerst echte Evidenz sammeln. Interviewen Sie eine Mischung aus aktuellen, abgewanderten und potenziellen Kundinnen und Kunden, und beobachten Sie einige von ihnen dabei, wie sie den Service dort nutzen, wo sie es normalerweise tun. Zehn bis fünfzehn gute Interviews zeigen oft die wichtigsten Muster, eine feste Zahl gibt es aber nicht: Machen Sie weiter, bis neue Interviews nichts Neues mehr erzählen. Ergänzen Sie, was Sie schon haben, etwa Beschwerden, Gesprächsnotizen und Suchbegriffe. Der Schwesterartikel darüber, wie Sie Ihre Kundschaft wirklich verstehen, behandelt diese Forschung ausführlich.

3. Nach Unterschieden in Verhalten und Zielen suchen, nicht in Demografie. Legen Sie aus, was Sie gehört haben, und gruppieren Sie es danach, was Menschen erreichen wollten, wie sie vorgingen und was sie aufhielt. Ein Affinitätsdiagramm eignet sich hier gut. Sie suchen nach Clustern, die unterschiedliche Dinge von Ihnen bräuchten. Zwei Menschen sehr unterschiedlichen Alters, die beide „es in einem Termin erledigen und nie wieder daran denken“ wollen, gehören zusammen. Zwei Gleichaltrige, einer vorsichtig, einer in Eile, gehören nicht zusammen.

Das Canvas zum Affinitätsdiagramm
Das Canvas zum Affinitätsdiagramm

4. Das Set klein halten. Drei bis fünf Personas reichen für die meisten Services. Bestimmen Sie eine als primäre Persona: die Person, für die der Service zuerst funktionieren muss, denn wenn er für sie funktioniert, funktioniert er meist auch für andere. Wenn Sie acht haben, sind einige vermutlich Varianten desselben Ziels; führen Sie sie zusammen. Eine Persona, die niemand aus dem Gedächtnis benennen kann, erfüllt ihren Zweck nicht.

5. Jede auf einer einzigen Seite schreiben, in fester Reihenfolge. Verwenden Sie für alle dieselbe Struktur, damit sie sich vergleichen lassen:

  • ein kurzer Name und eine Zeile zu ihrer Situation;
  • das Ziel, in ihren eigenen Worten („Ich will einfach wissen, dass es angekommen ist“);
  • die Verhaltensweisen, die für Ihren Service zählen: wie sie Hilfe suchen, welche Kanäle sie nutzen, wie viel Aufwand sie hinnehmen;
  • was ihnen im Weg steht, mit einem echten Zitat;
  • was das für den Service bedeutet: zwei oder drei Folgerungen für das Design.

Lassen Sie Hobbys, Marken, Persönlichkeitstypen und alles andere weg, was Sie nicht in der Forschung gelernt haben und in keiner Entscheidung nutzen würden. Eine Illustration oder ein Foto hilft beim Erinnern, aber wählen Sie eines, das die Persona nicht auf ein Geschlecht, ein Alter oder eine Nationalität festlegt, die Sie nicht festlegen wollten.

6. Kennzeichnen, was Evidenz und was Annahme ist. Manchmal müssen Sie anfangen, bevor Forschung möglich ist. Das ist in Ordnung: Schreiben Sie „Annahme“-Personas, manchmal Proto-Personas genannt – ein Begriff, den Jeff Gothelfs Lean UX bekannt gemacht hat –, und kennzeichnen Sie sie deutlich. Dann testen Sie sie. Eine Persona, die ihre Annahmen versteckt, wird noch verteidigt, wenn die Evidenz längst weitergezogen ist.

7. In die Arbeit einbauen. An diesem Schritt entscheidet sich, ob Personas leben. Schreiben Sie User Stories und Problemformulierungen, die eine Persona benennen („Als Noor, die zum ersten Mal einen Antrag stellt …“, siehe User Stories und Point-of-View-Statement). Fragen Sie in jedem Design-Review: „Für welche Persona ist das, und was würde sie hier tun?“ Rekrutieren Sie Teilnehmende für Usability-Tests passend zu jeder Persona. Wenn ein Feature keiner Persona dient, fragen Sie, warum es gebaut wird.

Das Canvas zu User Stories
Das Canvas zu User Stories

8. Regelmäßig überprüfen. Legen Sie einen Termin fest, etwa einmal im Jahr oder wenn sich der Service deutlich ändert, um jede Persona mit neuer Forschung abzugleichen. Verabschieden Sie die, die zu niemandem mehr passen. Eine Persona ist ein Arbeitswerkzeug, kein Denkmal.

Was Sie tun und was Sie lassen sollten

Tun:

  • Personas aus Interviews und Beobachtung bauen und die Quellnotizen verknüpft halten.
  • Sie über Ziel, Verhalten und Hindernis definieren.
  • Eine primäre Persona benennen und zuerst für sie gestalten.
  • Für Ziel und Frustrationen die eigenen Worte der Persona verwenden.
  • Personas zum festen Bestandteil davon machen, wie Arbeit formuliert, geprüft und getestet wird.

Lassen:

  • Personas in einem halbtägigen Workshop erfinden und als Forschung präsentieren.
  • Die Seite mit demografischen Details füllen, die keine Entscheidung verändern.
  • Für den Lieblingskunden jeder Abteilung eine eigene Persona anlegen.
  • Personas mit Marktsegmenten verwechseln. Segmente helfen Marketing und Finanzen beim Dimensionieren und Ansprechen; Personas helfen einem Team beim Gestalten. Sie können sich überschneiden, beantworten aber unterschiedliche Fragen.
  • Personas nutzen, um echte Kundinnen und Kunden zu bewerten oder zu etikettieren. Sie beschreiben Muster, keine Menschen.

Beispiel zur Veranschaulichung

Zur Veranschaulichung. Das öffentliche Bibliothekssystem einer mittelgroßen kanadischen Stadt hatte sieben Personas, die eine Agentur drei Jahre zuvor erstellt hatte. Jede hatte ein Alter, ein Foto, eine Liste von Hobbys und ein Lieblingsgenre. Das Digitalteam gab zu, dass seit einem Jahr niemand die Datei geöffnet hatte.

Als die Bibliothek ein neues Buchungssystem für Lernräume und Geräte plante, fing das Team von vorn an. Über drei Wochen interviewte es vierzehn Mitglieder und Nichtmitglieder, verbrachte zwei Nachmittage damit, Menschen an der Ausleihtheke zu beobachten, und las ein Jahr Buchungsbeschwerden. Nach Zielen gruppiert, traten drei Muster hervor.

„Planerin“ buchte Wochen im Voraus für Lerngruppen, legte Wert auf Verlässlichkeit und wollte Erinnerungen. „Spontan“ kam vorbei, wollte, was gerade frei war, und gab auf, wenn es länger als eine Minute dauerte. „Helfer“ buchte für jemand anderen, meist einen älteren Angehörigen oder eine Gemeinschaftsgruppe, und musste mehrere Buchungen verwalten, ohne ein Passwort zu teilen. Das Alter sagte nicht voraus, zu welchem Muster jemand passte.

Das Team wählte „Spontan“ als primäre Persona, weil das bestehende System sie am stärksten im Stich ließ. Jede User Story für das neue System benannte eine der drei, und für Usability-Tests wurden pro Persona mindestens zwei Personen rekrutiert. „Helfer“ veränderte das Design am stärksten: Das Team ergänzte eine Möglichkeit, im Namen anderer zu buchen, auf die keine frühere Persona hingedeutet hatte. Die alten sieben Personas wurden mit einer Notiz archiviert, die erklärte, warum.

Häufige Fragen

Wie viele Personas sollte ich erstellen? In der Regel drei bis fünf, davon eine primäre. Weniger als drei können wichtige Unterschiede verdecken; mehr als fünf sind schwer zu merken und bedeuten oft, dass einige Varianten desselben Ziels sind.

Was ist der Unterschied zwischen einer Persona und einer Empathy Map? Eine Empathy Map hält fest, was eine Person oder Gruppe sagt, denkt, tut und fühlt, oft aus einer einzigen Forschungsrunde. Eine Persona ist eine gefestigtere Beschreibung eines wiederkehrenden Musters über viele Menschen hinweg. Empathy Maps sind ein guter Zwischenschritt auf dem Weg zu Personas.

Kann ich Personas ohne Nutzerforschung erstellen? Sie können Annahme-Personas erstellen, um ein Gespräch anzustoßen, solange Sie sie als Annahmen kennzeichnen und vorhaben, sie zu testen. Erfundene Personas als Forschung auszugeben ist der Weg, auf dem Teams am Ende selbstbewusst für Menschen gestalten, die es nicht gibt.

Wie es weitergeht

Der Leitfaden zu Personas gibt Ihnen das Canvas, Stakeholder-Interviews helfen beim Sammeln der Evidenz, und das Affinitätsdiagramm hilft, die Muster zu finden. Für die breitere Praxis, zu der diese Personas gehören, lesen Sie Kundenzentrierung ist eine Praxis, kein Slogan, und damit die Forschung dahinter auch etwas verändert, lesen Sie Von der Erkenntnis zur Veränderung: Kundenforschung in Entscheidungen übersetzen.