‚Personas‘: die 5 häufigsten Fehler vermeiden

Viele Firmen verwenden Personas als Methode im Usability und Requirements Engineering. Eine Persona ist eine fiktive Person, die als repräsentativer Vertreter einer Gruppe dient, typischerweise einer Gruppe potenzieller Benutzer eines Systems.

Besonders in der agilen Software-Entwicklung sowie bei Marketing- und Design-Agenturen sind Personas beliebt. Doch die Methode wird häufig missverstanden und birgt Risiken, die den meisten Firmen nicht bewusst sind.

1. Wie Personas Benutzer prototypisch beschreiben

Eine Persona ist ein Steckbrief, der einen prototypischen Vertreter einer (Benutzer-)Gruppe beschreibt. Sie hilft dabei, sich diese Person konkret vorzustellen zu können. Dazu verwendet sie ein Bild der Person, gibt ihr einen Namen und beschreibt sie anhand persönlicher und beruflicher Charakteristiken.

Das Johner Institut empfiehlt, die fiktiven Personen beispielsweise anhand der Attribute und Charakteristiken zu beschreiben, die die Mindmap in Abbildung 2 umfasst.

Welche dieser Attribute tatsächlich genutzt werden sollten, hängt vom Kontext ab. Mehr dazu erfahren Sie weiter unten.

2. Vermeiden Sie diese Fehler beim Arbeiten von Personas

Die Usability und Requirements Engineers am Johner Institut mussten in Dutzenden Projekten beobachten, dass die Verwendung von Personas den Projekten mehr schadete als nutzte. Sie stießen v.a. auf die folgenden Probleme und Fehler:

Fehler 1: Spekulation und Wunschdenken statt Realität

Eine Persona ist kein prototypischer Vertreter, den sich ein Produktmanager ausdenken sollte. Häufig glauben Firmen, die Anwender zu kennen. Die Praxis zeigt jedoch, dass die Personas eher der Erwartung oder gar dem Wunschdenken der Firmen entsprechen, aber nicht die tatsächlichen Anwender korrekt repräsentieren.

Fehler 2: Ausbildung statt Aufgaben und Nutzungskontext

Regelmäßig klassifizieren die Hersteller die (künftigen) Anwender zu sehr über deren Berufsbezeichnung und Ausbildung. Doch lässt sich beispielsweise ein Facharzt für Innere Medizin mit den Zusatzbezeichnungen „internistische Onkologie“ und „Medikamentöse Tumortherapie“ nicht notwendigerweise mit nur einer Persona charakterisieren. Zwar ist die Ausbildung sehr präzise spezifiziert, aber der Arbeitskontext eines niedergelassenen Onkologen und einer Onkologin im Krankenhaus unterscheidet sich sehr.

Fehler 3: Falsche Zielsetzung

Der Gedanke vieler Firmen beim Verwenden von Personas besteht darin, den Entwicklern eine bessere Vorstellung davon zu verschaffen, wer die künftigen Anwender der zu entwickelnden Software sind.

Eine Webseite formuliert das so: „Sie [Personas] können z. B. einem Entwicklerteam aufgrund ihrer umfangreichen Beschreibung helfen, sich in die Lage der potenziellen Nutzer zu versetzen und diese Perspektive während des gesamten Designprozesses leicht zu vertreten.“

Zwar spricht nichts dagegen, Entwicklern diese Informationen zu gewähren. Wenn die Entwickler allerdings diese Informationen tatsächlich benötigen, um Ihre Aufgaben zu erledigen, stellt sich die Frage, wer für die folgenden Tätigkeiten verantwortlich ist:

• Kernaufgaben identifizieren
• Stakeholder-Anforderungen z.B. Nutzungsanforderungen erheben
• Software-System inkl. Benutzerschnittstelle spezifizieren

Hoffentlich nicht die Entwickler! Entwickler verfügen über Kompetenzen in der Entwicklung. In ihrer Entwicklerrolle(!) sind sie weder Requirements Engineers noch Interaktionsdesigner noch Informationsarchitekten.

Durch agiles Entwickeln die Gebrauchstauglichkeit iterativ zu erreichen, mag zwar „cool“ sein. Es bleibt aber ein kosten- und zeitaufwendiges Try-Error-Verfahren.

Fehler 4: Verwechseln von User Requirements & User Requests

Verstärkt wird dieses Problem, wenn Personas auch die Wünsche der Anwender dokumentieren. Zu leicht erliegen die Firmen dem Irrtum, dass diese die User Requirements seien. Es sind aber die User Requests. Produkte müssen jedoch die User Requirements, die Nutzungsanforderungen, erfüllen.

Fehler 5: Regulatorische Probleme

Dadurch, dass – wie eben erläutert – Entwickler die Methode „Personas“ nutzen, entstehen regulatorische Risiken:

• Die einzelnen Dokumente (z.B. Zweckbestimmung, Stakeholder-Anforderungen, Software Requirements Specification) werden nicht nach einander geprüft und freigegeben. Das führt häufig zu Nichtkonformitäten z.B. mit den Anforderungen der ISO 13485, der IEC 62366 und der IEC 62304.
• Probleme mit der Traceablity zwischen diesen Dokumenten werden befördert.
• Der Nachweis wird erschwert, dass die für die einzelnen Tätigkeiten verantwortlichen Personen über die spezifischen Kompetenzen verfügen.

Fehler 6: Überinterpretation und Missverständnisse

Eine Persona ist ein prototypischer Vertreter einer Gruppe. Diese Darstellung lässt aber nicht erkennen, welche Attribute relevant sind und welche Schwankungsbreiten diese Attribute haben dürfen.

Beispielsweise sei die Persona „Steffi Harmsen“ 22 Jahre alt. Bedeutet das, dass die anderen Vertreter dieser Benutzergruppe auch so jung sind? Spielt das Alter überhaupt eine Rolle im gegebenen Kontext?

3. Welche regulatorischen Anforderungen Personas zu erfüllen helfen

Personas helfen dabei, gleich mehrere regulatorischen Anforderungen zu erfüllen:

• Medizinproduktehersteller müssen die Zweckbestimmung formulieren. Zu dieser zählen auch eine Charakterisierung der Anwender.
• Die IEC 62366 fordert eine „Spezifikation der Anwendung“ und als Teil derer explizit ebenfalls eine Charakterisierung der Anwender.
• Bei der Risikoanalyse müssen die Hersteller diese Charakteristiken berücksichtigen. Das fordern sowohl die Medizinprodukterichtlinie (MDD) als auch die Medizinprodukteverordnung (MDR) in den jeweiligen Anhängen I.

4. Fazit und Zusammenfassung

Die Informationen, mit denen Personas die Benutzergruppen prototypisch charakterisieren, müssen die Hersteller dokumentieren. Dies spricht dafür, Personas als Methode zu nutzen.

Wenn Hersteller mit Personas jedoch das Ziel verfolgen, dass Entwickler damit bessere Produkte entwickeln, ist die Wahrscheinlichkeit hoch, dass das Arbeiten mit Personas mehr Risiken und Probleme verursacht als Nutzen stiftet.

Personas sind eine Methode zum Charakterisieren und Dokumentieren von Benutzergruppen. Personas sind keine Methode zum systematischen Identifizieren von Benutzergruppen. Sie ersetzen keine systematische Erhebung der Anforderungen. Hersteller sollten mehr als eine Persona pro Benutzergruppe spezifizieren.

Das Usability-Team des Johner Instituts nutzt eine tabellarische Darstellung, um Benutzergruppen knapp, präzise und dennoch vollständig und normenkonform zu beschreiben. Sie finden diese im Auditgarant.

Haben Sie Fragen z.B. zum Spezifizieren Ihrer Benutzergruppen? Unser Usability-Team hilft gerne, im Rahmen des Micro-Consultings sogar kostenlos.

Hier kostenlose Antworten bekommen