Personas aus echten Daten: So baust du eine Persona, mit der dein Team wirklich arbeitet

Ein kleines Team betreibt einen Lieferdienst für regionale Gemüsekisten. In einem Workshop entsteht an einem Nachmittag die erste Persona: „Lisa, 34, arbeitet im Marketing, macht Yoga, kauft gern bio und liebt Avocado-Toast.“ Dazu kommt ein lächelndes Stockfoto aus einem Hofladen. Das Poster hängt danach monatelang im Büro. Eine einzige Produktentscheidung hat es in dieser Zeit nicht beeinflusst.

Parallel dazu landen im Support immer wieder ähnliche Nachrichten. Menschen kündigen, weil sie mit dem dritten Kohlrabi in Folge nichts anzufangen wissen. Andere ärgern sich, weil sie vor dem Urlaub vergessen haben, die Lieferung zu pausieren, und dann eine volle Kiste vor der Tür verdirbt. Mit Lisa und ihrem Avocado-Toast hat das alles nichts zu tun.

Das Beispiel zeigt ein typisches Muster: Die Persona war nicht falsch, weil Personas als Methode nicht funktionieren. Sie war wirkungslos, weil sie aus Vermutungen statt aus Daten gebaut wurde. Dieser Artikel zeigt dir Schritt für Schritt, wie du aus echten Daten eine brauchbare Persona entwickelst, welche Fehler du dir sparen kannst und wie sich Personas von der Methode Jobs to be Done unterscheiden.

Was eine Persona ist und was nicht

Eine Persona ist eine fiktive, aber auf Forschung beruhende Beschreibung einer Gruppe von Menschen, die dein Produkt ähnlich nutzen. Sie bekommt meist einen Namen und ein paar konkrete Details, damit das Team über eine greifbare Figur sprechen kann statt über „die Nutzenden“. Das Konzept geht auf Alan Cooper zurück und wurde mit dem Buch „The Inmates Are Running the Asylum“ von 1998 bekannt.

Wichtig für den Einstieg ist die Unterscheidung zwischen zwei Dingen, die oft durcheinandergehen:

• Zielgruppe oder Marketing-Persona: Beschreibt, wen ein Unternehmen erreichen will, oft über Alter, Einkommen, Wohnort oder Interessen. Das hilft beim Schalten von Anzeigen.
• Design-Persona: Beschreibt, wie Menschen sich verhalten, was sie erreichen wollen und woran sie scheitern. Das hilft bei Entscheidungen über Funktionen, Abläufe und Texte.

In diesem Artikel geht es um die zweite Sorte. Warum Personas im Team überhaupt helfen und wo ihre Grenzen liegen, steht ausführlich im Artikel Was sind UX Personas und warum braucht jedes Team sie?. Hier geht es um das Handwerk: Wie kommst du von Rohdaten zu einer Persona, mit der dein Team tatsächlich arbeitet?

Drei Arten von Personas

Die Nielsen Norman Group (NN/g), eine bekannte UX-Beratung und Forschungseinrichtung, unterscheidet drei Arten von Personas, je nachdem, wie viel Forschung dahintersteckt.

Proto-Personas

Proto-Personas entstehen in einem Workshop von zwei bis vier Stunden. Alle Beteiligten skizzieren aus ihrem Wissen ein paar Personas, danach führt die Gruppe sie zusammen. Neue Forschung gibt es dafür nicht. Das ist schnell und macht Annahmen im Team sichtbar. Der Haken: Proto-Personas sind oft ungenau und können falsche Annahmen verfestigen, statt sie zu hinterfragen. Die Lisa aus dem Einstiegsbeispiel ist eine Proto-Persona, die nie als solche gekennzeichnet wurde.

Qualitative Personas

Qualitative Personas beruhen auf Interviews, Beobachtungen oder Usability-Tests. Die NN/g beschreibt dafür einen Rahmen von etwa 5 bis 30 Interviews, geführt in Runden von rund fünf Gesprächen, bis kaum noch Neues auftaucht. Der Aufwand ist überschaubar, und das Ergebnis zeigt Motive und Bedürfnisse, die keine Statistik liefert. Was diese Personas nicht leisten: Sie sagen dir nicht, wie viel Prozent deiner Kundschaft zu welcher Persona gehören.

Statistische Personas

Statistische Personas bauen auf qualitativer Forschung auf und ergänzen sie um eine große Umfrage, deren Antworten mit statistischen Verfahren in Gruppen sortiert werden. Die NN/g nennt als Untergrenze mindestens 100, besser 500 oder mehr Antworten. Das ist aufwendig und braucht Statistikwissen. Für die meisten Teams ist es mehr, als nötig ist.

Die NN/g empfiehlt für die meisten Teams qualitative Personas. Genau darum geht es in der folgenden Anleitung. Proto-Personas sind trotzdem nicht wertlos: Als klar gekennzeichnete Hypothese, die du später mit Forschung prüfst, können sie ein guter Startpunkt sein. Das passt gut zum Ansatz von Lean UX, bei dem Annahmen bewusst formuliert und dann getestet werden.

Schritt für Schritt: Von Daten zur Persona

Schritt 1: Klären, wofür die Persona gebraucht wird

Bevor du irgendetwas recherchierst, beantworte eine Frage: Welche Entscheidungen soll die Persona leichter machen? Eine Persona für die Gestaltung der Abo-Verwaltung braucht andere Informationen als eine für die Rezeptseite.

Im Gemüsekisten-Beispiel könnte die Antwort lauten: „Wir wollen verstehen, warum Menschen in den ersten drei Monaten kündigen, und welche Funktionen ihnen helfen würden, länger dabeizubleiben.“ Diese Frage bestimmt, mit wem du sprichst und was am Ende auf der Persona steht. Alles, was nicht zur Frage beiträgt, darf später weg.

Schritt 2: Vorhandene Daten einsammeln

Die meisten Teams haben mehr Daten, als sie denken. Sie liegen nur verstreut herum. Schau dir zum Beispiel an:

• Support-Anfragen und E-Mails: Welche Probleme tauchen immer wieder auf?
• Kündigungsgründe: Falls es bei der Kündigung ein Freitextfeld gibt, ist das eine Goldgrube.
• Bewertungen in App-Stores oder auf Vergleichsportalen: Was loben Menschen, was kritisieren sie?
• Nutzungsdaten (Analytics): Das sind automatisch erfasste Zahlen dazu, was Menschen in deinem Produkt tun, etwa welche Seiten sie besuchen oder wie oft sie eine Lieferung pausieren.
• Gespräche aus Vertrieb und Support: Die Menschen dort hören täglich, was die Kundschaft beschäftigt.

Diese Daten zeigen dir vor allem, was passiert. Warum es passiert, erfährst du daraus selten. Im Beispiel siehst du in den Zahlen vielleicht, dass viele Kündigungen nach der vierten oder fünften Lieferung kommen. Den Grund dafür findest du erst im Gespräch.

Schritt 3: Mit echten Menschen sprechen

Das Herz einer qualitativen Persona sind Interviews. Sprich mit Menschen, die zur Frage aus Schritt 1 passen: im Beispiel mit aktiver Kundschaft, mit Menschen, die gekündigt haben, und mit einigen, die sich nur informiert, aber nie bestellt haben.

Ein paar Grundregeln helfen dabei:

• Frag nach konkretem Verhalten in der Vergangenheit. „Erzähl mir von der letzten Kiste. Was hast du mit dem Inhalt gemacht?“ bringt mehr als „Kochst du gern?“.
• Beobachte, wenn möglich. Kim Goodwin rät in einem Fachartikel zur Persona-Entwicklung, sich auf das zu konzentrieren, was Menschen tun, statt sie zu fragen, was sie wollen. Ein Blick in den Kühlschrank am Liefertag kann mehr verraten als zehn Fragen.
• Arbeite in Runden. Führe etwa fünf Gespräche, schau dir die Ergebnisse an und entscheide dann, ob du weitere brauchst. Wenn neue Gespräche kaum noch Neues bringen, kannst du aufhören.

Mehr zu Methoden, mit denen du Menschen und ihr Verhalten kennenlernst, findest du im Glossar unter User Research.

Schritt 4: Verhaltensvariablen finden

Jetzt kommt der Schritt, den viele überspringen und der den größten Unterschied macht. Goodwin beschreibt ihn so: Liste alle Punkte auf, in denen sich die Befragten in ihrem Verhalten unterscheiden. Solche Punkte heißen Verhaltensvariablen. Meist lassen sie sich als Skala mit zwei Enden beschreiben.

Für die Gemüsekiste könnten das zum Beispiel diese Variablen sein:

• Planung: plant Mahlzeiten für die ganze Woche voraus ↔ entscheidet jeden Abend spontan
• Kochsicherheit: kocht ohne Rezept mit dem, was da ist ↔ braucht für unbekanntes Gemüse eine Anleitung
• Motivation: will vor allem regionale Landwirtschaft unterstützen ↔ will vor allem Zeit beim Einkaufen sparen
• Regelmäßigkeit: jede Woche zu Hause ↔ oft unterwegs, unregelmäßiger Alltag

