Blog-Artikel

Personas im UI/UX-Design

Design
Methoden
UI/UX
Konzeption
Seit über 20 Jahren sind Personas als Methode im Bereich des UI/UX-Designs etabliert. Anleitungen und Templates in Online-Blogs und Fachliteratur erwecken den Eindruck, dass man damit einfach und schnell nutzerzentriert arbeiten kann. In der Realität sieht dies jedoch meist anders aus.

Zur verbesserten Lesbarkeit verzichten wir in diesem Beitrag auf das Gendern und weisen darauf hin, dass stets alle Geschlechter gemeint sind.

Eine fiktive Person als Vertreter einer Nutzergruppe

Das Konzept der Persona wurde erstmals 1999 vom Softwareentwickler Alan Cooper vorgestellt. Zu der Zeit wurden Softwareprodukte noch von Entwicklern selbst gestaltet, was meist dazu führte, dass die tatsächlichen Nutzer sich darin nicht zurechtfanden. Einerseits fehlte das Wissen über die Bedürfnisse, Anforderungen sowie die Verhaltensweisen der Nutzer. Andererseits hatten sie nie die Intention, sich in andere Personen hineinzuversetzen, um das User Interface entsprechend zu gestalten. Alan Cooper wollte dies ändern und entwickelte die Persona, welche den Entwicklern dabei helfen sollte, Software aus Sicht des Nutzers zu gestalten. 

Dabei handelt es sich um eine fiktive Person, die auf realen, erhobenen Daten basiert und eine Gruppe von Nutzern mit ähnlichen Eigenschaften repräsentiert. Eine Persona kann also als eine Art Datenmodell verstanden werden, das meistens in einem Steckbrief festgehalten wird. Neben einem Namen und einem Foto werden dort unter anderem Persönlichkeitsmerkmale, Wünsche und Interessen sowie Verhaltensmerkmale notiert.

Design Persona vs. Marketing Persona

Personas, die im UI/UX-Design angewendet werden, sollten nicht mit anderen Varianten der Persona verwechselt werden. Diese werden nämlich unter anderem auch im Marketing eingesetzt. Dort liegt der Fokus allerdings auf dem Kaufverhalten und nicht auf dem Nutzungsverhalten bei der Interaktion mit einer Benutzerschnittstelle. Dementsprechend sind andere Daten relevant. 
Es besteht außerdem die Verwechslungsgefahr zwischen Personas und Zielgruppen. Letztere ist eine abstrakte Beschreibung einer Nutzergruppe, die auf quantitativen Daten basiert. Personas hingegen sind konkret und basieren in erster Linie auf qualitativen Daten.

Konkrete statt elastische Nutzer

Wenn innerhalb eines Projektteams von dem Nutzer gesprochen wird, besteht die Gefahr, dass jeder Beteiligte eine andere Person im Kopf hat. Meistens basiert diese auf den eigenen Annahmen und ist im schlimmsten Fall sogar stereotypisiert. Mithilfe von Personas soll dies vermieden werden. Die konkrete Definition von einer oder mehreren Personas führt innerhalb eines Projektteams zu einem gemeinsamen Verständnis. Wenn also von dem Nutzer gesprochen wird - oder noch besser: der Persona namens Max - haben alle Beteiligten dieselbe Person im Kopf.

Dadurch kann zudem das Phänomen des "elastischen Nutzers" vermieden werden. Wenn der Nutzer nicht genau definiert ist, kann es vorkommen, dass die Eigenschaften der Nutzer im Laufe des Projektes an die Bedürfnisse von Entwicklern oder Designern angepasst werden. Dann wird der Anfänger, der Unterstützung vom System benötigt, plötzlich zum Experten, der das System auf Anhieb problemlos bedienen kann. Dadurch wird Problemen im Design- und Entwicklungsprozess eher ausgewichen, anstatt eine Lösung dafür zu finden.

Indem die Eigenschaften der Nutzer festgehalten werden, kann zudem das Phänomen des “elastischen Nutzers” vermieden werden. Dieses tritt auf, wenn die Eigenschaften und Anforderungen der Nutzer an das bestehende Produkt angepasst werden, wodurch Probleme eher umgangen statt gelöst werden. Versetzt man sich in die Personas, können potenzielle Probleme aufgedeckt und Lösungen entwickelt oder auch validiert werden. 

