Content also available in:

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!
Mehr dazu im nächsten Artikel dieser Serie:

Andreas Poschen ist ein Spezialist für Konzeption, E-Commerce, UX und Digital Marketing aus Aachen. Er arbeitet als Product Owner Smart Home für Web, iOS und Android bei einem IT-Mittelständler und schreibt in diesem Blog über seine Arbeit als PO und seine Gedanken. Folgt ihm gerne auf:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.