Beachte, was auf dieser Liste fehlt: Alter, Beruf, Geschlecht, Hobbys. Goodwin rät, mit demografischen Merkmalen vorsichtig zu sein, weil Verhaltensvariablen fürs Design meist mehr Gewicht haben. Ob jemand 28 oder 52 ist, sagt dir wenig darüber, ob die Person mit einem Kohlrabi etwas anfangen kann.

Schritt 5: Muster erkennen

Nimm jede befragte Person und setz sie auf jeder Skala an die passende Stelle. Das geht gut auf einem Whiteboard oder einem digitalen Board: eine Linie pro Variable, ein Klebezettel pro Person. Danach suchst du nach Menschen, die auf mehreren Skalen nah beieinanderliegen. Goodwin nennt das Personen, die über mehrere Variablen hinweg „zusammenklumpen“.

Im Beispiel könnte sich zeigen, dass vier Befragte Mahlzeiten vorausplanen, sicher ohne Rezept kochen und vor allem regionale Höfe unterstützen wollen. Fünf andere entscheiden spontan, brauchen Anleitung bei ungewohntem Gemüse und wollen vor allem Zeit sparen. Genau diese zweite Gruppe taucht auffällig oft bei den Kündigungen auf.

Aus diesen Mustern werden deine Personas. Prüfe jedes Muster kritisch: Ist es wirklich in den Daten zu sehen, oder siehst du, was du sehen wolltest? Goodwin warnt ausdrücklich davor, falsche Muster zu definieren. Ein Muster, das nur auf einer einzigen Person beruht, ist noch keins.

Schritt 6: Die Persona aufschreiben

Jetzt schreibst du für jedes Muster eine kurze Beschreibung. Goodwin empfiehlt, sie als kleine Geschichte statt als Stichpunktliste zu formulieren, sie kurz zu halten und jedes Element auf echte Daten zurückführen zu können. Hilfreich sind diese Bausteine:

• Ziele: Was will die Person erreichen, im Alltag und mit deinem Produkt?
• Typische Situation: Wann und wo kommt sie mit deinem Produkt in Berührung?
• Heutige Lösung: Wie löst sie das Problem bisher, und was nervt daran?
• Hürden: Woran scheitert sie, und warum?
• Ein oder zwei echte Zitate aus den Interviews, die das Muster gut auf den Punkt bringen.

So sieht der Unterschied im Gemüsekisten-Beispiel aus:

Vorher (Klischee): „Lisa, 34, Marketing-Managerin, wohnt in Köln, macht Yoga, liebt bio und Avocado-Toast. Möchte sich gesund ernähren.“

Nachher (aus Daten): „Sascha entscheidet meist erst gegen 18 Uhr, was es zu essen gibt, und hat dann wenig Lust auf Experimente. Die Kiste wurde abonniert, um sich den Wocheneinkauf zu sparen. Bekanntes Gemüse wird sofort verkocht, ungewohnte Sorten bleiben liegen, bis sie welk sind. Das schlechte Gewissen darüber ist der häufigste Grund, über eine Kündigung nachzudenken. Ziel: an stressigen Abenden in 20 Minuten etwas Gutes kochen, ohne Lebensmittel wegzuwerfen.“

Die zweite Fassung enthält kein Alter und keinen Beruf, aber sie beantwortet sofort Designfragen. Brauchen wir Rezepte zur Kiste? Ja, schnelle und passend zum Inhalt. Sollten Menschen einzelne Gemüsesorten ausschließen können? Wahrscheinlich. Lisa hätte auf keine dieser Fragen eine Antwort gegeben.

Wie viele Personas brauchst du? So viele, wie es deutlich unterschiedliche Muster gibt, und nicht mehr. Die NN/g warnt davor, zu viele Personas anzulegen: Sie sollen sich gut merken lassen und klar voneinander unterscheiden.

Schritt 7: Die Persona in den Alltag bringen

Eine Persona, die nur in einem Ordner liegt, hilft niemandem. Damit sie wirkt, muss sie dort auftauchen, wo Entscheidungen fallen:

