man in middle of wheat field

Was ist eine Persona?

de_DE
en_US
Lesedauer: 8 Minuten

TL;DR – Kurzbeschreibung Persona:

person looking out through window

Eine Persona ist eine fiktive Figur, die erstellt wurde, um eine Gruppe zu repräsentieren, die eine Website, Software, Marke oder ein Produkt nutzen könnte. Die Persona wird mit Bild und Beschreibung „lebendig“ gemacht und sorgt dafür, dass man sich in allen zu planenden Anforderungen (Software-Feature, UX, Kaufprozess, u.ä.) besser in diese Person hineinversetzen und alle Aspekte als diese Person durchdenken kann. Dies ist einfacher und führt zu besseren Ergebnissen, als das abstrakte Arbeiten mit soziodemografischen Zielgruppen.

Die Persona wird häufig in Scrum oder anderen agilen Entwicklungsprozessen in den Bereichen User Story, User Experience (UX) und Testing eingesetzt. Personas findet man weiterhin im Online Marketing und Content Marketing.

Die Persona als zentrales Element von User Stories

In der Software-Entwicklung hat sich bereits in den 1980er Jahren durch den Entwickler Alan Cooper der Begriff „Persona“ für einen repräsentativen User einer Software durchgesetzt. In der heutigen agilen Entwicklung sind Personas nunmehr de facto Standard für alle Planungen, die den Nutzer oder Kunden betreffen.

User Story

In erster Linie wird die Persona bei der User Story wichtig (weitere Verwendungen später in dieser Serie). User Stories haben in der Regel diese Struktur:

„Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen/Problemlösung>“

Der Grund dieser Struktur wird in einem gesonderten Beitrag zum Thema „User Story“ erklärt. Bei der Persona interessiert uns der Bereich <Rolle>

Die User Story ist eine kurze in Alltagssprache formulierte Softwareanforderung. Da wir sehr kundenzentriert arbeiten wollen, formulieren wir sie aus der Sicht eines Nutzers, der ein Problem gelöst oder ein Bedürfnis befriedigt haben möchte.

Beispiel:

„Als Kunde möchte ich eine große Auswahl an Zahlungsmöglichkeiten im Onlineshop haben, damit ich möglichst einfach nach meinen Wünschen bezahlen kann“

Diese Alltagssprache formuliert für Entwickler das „Was“ einer zu erstellenden Entwicklung. Das „Wie“ ist dem Entwickler überlassen. Diese Alltagssprache soll es einerseits erleichtern, die Anforderungen zu erheben, ohne dicke Lastenhefte zu schreiben. Andererseits soll sich jedes beteiligte Teammitglied in die Person hineinversetzen können und sich bei allen Entwicklungen fragen: „Würde das im Sinne dieses Kunden sein?“

Dieses Hineinversetzen würde schwierig werden, wenn wir – wie in der klassischen Nutzeranalyse – mit soziodemografischen Zielgruppen arbeiten. Unsere Zielgruppe ist männlich, 35-45 Jahre alt, gehobener Mittelstand, etc … – wenn wir aber nun eine „echte“ Person vor Augen haben, mit Bild, Name, Steckbrief und Geschichte, so kann man sich fast schon bildlich vorstellen, wie diese Person vor dem Rechner sitzt und dass benutzt, was wir gerade entwickeln.

Personas haben außerdem den Vorteil, dass sie nicht so beliebig sind, wie eine soziodemografische Gruppe. Es ist einfacher, einer kleinen Handvoll Personas ein Feature schmackhaft zu machen, als einer großen unspezifischen Gruppe. So verzettelt man sich weniger in einer beliebigen breiten und uninteressanten Ausgestaltung von Features.

Nachteile von Personas

Vielleicht fragt ihr euch: Wenn Personas so toll sind, warum nutzen nicht alle überall Personas?

