{"id":1203570,"date":"2018-05-08T08:00:17","date_gmt":"2018-05-08T07:00:17","guid":{"rendered":"https:\/\/www.johner-institut.de\/blog\/?p=1203570"},"modified":"2024-11-06T13:56:15","modified_gmt":"2024-11-06T12:56:15","slug":"personas","status":"publish","type":"post","link":"https:\/\/www.johner-institut.de\/blog\/iec-62366-usability\/personas\/","title":{"rendered":"‚Personas‘: die 5 h\u00e4ufigsten Fehler vermeiden"},"content":{"rendered":"\n

Viele Firmen verwenden Personas<\/strong> als Methode im Usability und Requirements Engineering<\/a>. Eine Persona ist eine fiktive Person, die als repr\u00e4sentativer Vertreter einer Gruppe dient, typischerweise einer Gruppe potenzieller Benutzer eines Systems.<\/p>\n\n\n\n

Besonders in der agilen Software-Entwicklung<\/a> sowie bei Marketing- und Design-Agenturen sind Personas beliebt. Doch die Methode wird h\u00e4ufig missverstanden und birgt Risiken, die den meisten Firmen nicht bewusst sind.<\/p>\n\n\n\n\n\n\n\n

1. Wie Personas Benutzer prototypisch beschreiben<\/h2>\n\n\n\n

Eine Persona ist ein Steckbrief, der einen prototypischen Vertreter einer (Benutzer-)Gruppe beschreibt. Sie hilft dabei, sich diese Person konkret vorzustellen zu k\u00f6nnen. Dazu verwendet sie ein Bild der Person, gibt ihr einen Namen und beschreibt sie anhand pers\u00f6nlicher und beruflicher Charakteristiken.<\/p>\n\n\n\n

\"Beispiel<\/a>
Abb. 1: Beispiel f\u00fcr eine Persona (zum Vergr\u00f6\u00dfern klicken)<\/figcaption><\/figure>\n\n\n\n

Das Johner Institut empfiehlt, die fiktiven Personen beispielsweise anhand der Attribute und Charakteristiken zu beschreiben, die die Mindmap in Abbildung 2 umfasst.<\/p>\n\n\n\n

\"Personas<\/a>
Abb. 2: Charakterisieren Sie die Personas anhand der hier gezeigten Attribute (zum Vergr\u00f6\u00dfern klicken)<\/figcaption><\/figure>\n\n\n\n

Welche dieser Attribute tats\u00e4chlich genutzt werden sollten, h\u00e4ngt vom Kontext ab. Mehr dazu erfahren Sie weiter unten.<\/p>\n\n\n\n

Mindmap als PDF<\/a>Herunterladen<\/a><\/div>\n\n\n\n

2. Vermeiden Sie diese Fehler beim Arbeiten von Personas<\/h2>\n\n\n\n

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\u00dfen v.a. auf die folgenden Probleme und Fehler:<\/p>\n\n\n\n

Fehler 1: Spekulation und Wunschdenken statt Realit\u00e4t<\/h3>\n\n\n\n

Eine Persona ist kein prototypischer Vertreter, den sich ein Produktmanager<\/a> ausdenken sollte. H\u00e4ufig 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\u00e4chlichen Anwender korrekt repr\u00e4sentieren.<\/p>\n\n\n\n

Fehler 2: Ausbildung statt Aufgaben und Nutzungskontext<\/h3>\n\n\n\n

Regelm\u00e4\u00dfig klassifizieren die Hersteller die (k\u00fcnftigen) Anwender zu sehr \u00fcber deren Berufsbezeichnung und Ausbildung. Doch l\u00e4sst sich beispielsweise ein Facharzt f\u00fcr Innere Medizin mit den Zusatzbezeichnungen \u201einternistische Onkologie\u201c und \u201eMedikament\u00f6se Tumortherapie\u201c<\/em> nicht notwendigerweise mit nur einer Persona charakterisieren. Zwar ist die Ausbildung sehr pr\u00e4zise spezifiziert, aber der Arbeitskontext eines niedergelassenen Onkologen und einer Onkologin im Krankenhaus unterscheidet sich sehr.<\/p>\n\n\n\n

\n
<\/i> Tipp<\/div>\n

Spekulieren Sie nicht! Erfinden Sie keine Personas. Nutzen Sie Kontextinterviews<\/a> mit potenziellen Anwender, um den Arbeitskontext inklusive der Kernaufgaben zu erfassen. Sie ben\u00f6tigen die empirische Basis sowieso, um die Stakeholder-Anforderungen systematisch ableiten zu k\u00f6nnen.<\/p>\n<\/div>\n\n\n\n

Fehler 3: Falsche Zielsetzung<\/h3>\n\n\n\n

Der Gedanke vieler Firmen beim Verwenden von Personas besteht darin, den Entwicklern eine bessere Vorstellung davon zu verschaffen, wer die k\u00fcnftigen Anwender der zu entwickelnden Software sind.<\/p>\n\n\n\n

Eine Webseite<\/a> formuliert das so: \u201eSie [Personas] k\u00f6nnen z. B. einem Entwicklerteam aufgrund ihrer umfangreichen Beschreibung helfen, sich in die Lage der potenziellen Nutzer zu versetzen und diese Perspektive w\u00e4hrend des gesamten Designprozesses leicht zu vertreten.\u201c<\/em><\/p>\n\n\n\n

Zwar spricht nichts dagegen, Entwicklern diese Informationen zu gew\u00e4hren. Wenn die Entwickler allerdings diese Informationen tats\u00e4chlich ben\u00f6tigen, um Ihre Aufgaben zu erledigen, stellt sich die Frage, wer f\u00fcr die folgenden T\u00e4tigkeiten verantwortlich ist:<\/p>\n\n\n\n