Dabei ist gerade das ein wichtiger Vorteil der Persona: offensichtliche Probleme können bereits ermittelt werden, bevor mit realen Nutzern getestet wird. Dadurch können Zeit und Aufwand bei der Evaluation eines Systems gespart werden.

Häufige Fehler bei der Entwicklung und Nutzung von Personas

Wenn von einer Persona gesprochen wird, denken die meisten an den Steckbrief, in dem die Informationen festgehalten werden. Hierbei handelt es sich aber lediglich um die Dokumentation und nicht um die Persona. Diese sollte nicht nur auf dem Papier existieren, sondern in den Köpfen aller Beteiligten - wie eine Person, die man tatsächlich kennengelernt hat oder ein Charakter aus der Lieblingsserie.

Bei der Entwicklung von Personas wird oft der Fehler gemacht, diese auf eigenen Annahmen zu basieren anstatt auf erhobenen Daten. Dadurch fließen stereotypische Eigenschaften und falsche Informationen ein, wodurch eine Persona nicht mehr repräsentativ für die tatsächlichen Nutzer ist. Dies kann passieren, wenn man nicht ausreichend über die Methode informiert ist oder weil der Aufwand der Datenerhebung als zu hoch angesehen wird. Immerhin beinhaltet der Prozess der Entwicklung einer Persona eine Datenerhebung und -auswertung, die Ableitung mehrerer Personas, die Dokumentation der Informationen sowie die Präsentation im Team. Um wirklich repräsentative Personas zu erstellen, ist dieser Aufwand jedoch dringend notwendig.

Ein weiterer Fehler ist es, Personas als Steckbriefe zu erstellen und anschließend nicht weiter zu nutzen. Man könnte meinen, dass man mit der Methode fertig ist und zur nächsten übergehen kann. Dabei fängt der Nutzen von Personas erst an, wenn man sie in Kombination mit anderen Methoden verwendet. Dazu zählen beispielsweise Jobs to be done, Use Cases und User Journeys, welche dadurch viel zuverlässiger und konkreter ausgefüllt und angewendet werden können.

Fazit

Personas können einen hohen Nutzen für UI/UX-Projekte haben, da sie zu einem gemeinsamen Verständnis der Nutzer innerhalb eines Teams beitragen und schnelle Antworten auf Designfragen bringen können. Um diesen Nutzen zu erfüllen, werden jedoch repräsentative Personas benötigt. Und diese erfordern einen hohen Aufwand bei der Datenerhebung und -auswertung sowie bei regelmäßigen Aktualisierungen von Informationen. Nimmt man diesen nicht in Kauf, kann das schwerwiegende Folgen für das Produkt haben. Verlässt man sich auf ausgedachte Personas, kann das zu einer großen Unzufriedenheit der tatsächlichen Nutzer führen und einen umso größeren Aufwand verursachen, wenn nach Release große Veränderungen am Produkt vorgenommen werden müssen. Wenn man sich also dazu entscheidet, Personas zu verwenden, sollten diese sorgfältig entwickelt werden.

Nutzen wir Personas?

Im Vergleich zum Nutzen sehen wir den Aufwand der Erstellung von repräsentativen Personas als zu hoch an. Bei wechselnden Anforderungen in agilen Projekten sind zudem immer neue Informationen notwendig, welche über die erhobenen Daten hinaus nur durch die eigene Vorstellungskraft erlangt werden können. Dabei kann es jedoch zu unzuverlässigen Annahmen kommen, welche die tatsächliche Nutzerzentriertheit eines Projektes verfälschen können.
Bevor man also weitere Daten erhebt, auswertet und in die Personas einpflegt, um sich mit gutem Gewissen in diese hineinversetzen zu können, kann man auch ins Gespräch mit den tatsächlichen Nutzer gehen. Wir setzen also auf den direkten Austausch, um Anforderungen abzufragen und Tests durchzuführen. Dadurch erhalten wir konkretes Feedback und können direkt darauf reagieren.