Bei all diesen Vorteilen sollte man den einen großen Nachteil bedenken: Die Persona ist eine fiktive Einzelperson, die i.d.R. auf wenigen spezifischen Daten beruht – wenn überhaupt. Es sollte euch daher bewusst sein, dass es keine klaren direkten Bezug zu echten Kundendaten gibt und sie daher in Bereichen, wo es dieser Kundendaten bedarf, mit Vorsicht anzuwenden sind. Beispielsweise sollte bei wissenschaftlichen Analysen keine Persona als Ausgangspunkt angenommen werden.

Personas sind teil eines agilen Prozesses. D.h. Personas und deren Ergebnisse sollten iterativ und in kurzen Zeiträumen angewendet und dann geprüft und hinterfragt werden. Wendet nicht Personas als absolute Wahrheit an!

Beginnen wir mit der Erstellung einer Persona, indem wir sie zunächst klassifizieren.

Personas klassifizieren

Klassifizieren und Kategorisieren von Personas

1) Teilnehmer / Profiteure der Persona bestimmen

Die Persona hat das Potential,  die abteilungs- und professionsübergreifende Grundlage allen Handelns zu sein. Achtung: Wie im vorigen Abschnitt zu lesen, beschränkt sich das auf agile Umgebungen wo es keinen klaren Bezug zu echten Kundendaten gibt.

Je nach Unternehmens- und Abteilungsstruktur könnten folgende Unternehmensbereiche involviert und synchronisiert werden:

  • Anforderungserhebung von Soft- oder Hardware-Requirements
  • Anforderungserhebung von User Experience Requirements
  • Onlinemarketing
  • Contentmarketing
  • Social Media Marketing
  • Kaufprozesse
  • Registrierungsprozesse
  • Testing und UX Testing
  • Designentscheidungen wie Erscheinungsbild von Hardware, GUIs, Corporate Identity
  • uvm …

Ziel von Schritt 1:
Findet entsprechende Abteilungen/Mitarbeiter und laden Sie zum Kickoff der Persona-Erstellung ein.

2) Die Art der Persona bestimmen.

Im Kickoff oder Folgeterminen müssen wir nun die Art(en) der Persona(s) spezifizieren:

a) Persona als Ausgangspunkt oder Ziel?

Je nach Unternehmensalter und/oder -ausrichtung soll die Persona entweder den aktuellen Kunden repräsentieren – oder den zukünftigen. Diese Unterscheidung ist wichtig! Beispielsweise bei einem Unternehmen, dass noch nicht am Markt ist, kann man sich exakt die Persona modellieren, die man erreichen möchte. Da ist man viel freier und die Erschaffung der Persona kann die Unternehmensrichtung ggf. zurück beeinflussen.

b) Kategorien von Personas

Wir können zwischen 3 Gruppen von Personas unterscheiden:

  • Primäre Personas / Primary Personas
  • Sekundäre Personas / Secondary Personas
  • Ad-Hoc Personas oder Proto-Personas

Die Primäre Persona ist jemand, der mit unseren Entwicklungen möglichst vollständig und zufriedenstellend bedient werden kann. Die Primäre Persona darf nicht behindert, eingeschränkt oder enttäuscht werden durch Entwicklungen, die durch andere Primär-Personas erzeugt werden. Im extremsten Fall sorgen mehrere konträre Primär-Personas dafür, das mehrere Produkte entwickelt werden.

Beispiel: Wir sind eine Firma für einfache Amateurfunkgeräte. Es gibt nun die Primär-Persona eines 35jährigen CB-Funk-Amateuers und die Primär-Persona eines 7jährigen Kindes. Da die Technik der Geräte gleich ist, möchte die Geschäftsführung beide Gruppen erreichen. Beide haben aber wenige identische Ansprüche, sondern viele konträre. So kann es dazu führen, dass wir unterschiedliche Produkte herstellen. Für das Kind das einfache rosa Hello-Kitty-Funkgerät mit nur einem Bedienknopf, mit dem unser CB-Funker wohl eher nicht zufrieden wäre. Ob es sinnvoll ist, alle Personas zu bedienen, ist dabei eine individuelle unternehmenswirtschaftliche Entscheidung und soll hier nicht das Thema sein. Um beiden gerecht zu werden, würde es beim respektieren von Primärpersonas dazu führen, dass zwei Teams zwei Produkte entwickeln.

Die Sekundäre Persona ist der Primären in Eigenschaften und Wünschen sehr ähnlich. Es gibt jedoch wenige kleine Unterschiede, die berücksichtig werden müssen. Diese dürfen die Primär-Persona nicht beeinflussen, die Sekundär-Persona kann davon aber profitieren.

Beispiel: In unserem CB-Funker Beispiel könnte die Sekundäre Persona ein älterer Mensch mit geringerer Sehkraft sein. Dies würde zu Zusatzanforderungen führen, dass die Beschriftungen von Bedienelementen etwas größer sind. Stört unseren Hauptnutzer nicht, bringt aber Vorteile beim Sekundärnutzer. Auch hier sollte man sich die Frage stellen, wie bei den Sekundärnutzern das Aufwand/Kosten Verhältnis ist.

Die Adhoc-Persona oder Proto-Persona ist ein spezieller Typ. Die ersten beiden Persona-Typen werden (siehe auch den nächsten Artikel der Serie) auf Basis von Daten erstellt. Für die Proto-Persona gibt es keine Daten, sondern nur Annahmen oder eine fundierte Vermutung. Entweder, weil man sie spontan im Laufe eines Planungsmeetings erstellt (z.B. um verschiedene Möglichkeiten für exotische User zu durchleuchten) oder weil man noch keine Daten hat. Im letzteren Falle sollte man die Persona auf jeden Fall zu einem späteren Zeitpunkt mit Daten verifizieren.

Beispiel: Im Meeting hat jemand die Idee, die Funkgeräte aus den vorigen Beispielen mit einer Smart Home Anlage zu verbinden. Es wird spontan eine Persona erschaffen, von der man annimmt, sie wäre ein Smart Home Kunde. Nun kann man sich in diese Persona reinversetzen und durchdenken, ob diese Verbindung sinnvoll ist.

c) Arten von Personas

Es ist hilfreich zu durchdenken, in welchem Kontext sich die Persona bewegt. Beispielsweise könnte man an diese 3 Bereiche denken:

  • Audience Persona
  • Buyer Persona
  • User Persona

Eine Audience Persona ist das „Publikum“, dass man beispielsweise in Social Media Kanälen bespielt. Eine Buyer Persona ist jemand, der dir das Geld für dein Produkt gibt oder deinen Online-Kaufprozess durchläuft. Eine User Persona ist jemand, der ein Produkt oder eine Software anwenden.

Das kann ein und dieselbe Person sein, muss es aber nicht. Beispiel: Bei einem Kinderspielzeug ist der User ein Kind, die Audience vielleicht Elternteil Nummer 1, die den Social Media Kanälen folgt, aber Elternteil Nummer 2 ist die Buyer Persona, von der man annimmt oder weiß, dass sie den unternehmenseigenen Onlineshop nutzt.

d) Markt / Umfeld bestimmen

Es ist möglich, dass euer Unternehmen nicht nur mit Endkunden spricht, sondern auch mit Firmenkunden. Oder gar mit Partnern, an deren Endkunden wir uns indirekt richten:

  • B2B Persona (Firmenkunde)
  • B2C Persona (Endkunde)
  • B2B2C Persona (Endkunde, der über einen Firmenkunden erreicht wird)

Fazit:

Unternehmen verzetteln sich gerne in zu vielen unklaren Zielgruppen und Märkten. Wenn wir die Personas wie oben initial bestimmen wird sehr früh bereits klar, wieviel Aufwand es bedeutet, diese zu befriedigen. Ein Unternehmen mit Produkten für Kinder, Jugendliche, Erwachsene, Familien, von geringem bis zu hohem Einkommen, mit eigenem E-Commerce im B2B und B2C Markt werden entweder extrem hohen Aufwand treiben um es mit sehr vielen Einzellösungen den Personas recht zu machen – oder sie werden gar nicht erst Personas erschaffen und mit der fehlenden Kundenbrille einen unspezifischen Einheitsbrei erschaffen, den niemanden interessiert.

