Personas im Service-Design – Vom Plakat zur Performance (Teil 1)

Was sind eigentlich Personas, und wie erweckt man sie zum Leben?

Dieser Artikel bildet den Startpunkt einer Reihe über Personas, einer mächtigen Methode aus dem Interaktions- und dem Service-Design. brightONE nutzt Personas schon seit ein paar Jahren und hat noch einiges mehr damit vor. Ich gebe in diesem Artikel einen Einstieg zum Was und Warum, bevor wir den nächsten Schritt machen – hin zu „Living Personas“.

Aber lassen Sie uns am Anfang beginnen.

Als einer der prägenden, frühen Protagonisten der Persona-Methode gilt der amerikanische „Vater“ von Visual Basic, Agenturinhaber und Buchautor Alan Cooper. Er schrieb darüber um die Jahrtausendwende in seinem provokativen Buch „The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity“ (2. Auflage hier). Den Titel kann man lose so übersetzen „Den Bock zum Gärtner gemacht: Warum uns High-Tech-Produkte zum Wahnsinn treiben und wie man wieder Vernunft reinbringt“.

Wer ist hier der Bock, und wer der Gärtner? In Coopers Buch bekommen Entwicklungsprozesse ihr Fett weg, bei denen interaktive Systeme rein aus der Experten-Innensicht definiert werden, ohne je die Bedürfnisse der Endnutzer in Betracht zu ziehen.

Ein Plädoyer für nutzerzentriertes Design, das 15 Jahre später in seiner Schärfe für meine Ohren altmodisch klingt.

Seitdem sind viele begriffliche Säue durchs Dorf getrieben worden (Human-Computer-Interaction, Usability, User-Experience, Service-Design) und die benötigten Kompetenzen werden mittlerweile auch in Deutschlands Universitäten gelehrt. Andererseits treffe ich immer wieder auf Unternehmen, bei denen Systeme freischwebend und ohne Endnutzerbeteiligung definiert und umgesetzt werden.

Wenige deutsche IT-Unternehmen sind so ausgerichtet, dass sie sich regelmäßig Zugang zu passenden Endkunden in ihren natürlichen Nutzungskontexten verschaffen. Selbst wenn es eine User-Research-Phase zu Beginn eines Software-Projektes gegeben hat, bei der „echte Endnutzer“ beteiligt waren, ist die Frage, wie man das Wissen daraus in das Design- und Entwicklungsteam bringt und am Leben erhält.

Eine Methode, genau das zu leisten, sind Personas. Cooper beschreibt Personas folgendermaßen (meine lose Übersetzung aus dem Englischen, Anfang von Kapitel 9):

„Personas sind keine echten Personen, aber sie repräsentieren diese im gesamten Designprozess. Sie sind hypothetische Urbilder echter Nutzer. Obwohl sie ausgedacht sind, werden sie doch methodisch streng und präzise definiert. Im Grunde sind  unsere Personas nicht so sehr ausgedacht, wir entdecken sie vielmehr als Nebenprodukt unseres Untersuchungsprozesses. Wir denken uns allerdings ihre Namen und persönliche Details aus.“

Was leisten Personas im Design von Produkten und Services?

• Das Design-Team kann die Nutzer des Produktes empathisch wahrnehmen, es wird dazu angehalten, flüssige und natürliche Interaktionen mit Produkten und Services zu gestalten.
• Sie zeigen einen gemeinsamen Weg auf, der über die Tellerränder der einzelnen Beteiligten hinaus weist. Sie schützen gegen Scheuklappen und vorschnelle Lösungen, die die Akzeptanz des Ergebnisses bei Endkunden beeinträchtigen würden.
• Sie geben Teams eine gemeinsame Sprache, bei denen die Namen der Personas als Kürzel dienen. Niemand sollte sich mehr in Allgemeinplätze flüchten („unsere Nutzer würden…“), abstrakte Segmente verwenden („Die Young Professionals würden…“), oder die jeweilige Einzelmeinung zum Zentrum der Welt erklären („ich als Experte würde…“ und implizit: daher würden alle anderen auch…). Mit einer gut gewählten Persona-Gruppe im Design-& Entwicklungsteam entstehen vielschichtigere, dichtere und damit produktivere Diskussionen: „Wie würde Christian vor seinem Hintergrund mit diesem Service interagieren? Wie würde Nicole es tun? Ist ihre Erfahrung unterschiedlich? Wie unterscheidet sie sich? Was wäre also vor ihrem jeweiligen Hintergrund die optimale Nutzungserfahrung? Da Christian unsere Haupt-Persona ist, wie schaffen wir es, dass seine Belange besonders effizient berücksichtigt werden, ohne Nicole vor den Kopf zu stoßen?“.
• Sie wirken in offenen Kreativ-Prozessen als sog. strange attractors: Personas einzuführen ist ein mächtiger Schritt, wenn man Design-Teams leitet oder beauftragt. Man motiviert dadurch nutzerzentrierte, kreative Design-Lösungen, ohne den Möglichkeitsraum vorschnell einzuschränken. Ich verstehe Personas neben funktionalen Requirements und Business-Zielen als Gravitationsquellen, die Design-Lösungen in den Orbit relevanter Nutzungskontexte ziehen.
• Auch wenn sich das Produkt sich ändert, können die Personas genauso weiterverwendet und trotzdem neue Ergebnisse erzielt werden.

