Ende Februar haben Kyra Edeker und Jan Moorman im UXMagazin einen Beitrag gepostet, den ich aus zwei Gründen interessant finde. Die Autorinnen beleuchten in knapper Form die mittlerweile 30-jährige Geschichte der Personas. Zum anderen setzen sie sich im Detail mit der zunehmenden Kritik zu Personas auseinander, die in der UX-Gemeinde in letzter Zeit laut wird. Was bedeutet die Kritik für die Zielgruppenarbeit in der Technischen Redaktion?

Problem-Personas

Edeker und Moorman identifizieren drei typische Probleme bei der Erstellung von Personas:

1. Halbgare Personas
   Erstellen die Beteiligten ihre Personas mit zu wenig systematischen Untersuchungen, dann entstehen Personas, die nur scheinbar das Bedürfnis der Benutzer nach einem Arbeitswerkzeug erfüllen. Die Usability-Experten erhalten zwar eine Persona, durch eine unzureichende Faktengrundlage verleitet sie aber zu Fehlentscheidungen. „A little knowledge is a dangerous thing“, wie Alexander Pope schon im 19. Jahrhundert wusste.
2. Leere Personas
   Noch schlimmer sind leere Personas, die ohne Faktengrundlage lediglich aus Marketing-Annahmen und Vermutungen der Projektbeteiligten gespeist werden. Solche Personas halten in der Realität nicht stand, gehen an den Bedürfnissen der Entwickler vorbei und destabilisieren langfristig das Vertrauen in die Persona-Technik insgesamt.
3. Überdefinierte Personas
   Im Gegensatz zu den beiden vorherigen Fällen liegt hier das Problem in zu viel Information mit zu wenig Relevanz für die Entwickler. Edeker und Moorman verdeutlichen das am Beispiel einer Software für Support-Hotlines. Für die Persona ist letzten Endes nicht entscheidend, ob sie verheiratet ist oder nicht. Stattdessen muss die Persona aber herausarbeiten, dass es unterschiedliche Typen von Support-Mitarbeitern gibt: Unerfahrene, die lediglich möglichst viele Tickets abarbeiten und erfahrene, denen die Zahl der abgearbeiteten Tickets weniger wichtig ist und die sich auf eine gute Supportleistung konzentrieren.

Lösungen

Sollten wir angesichts dieser Probleme auf Personas verzichten? Die Autorinnen kommen zu einem eindeutigen Ergebnis:

Good personas that enable us to have extended role-play with our users serve a need that isn’t currently filled by anything else. If the design community throws personas in the trash, they’re back to square one: the standard old argument around the product team table based on everyone’s personal opinion. The user is lost in the equation.”

Es gibt also keine Alternative zu Personas. Aber es gibt Möglichkeiten, sie besser zu machen. Schlüsselfaktoren sind dabei:

• Solide Informationsbeschaffung und -auswertung
• Balance zwischen persönlichen Charakteristika (um die Persona realistischer zu machen) und den Einstellungen, Zielen, Erwartungen der Personas
• Anreicherung der Persona mit realen Fotos, Videos etc. aus der Benutzerbefragung
• Bewerben und Verbreiten der Personas im eigenen Unternehmen

… und die Technische Dokumentation?

Edeker und Moorman beziehen sich mit ihrem Post auf den Aspekt des Produkt- und User-Interface-Designs. In weiten Teilen gilt das aber gleichermaßen für die Technische Dokumentation (wie sich ja insgesamt viele Parallelen zwischen Dokumentation und Usability finden lassen).

Allerdings trifft uns das Problem der „leeren Personas“ fast noch schärfer, da das Produkt-Design den Käufer zumindest teilweise berücksichtigen muss und Marketingdaten dadurch zumindest eine geringe Relevanz haben. Technische Dokumentation hingegen richtet sich immer an den Benutzer – und dessen Bedürfnisse können sich von denen des Käufers stark unterscheiden.

Den Ratschlag, Personas auf einer aufwändigen Benutzeruntersuchung aufzubauen, ist wiederum für Technische Dokumentation berechtigt, aber letzten Endes unrealistisch. Denn wenn schon die Produktentwicklung nicht die Budgets dafür erhalten, sind die Chancen für die (oft als notwendiges Übel verstandene) Dokumentation noch wesentlich geringer.

Einen Ausweg bietet hier manchmal eine strategische Allianz mit dem Marketing und den Usability-Fachleuten. Was einer Abteilung als Budget nicht zugestanden wird, können drei Bereiche vielleicht gemeinsam verargumentieren. Wichtig ist für uns dann aber, dass die Recherchen sich auch auf die Benutzer erstrecken und nicht nur Kunden-Personas einbeziehen.

Alles in allem bleibt uns in der Technischen Dokumentation wohl nichts anderes übrig, als mit dem zu arbeiten, was wir haben. Das entspricht zwar ziemlich genau dem Problembild „halbgare Persona“. M. E: ist diese Lösung aber immer noch besser als komplett ohne Benutzerkonzept zu arbeiten. Umso wichtiger ist es, die Personas regelmäßig auf den Prüfstand zu stellen und mit Benutzerdaten abzugleichen, soweit wir sie ermitteln können.