An unternehmerischen Fehlentscheidungen können Personas nichts ändern, aber Sie können sehr früh den möglichen Aufwand anzeigen, den man betreiben muss, um Kunden zufriedenzustellen.

Nun haben wir die Persona(s) eingegrenzt. Zur Erstellung der Persona fehlt uns aber noch etwas: Daten!

Daten als Grundlage von Personas

Daten als Grundlage von Personas

a) Welches Problem oder Bedürfnis hat die Persona?

In der Praxis findet man häufig Personas und Templates, die eine viel zu große Fülle an Informationen zu diesem fiktiven Charakter bieten. Da ist weniger oft mehr! Der wichtigste Punkt bei der Persona: Welches Problem wird durch dein Produkt gelöst oder welches Bedürfnis wird befriedigt? Wenn du diese Frage nicht beantworten kannst, ist deine Persona ungeeignet bzw. es macht keinen Sinn diese Menschen anzusprechen – warum sollten sie dein Produkt kaufen?

Die Erschaffung eines Produktes mit der Beantwortung dieser Frage „Welches Problem wird gelöst“ ist erstmal nicht Teil dieses Beitrages und wird zu einem späteren Zeitpunkt veröffentlicht.

b)  Beschaffe Daten

In der Regel gibt es bereits bestehende Datenhalden, aus denen du dich bedienen kannst. Da die Daten für eine Persona abhängig von Unternehmen, Produkt und Ziel sind, kann man es nicht verallgemeinern. Folgende Anregungen können dir weiterhelfen:

  • Frag das Marketing
    z.B. die klassischen Produktmarketingmanager, die soziodemografische Daten haben, z.B. die Einordnung der Kunden in Sinus Milieus. Eine wertvolle Quelle sind Webanalysten, die besonders genaue Daten zu Nutzern und Vorlieben erheben können.
  • Frag die Produktmanager, Entwickler und Designer
    Vielleicht haben sich diese Kollegen bereits Gedanken gemacht und Daten beschafft. Vielleicht gibt es bereits UX Pesonas oder sogar echte Nutzer und Beta-Programm Teilnehmer, die die interviewen kannst?
  • Frag die Strategen
    Gibt es eine Strategieabteilung oder ähnliches? Frag in welche Richtung das Unternehmen steuert, vielleicht möchte man sich zu einer anderen Nutzerklientel hinentwickeln?
  • Besorgt euch Daten oder kauft euch Daten
    Es gibt viele freie Quellen für Daten, oder Quellen, die für kleines Geld viele Insights bereit halten. Beispielsweise Statista, Branchenverbände, Beratungsdienstleister. Auch solltet ihr einen Blick auf LinkedIn und Xing haben, dort werden sehr gerne von entsprechenden Unternehmen und Beratern Whitepapers o.ä. veröffentlicht. Es lohnt sich, diesen Menschen zu folgen.

Vorsicht mit Fachmeinungen

Was du bei dir selbst vermeiden und auch bei den konsultierten Kollegen unterlassen solltest: Geht, wenn Daten verfügbar sind, nicht von Annahmen, Vermutungen und Fachmeinungen aus, nur weil es leichter ist. Fachleute haben oft eine erschreckend falsche Sicht vom echten User!

Without data, you’re just another person with an opinion

W. Edwards Deming

Immer, wenn eine Diskussionsrunde ohne Daten in eine Art demokratisch gewählte Hauptfachmeinung abdriftet, werfe ich dieses Zitat in den Raum, dass es ziemlich gut auf den Punkt bringt

Persona erstellen

Wichtig: Grenze den Kreis der Personas auf Basis der in den vorigen Artikeln genannten Kategorien ein und nehme dir vor, nicht mehr als 1-2 Primär- und Sekundär Personas zu erschaffen.

Jetzt kanns losgehen:

Auf Basis der im vorigen Punkt beschafften Daten sollte sich ein Bild der ersten Persona gebildet haben. Nun denkst du dir ein paar persönliche Eigenschaften aus, die diese Person hat. Die Persona erhält somit ein Gesicht, eine Geschichte, einen Charakter. Und das macht es den Leuten, die später mit der Persona arbeiten, sehr viel einfacher, sich in sie hineinzudenken!