• Stell die Personas gemeinsam vor und erzähl dabei, aus welchen Daten sie entstanden sind. Das schafft Vertrauen.
• Verknüpfe sie mit konkreten Aufgaben. Schreib in Tickets oder User Stories, für welche Persona eine Funktion gedacht ist.
• Nutze sie in Diskussionen. „Würde Sascha diese Einstellung um 18 Uhr finden?“ ist eine bessere Frage als „Ist das nutzerfreundlich?“.
• Verbinde sie mit anderen Werkzeugen. Eine Journey Map zeigt zum Beispiel, wie eine Persona Schritt für Schritt mit deinem Produkt in Berührung kommt.
• Plane eine Überprüfung ein. Menschen und Produkte ändern sich. Schau dir die Personas regelmäßig an, zum Beispiel nach jeder größeren Interviewrunde.

Typische Fehler und wie du sie vermeidest

Klischees statt Beobachtungen

Die häufigste Falle: Das Team füllt Lücken mit dem, was es sich unter „der typischen Kundschaft“ vorstellt. Heraus kommen Figuren wie Lisa mit dem Avocado-Toast oder „die technikferne ältere Generation“. Solche Personas fühlen sich plausibel an, weil sie bekannte Bilder bedienen. Genau das macht sie gefährlich. In einem Essay über Personas warnt Indi Young, dass demografische Angaben im Team zu Annahmen, gedanklichen Abkürzungen und unbewussten Stereotypen führen können.

Abhilfe: Jede Aussage auf der Persona braucht eine Quelle in deinen Daten. Wenn du etwas nicht belegen kannst, streich es oder kennzeichne es als offene Frage.

Zu viel Demografie, zu wenig Verhalten

Alter, Einkommen, Familienstand und Lieblingsmarke füllen eine Persona schnell, helfen aber selten bei Entscheidungen. Die NN/g schreibt dazu sinngemäß, dass demografische Daten für Produkt- und Designentscheidungen problematisch sind, weil sie nichts über Verhalten und Einstellungen aussagen. Young schlägt vor, Demografie nur dann aufzunehmen, wenn sie wirklich mit dem untersuchten Verhalten zusammenhängt. Das Alter etwa lässt sich oft besser als Lebensphase beschreiben („gerade ins Berufsleben gestartet“) statt als Zahl.

Das perfekte Stockfoto

Ein Foto macht eine Persona lebendig, lenkt aber auch die Aufmerksamkeit. Ein makelloses Werbefoto lädt dazu ein, die Persona nach ihrem Aussehen zu beurteilen. Manche Teams verzichten deshalb ganz auf Fotos oder nutzen schlichte Illustrationen. Young erwähnt, dass manche Teams Namen und Fotos ganz weglassen und stattdessen mit beschreibenden Verhaltensgruppen arbeiten. Wenn du ein Bild nutzt, wähle eines, das eine typische Situation zeigt, etwa jemanden am Herd nach Feierabend, statt eines Porträts.

Wunschkundschaft statt echter Kundschaft

Manchmal beschreibt eine Persona nicht, wer das Produkt nutzt, sondern wer es nutzen soll. Das ist legitim, wenn eine neue Zielgruppe erschlossen werden soll, aber dann muss es so heißen. Mische nie Wunsch und Wirklichkeit auf derselben Persona.

Falsche Genauigkeit

„Nutzt die App 3,2-mal pro Woche“ klingt präzise, ist bei zwölf Interviews aber erfunden. Goodwin rät, nicht mehr Sicherheit vorzutäuschen, als die Forschung hergibt. Wenn die Datenlage dünn ist, kennzeichne die Persona als vorläufig und beschränke dich auf wenige Ziele und Merkmale.

Einmal gemacht, nie wieder angeschaut

Personas veralten. Wenn sich das Produkt oder die Kundschaft verändert, passt die Persona von vor zwei Jahren vielleicht nicht mehr. Behandle Personas als lebendes Dokument, nicht als Abschlussbericht.

Personas und Jobs to be Done

Wer sich mit Personas beschäftigt, stößt früher oder später auf Jobs to be Done, kurz JTBD. Manchmal wird die Methode als Ersatz für Personas dargestellt. Für den Einstieg lohnt es sich, den Unterschied zu kennen.

Was Jobs to be Done ist

Die Grundidee von JTBD: Menschen „heuern“ ein Produkt an, um eine bestimmte Aufgabe in ihrem Leben zu erledigen. Statt zu fragen „Wer ist unsere Kundschaft?“, fragt JTBD „Welche Aufgabe soll unser Produkt für jemanden erledigen?“.