Was macht eine gute Persona aus?

Forrester hat 2007 eine nützliche Checkliste für die Gütekriterien von Persona-Dokumenten erstellt, die „Persona Review Scorecard 2.0“. Dies sind die Kriterien:

1. Die Beschreibung der Persona klingt wie eine echte Person.
2. Die Geschichte der Persona ist mitreißend.
3. Das Persona-Dokument zeigt alle wesentlichen Charakteristika der jeweiligen Persona sowie ihre großen Ziele.
4. Die Persona ist spezifisch darauf zugeschnitten, Design-Entscheidungen zu fördern.
5. Das Persona-Dokument ist von seiner Gestaltung her gebrauchstauglich.
6. Das Persona-Dokument ist angemessen hochwertig aufbereitet.

Ich finde auch, dass Personas ein empirisches Fundament brauchen, also nicht frei fantasiert sein sollten. Das kann man erreichen, indem das Design-Team in der Auftakt-Phase eines Projektes Interviews oder Beobachtungen mit relevanten Anwendern durchführt und die Erkenntnisse in Personas destilliert. Sonst klingen sie selten echt und bringen auch keine mitreißende Geschichte mit. Man merkt als Leser, wenn eine Persona wie der Hauptdarsteller in einem Michael-Bay-Action-Film angelegt ist – ein Abziehbild, ein reines Klischee.

Beim Schreiben von Personas geht man als Autor einen schmalen Grat zwischen Spezifität und Verallgemeinerung. Ist die Persona zu konkret definiert, verliert sie ihre Flexibilität. Ist sie zu generisch, klingt sie nicht wie eine reale Person. Dazu kommt noch, dass Personas ja nicht im statistisch-mathematischen Sinne repräsentativ sind, sondern vielmehr plausible Akteure für Geschichten abgeben sollen, die noch im Begriff sind, zu entstehen.

Es hat sich auch bewährt, eine bestimmte Persona-Gruppe zu besetzen, die dann gemeinsam verschiedene Aspekte der Nutzerschaft abdeckt:

• Insgesamt ca. 3-4, damit man alle auf einmal im Kopf behalten kann
• Eine Haupt-Persona, dazu 2-3 Neben-Personas
• Nach Bedarf auch eine Anti-Persona, die konträre oder sogar destruktive Komponenten mitbringt. Solch ein Störer kann helfen, ausgetretene Pfade im Design zu verlassen oder Widerstand zu antizipieren (z. B. den Datenschutz-Fundamentalisten in einem Social-Media-Projekt).

Christian Lange, 44 – hier als Beispiel-Persona

Für unser internes Intranet-Entwicklungsprojekt habe ich vier Personas geschrieben, die auf knapp 30 internen, internationalen, halbstrukturierten qualitativen Interviews basieren. Diese haben uns sehr dabei geholfen, Anforderungen aus verschiedenen Blickwinkeln zu betrachten und zu priorisieren. Sie machten sich auch gut in der Cover-Story, die wir zur Visualisierung unserer Produkt-Ambition verwendet haben, als es darum ging, intern finanzielle Unterstützung für das Projekt zu beantragen.

Hier sehen Sie Christian, unsere Haupt-Persona. Sie enthält diese Aspekte:

• Name (realistisch für das Alter und die Region, aus der die Person stammt)
• Demografische Merkmale und Lebensumstände (plausibel, nicht zu generisch)
• Foto, um eine emotionale Verbindung herstellen zu können
• Wörtliches Zitat, das die Persona weiter charakterisiert
• Interessen
• Wünsche
• Produktnutzung
• Motivationen und Frustrationen
• Technologie-Affinität
• Visualisierung von Kern-Aspekten der Produktnutzung (z.B. wie häufig, in welchen Kontexten)

Im nächsten Teil erfahren Sie, wie wir bei unserem Kundentag am 23.9.2014 vier Personas zum Leben erwecken – vom Plakat zur Performance. Bis dahin freue ich mich über Fragen und Anregungen unter sven.koerber[at]brightone.eu oder als Kommentar zu diesem Artikel.