Wir beginnen mit den Stammdaten:

  • Vor- und Nachname
  • Alter
  • Beruf und Branche
  • Familienstand

Dann beschreiben wir den Charakter der Persona:

  • Stärken
  • Schwächen
  • Ziele
  • Enttäuschungen / Herausforderungen

Idealerweise beschreiben wir den Charakter in Bezug das Umfeld, in dem ihr plant. Ihr solltet also keine allgemeinen Lebensziele formulieren, sondern Ziele in Zusammenhang mit eurem Projekt/Produkt. Habt ihr ein Reiseportal ist das Ziel der Persona eine Reisebuchung, mit Subzielen wie: Geld sparen, außergewöhnliche Reisen ohne Pauschaltouristen buchen, o.ä.

Weitere Felder solltet ihr gut durchdenken, da die Persona nicht zu komplex und zeitaufwändig werden soll. Aber je nach Kontext sind vielleicht folgende Felder interessant.

Kontext: Website, E-Commerce o.ä.:

  • Technologieaffinität
  • Verwendeter Browser, mobile oder Desktop

Kontext: Marketing (Brandmarketing, Onlinemarketing, Contentmarketing, u.w.) und Design

  • Psychologischer Typ (z.B. nach dem Myers-Briggs-Typenindikator):
    • Introvertiert / Extrovertiert
    • Intuitiv / Sensorisch
    • Denkend / Fühlend
    • Wahrnehmender / Urteilender
  • Lieblingsmarken
  • Lieblingsfarben, -autos, -smartphones, etc.

Versucht diese weiteren Felder möglichst kurz zu halten und an der wichtigsten Besonderheit der Persona im Kontext festzumachen. Bei B2B ist es vielleicht die Verantwortung und Hierarchiestufe der Person, bei Registrierungsprozessen sind die Technologieaffinität und Datenschutzbedenken wichtig. Denkt einfach: Welche Faktoren unterscheiden den Menschen hier speziell von Menschen in anderem Umfeld?

Füllt diese Daten am besten in ein Standardtemplate.

Persona Vorlage

4) Template Downloaden

Hier findet ihr das Persona Template für verschiedene Anwendungszwecke:

  • Persona – Gesamt
  • Persona – Basic

Beispiele:

  • Checkoutprozess im Reiseportal
  • Contentmarketing einer Parfümmarke

Ihr glaubt, das war’s? Nicht ganz! Im agilen Umfeld wollen wir uns ständig selbst hinterfragen und verbessern, deswegen darf ein Persona Review nicht fehlen.

Persona Review

Da Personas keine „Wahrheiten“ sind, wie im vorigen Artikel beschrieben, solltet ihr die Personas regelmäßig reviewen:

  • Nach jedem Sprint solltet ihr die Ergebnisse, deren Planung auf Personas beruhen, messen und auf Unstimmigkeiten überprüfen.
  • Setzt euch einen festen Termin (z.B. je Quartal) mit allen Abteilungen, die die Personas einsetzen, um die Persona selbst zu hinterfragen. Vielleicht hat sich die Unternehmensstrategie oder die Zielgruppen geändert? Ggf. müssen Personas angepasst oder ersetzt werden.
  • Macht euch ständig bewusst, dass es Situationen gibt, in denen die Persona völlig ungeeignet ist. Verfallt nicht in den im Agilen allgegenwärtig drohenden Cargo-Kult: Etwas machen, nur weil man irgendwo gesehen hat, dass es gemacht wird. Oder weil man es immer schon gemacht habt. Bleibt wachsam und selbstkritisch.

Ich hoffe, ich konnte euch einen breiten Überblick über das Thema Persona bieten. Ich freue mich über Feedback zum Artikel und eure Erfahrungen mit Personas. Schreibt einen Kommentar oder twittert darüber. Vielen Dank!

Schreibe einen Kommentar

Mastodon