Das bekannteste Beispiel stammt aus dem Umfeld von Clayton Christensen, Professor an der Harvard Business School. Eine Fast-Food-Kette wollte mehr Milchshakes verkaufen. Im Rahmen eines Forschungsprojekts wurde einen Tag lang beobachtet, wer wann Milchshakes kaufte. Ergebnis: 40 Prozent davon wurden früh am Morgen gekauft, meist von Pendelnden zum Mitnehmen. Der „Job“ des Milchshakes war nicht Genuss, sondern: eine lange, langweilige Autofahrt erträglicher machen, eine Hand beschäftigen und bis zum Vormittag satt halten. Das brachte ganz andere Ideen für das Produkt hervor als Befragungen zu den idealen Eigenschaften eines Milchshakes.

Wo der Unterschied liegt

Vereinfacht gesagt: Eine Persona beschreibt, wer jemand ist und wie sich die Person verhält. Ein Job beschreibt, was jemand erreichen will, unabhängig davon, wer es ist. Im Gemüsekisten-Beispiel könnte ein Job lauten: „Wenn ich abends müde nach Hause komme, will ich schnell etwas Gesundes kochen, damit ich nicht wieder Pizza bestelle.“ Diesen Job haben vielleicht sehr unterschiedliche Menschen.

Page Laubheimer von der NN/g hält die Gegenüberstellung für ein Missverständnis. Wer Personas zugunsten von JTBD abschaffen will, versteht sie laut Laubheimer als rein demografische Profile. Gut gemachte Personas enthalten ohnehin Ziele, Verhalten und Hürden, und diese Ziele lassen sich als Jobs formulieren. Laubheimer schlägt vor, auf jeder Persona die passenden Jobs zu vermerken. Gleichzeitig nennt Laubheimer eine Schwäche von JTBD: Weil Jobs über alle Menschen verallgemeinert werden, geht der emotionale und soziale Kontext leicht verloren, und damit ein Teil der Empathie.

Was du für den Einstieg mitnehmen kannst

Du musst dich nicht entscheiden. Wenn dein Team schon Personas nutzt, formuliere deren Ziele als Jobs und schreib sie dazu. Wenn es im Team Vorbehalte gegen Personas gibt, etwa weil frühere Poster ohne Wirkung an der Wand hingen, kann der Start mit Jobs leichter sein. Die Personas können später folgen, wenn klar ist, dass unterschiedliche Menschen denselben Job sehr unterschiedlich erledigen.

Fazit

Zurück zum Team mit der Gemüsekiste. Mit einer klaren Frage, ein paar ausgewerteten Support-Anfragen und rund zehn Gesprächen wäre aus Lisa mit dem Avocado-Toast eine Persona wie Sascha geworden: jemand, der um 18 Uhr schnell etwas kochen will und an ungewohntem Gemüse scheitert. Diese Persona hätte direkt zu Ideen geführt, die Kündigungen verhindern können.

Gute Personas brauchen kein großes Budget. Sie brauchen Daten statt Vermutungen, Verhalten statt Demografie und die Disziplin, nur aufzuschreiben, was sich belegen lässt. Wenn du dazu noch die Jobs festhältst, die deine Personas erledigen wollen, hat dein Team ein Werkzeug, das in Diskussionen wirklich hilft.

Checkliste

• Die Frage ist klar, bei welchen Entscheidungen die Persona helfen soll.
• Vorhandene Daten wie Support-Anfragen, Kündigungsgründe und Nutzungsdaten sind gesichtet.
• Es gab Interviews mit Menschen, die zur Frage passen, in Runden von etwa fünf Gesprächen.
• Verhaltensvariablen sind als Skalen notiert, und alle Befragten sind darauf eingeordnet.
• Jede Persona beruht auf einem Muster, das bei mehreren Menschen auftaucht.
• Die Persona beschreibt Ziele, Situationen, heutige Lösungen und Hürden.
• Demografische Angaben stehen nur drauf, wenn sie das Verhalten erklären.
• Jede Aussage lässt sich auf Daten zurückführen, Unsicheres ist gekennzeichnet.
• Proto-Personas sind als Hypothese markiert.
• Passende Jobs to be Done sind auf der Persona vermerkt.
• Ein Termin für die nächste Überprüfung steht fest.

Quellen

• Page Laubheimer, Nielsen Norman Group: 3 Persona Types: Lightweight, Qualitative, and Statistical (2020)
• Page Laubheimer, Nielsen Norman Group: Personas vs. Jobs-to-Be-Done (2017)
• Kim Goodwin, MarketingProfs: Getting from Research to Personas: Harnessing the Power of Data
• Indi Young: Describing Personas (2016)
• Carmen Nobel, Harvard Business School Working Knowledge: Clay Christensen’s Milkshake Marketing (2011)
• Wikipedia: Alan Cooper (software designer)