Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Wann ‚Personas‘ mehr schaden als nützen

Dienstag 8. Mai 2018

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.

Abb. 1: Beispiel für eine Persona (zum Vergrößern klicken)

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

Personas - Liste möglicher Attribute

Abb. 2: Charakterisieren Sie die Personas anhand der hier gezeigten Attribute (zum Vergrößern klicken)

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

Download

Laden Sie sich die Mindmap als PDF hier herunter.

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.

Tipp

Spekulieren Sie nicht! Erfinden Sie keine Personas. Nutzen Sie Kontextinterviews mit potenziellen Anwender, um den Arbeitskontext inklusive der Kernaufgaben zu erfassen. Sie benötigen die empirische Basis sowieso, um die Stakeholder-Anforderungen systematisch ableiten zu können.

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:

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

Vorsicht!

Wer Entwicklern die Aufgaben (Anforderungen identifizieren, Systeme spezifzieren) überträgt, läuft Gefahr, dass die Gebrauchstauglichkeit nicht in ausreichende Maß erreicht oder/und aufwändiges Nachbessern notwendig wird.

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.

Tipp

Arbeiten Sie agil, aber ersetzen Sie dadurch kein systematisches Ableiten der UI-Spezifikation, wie in der ISO 9241-Familie beschrieben. Lesen Sie hier mehr zum Unterschied von User Requirements und User Request.

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?

Tipp

Hersteller sollten nicht alle Attribute, die die obige Mindmap vorschlägt, blind übernehmen, sondern ggf. welche weglassen oder ergänzen. Dies wird aber nur mit einer systematischen Analyse des Kontexts und der Produktrisiken gelingen.

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


Kategorien: Usability & IEC 62366
Tags: , , ,

2 Kommentare über “Wann ‚Personas‘ mehr schaden als nützen”

  1. Eckhard Jokisch schrieb:

    Lieber Herr Johner,

    Sie haben wieder einmal den Nagel auf den Kopf getroffen.
    Gerade zu den Fehlern 3. und 4. sprechen Sie mir aus der Seele.

    Ich habe vor einiger Zeit in einem Gastbeitrag unter
    https://t2informatik.de/blog/softwareentwicklung/anforderungen-ohne-expertenwissen/
    veröffentlicht, der genau diese Schwachstelle ins Licht rückt.

    Ich freue mich über jeden Verbündeten damit endlich dieser Unfug „Entwickler scheeiben die Anforderungen“ aufhört.

    Viele Grüße

    Eckhard Jokisch

  2. Prof. Dr. Christian Johner schrieb:

    Herzlichen Dank, lieber Herr Jokisch, für Ihre positive Rückmeldung, über die ich mich freue!

Kommentar schreiben