Personas und äußerst beliebte Design-Fallen in der Entwicklung von Software-Produkten

Personas sind ein nützliches und grundlegendes Design-Werkzeug, um positive Benutzererfahrungen zu entwickeln. Personas unterstützen Produktteams dabei, bessere Design-Entscheidungen zu treffen. Die Basis von Personas ist tiefes Verständnis der Nutzer. Dieses Verständnis wird durch User Research gewonnen, analysiert und aufbereitet und als Nutzer-Archetyp (Persona) für die tägliche Arbeit am Produkt genutzt. Im Idealfall helfen Personas Design-Fallen von Software-Produktteams zu verhindern. Drei der beliebtesten Fallen beschreibe ich hier:

Falle 1: Self-Referential Design

Was passiert, wenn wir als Produktteam Design-Entscheidungen treffen ohne die Nutzer zu verstehen? Wir projizieren unsere Ziele, Motivationen, Skills und mentale Modelle [1] auf das Produkt. Wir treffen Design-Entscheidungen ausschließlich für uns. Wir selbst verstehen unsere Anwendung sehr gut, weil sie auf unserem „Implementation Model“ [2] basiert. Alle anderen jedoch, also auch die Nutzer, verstehen die Anwendung im schlimmsten Fall nicht. Oft tappt man in diese Falle, wenn wir besonders „coole“ Apps bauen wollen (z.B. abgefahrene Animationen, verrückte Interaktionen, crazy AI, usw.) die nur wir als Ersteller verstehen, aber der Rest der Welt nicht.

Personas helfen dabei, diese Falle zu umgehen, da die Persona im Team ein gemeinsames Verständnis über den Nutzer erzeugt. Dennoch kann auch unter Nutzung der Persona etwas geschwindelt werden. Besonders geschwindelt wird dann, wenn wir als Produkt-Team sogenannte „Geister“-Personas erstellen.

Falle 2: Geister-Personas

Wir als Produkt-Team treffen Annahmen über die Nutzer. Beispielsweise treffen wir uns in einem Design-Thinking Workshop mit ein paar Stakeholdern, erstellen brav Empathy Maps, entwickeln daraus Persona-Profile, um Geschichten über die Nutzer zu erzählen. Exzellent. Wir verfügen über ein gemeinsames Verständnis über unsere Nutzer und haben eine gemeinsame Basis um Design-Entscheidungen zu treffen. Vorsicht! Wir glauben alles über die Nutzer zu wissen, doch wir haben noch keine unserer Annahmen validiert, etwa durch Daten aus qualitativer User Research.

Auf diese Weise entstehen Geister-Personas, die uns durch die komplette Produktentwicklung hin verfolgen. Personas sollten daher immer auf zuverlässigen Daten beruhen. Sei es aus qualitativer Research oder quantitativer Research. UX Researcher sorgen mit entsprechenden Research-Methoden dafür, Sinn aus dem Datenchaos zu entwickeln. Starten wir mit Annahmen über unsere Nutzer, ist es von größter Bedeutung diese Annahmen mit „echten“ Daten zu validieren.

Falle 3: Elastic User

Wir als Produktteam beabsichtigen natürlich, dass wir mit unserem Produkt die Bedürfnisse der Nutzer befriedigen. Darüber herrscht Einigkeit, keine Frage. Jetzt ist es aber so, dass Timo ein anderes Verständnis über den Nutzer hat, als Freddy. Jedes Teammitglied hat ein unterschiedliches Konzept des Nutzers und seiner Bedürfnisse im Kopf. Kommt der Zeitpunkt Design-Entscheidungen zu treffen, entsteht der „Elastic User“. Am Elastic User wird gezogen und gezerrt, um die individuellen Konzepte bequem zu rechtfertigen und durchzusetzen.  So wird aus einem Nutzer mal ein „Power-User“, der durch seine Erfahrung mit komplexen und überladenen Dialogen gut umgehen kann, manchmal wird er zum „First-Time“-User, der unbedingt Wizards benötigt, um seine Tasks in einem Workflow abzuschließen. Auf diese Weise gewinnen wir als Produktteam die Freiheit, zu machen was wir wollen, mit dem Nachteil die Bedürfnisse und Ziele der „echten“ Nutzer ignoriert zu haben.

Conclusio

Personas helfen Produktteams bessere Design-Entscheidungen zu treffen. Dennoch fällt eine Persona nicht einfach vom Himmel, sondern sollte gewissenhaft und sorgfältig erstellt und am Leben erhalten werden. Ein guter Beginn ist es mit Annahmen zu Proto-Personas zu starten. Besser und unverzichtbar für gutes Persona-Gelingen ist es, die Annahmen zu validieren. Auf diese Weise entfalten Personas ihren größten Mehrwert und gängige Design-Fallen wie Elastic User, Geister-User oder Self-Referential-Design können erfolgreich umgangen werden.

Möchtest Du mehr erfahren über User Experience und Design Thinking?

Kontaktiere uns und lass uns austauschen: https://www.opitz-consulting.com/portfolio/software-development/user-centered-development.html

Spannende Links und Referenzen

[1] https://www.nngroup.com/articles/mental-models/

[2] http://www.jonkolko.com/projectFiles/scad/IACT315_03_MentalModelsPersonasScenarios.pdf  

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

%d Bloggern gefällt das: