Personas in a nutshell – Was sind Personas und wozu brauche ich diese?
Im Umfeld der agilen, verteilten Softwareentwicklung kommt es gerade im B2B-Kontext häufig zu dem Szenario, dass der Auftraggeber der einzige Ansprechpartner für den Entwicklungsdienstleister ist. Oft begründet sich dies durch die mangelnde Verfügbarkeit der Endnutzer, welche entweder örtlich vom Entwicklungsteam getrennt sind oder keine Zeit haben. Wenn der Nutzer nicht gerade nebenan sitzt, können Personas Abhilfe schaffen und den fehlenden Nutzerkontakt kompensieren.
Personas stellen prototypische Benutzer in Vertretung einer Benutzergruppe dar und verkörpern deren wichtige Eigenschaften und Bedürfnisse in Hinblick auf das geplante Produkt. Sie verdichten die Ergebnisse aus der Kontextanalyse, ersetzen jedoch die Nutzerforschung nicht. Die Ausgestaltung erfolgt in Poster-Form, möglichst „lebendig“ und realistisch, denn sonst ist die Persona nicht brauchbar. Generell entstehen Personas in frühen Projektphasen (Analyse und Planung) und werden dann über den gesamten Entwicklungszyklus hinweg als Soll-Ist-Vergleich verwendet. So wird es dem Design- und Entwicklungsteam ermöglicht, sich auf Nutzerbedürfnisse zu fokussieren. Bei Diskussionen dienen sie als Entscheidungsreferenz und stellen mit einer Frage wie „Würde Person x das verstehen?“ den Nutzer in den Vordergrund. Vor allem dem Product Owner helfen Personas bei der Bewertung von Ideen für neue Features.
Oft braucht es nicht nur eine Persona, sondern mehrere Personas, um die potentiellen Benutzer der Software abzudecken. Falls zu viele, eventuell auch im Widerspruch zueinander stehende Personas existieren, ist es hilfreich, diese in primäre und sekundäre Personas zu unterteilen. Das hilft, den Fokus auf die Zielnutzergruppe zu behalten und Entscheidungsalternativen zu gewichten.
Und welche Bestandteile werden nun für eine gute Persona benötigt?
Name: Ein realistischer Name, anhand dessen man die Persona identifizieren kann
Alter: Lässt Rückschlüsse auf die Einstellung der Persona zu
Bild: Ein Bild, egal ob fotografiert oder gezeichnet, damit die Persona realistischer wird
Persona-Typ: Die zugehörige Nutzergruppe / der Archetyp (z. B. Teenager, Hausfrau, Rentner)
Beruf: Funktion, Verantwortlichkeiten und Aufgaben
Technische Expertise: Allgemeine Computerkenntnisse, Technikaffinität, Kenntnisse über verwandte Produkte, Vorgängersysteme oder Konkurrenzprodukte
Charakter: Die persönlichen Einstellungen und Werte der Persona – Ist sie z. B. aufgeschlossen gegenüber Neuem?
Verhaltensmuster und Vorgehensweisen: Werte, Ängste, Sehnsüchte und Vorlieben
Ziele: Die wesentlichen Aufgaben, welche mit der neuen Anwendung zu bearbeiten sind
Bedürfnisse & Erwartungen: Anforderungen an den Umgang mit dem Produkt
Frustration: Typische Ärgernisse an Produkten generell, was also unbedingt zu vermeiden ist
Persona Template
Das Usability Team der Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation) hat auf Basis der Best Practices und eigener Erfahrungen ein Template zur Erstellung einer Persona entwickelt. Das Template ist kostenlos als PDF erhältlich: DOWNLOAD
Template zur Erstellung einer Persona
Mit dem Persona Template haben Sie die Möglichkeit, Ihre Software noch besser an Ihre potentiellen Nutzer anzupassen und verlieren nie den Blick auf das Wichtigste … denn wir wissen ja alle: „The user is always right.“
Vor längerer Zeit habe ich in einem Blogartikel unsere Design Prinzipien vorgestellt, nach welchen wir bei der Saxonia Systems (seit 03/2020 ZEISS Digital Innovation) nutzerfreundliche Software konzipieren und entwickeln. Im Rahmen der Entstehung unseres Custom Usability Index, mit dem der Erreichungsgrad der Usability eines Softwareprojekts gemessen werden kann, haben wir im Usability-Team diese Prinzipien noch einmal genau unter die Lupe genommen und auf 13 Oberkategorien erweitert, welche jeweils mehrere Usability-Aspekte umfassen. In diesem Artikel werden diese Kategorien und Aspekte genauer erläutert und durch Beispiele veranschaulicht.
Effektivität: Das Ziel erreichen. (Prinzip 1)
Die erste und somit wichtigste Regel ist die Einhaltung von Effektivität. Eine Anwendung soll dem Nutzer eine effektive Arbeitsweise ermöglichen, indem eine geeignete Funktionalität zur Erledigung seiner Aufgabe zur Verfügung gestellt wird. Der Nutzer wird nicht mit Informationen und Funktionen belastet, die für seinen Anwendungsfall unnötig sind. Entsprechend sollten Dialoge nur relevante oder häufiger benötigte Informationen enthalten. Jede zusätzliche Information lenkt den Nutzer von den wichtigen Inhalten ab, und es besteht die Gefahr einer Reduktion der relativen Sichtbarkeit.
Es gilt daher die zentrale Frage zu beantworten: Was ist wirklich die Aufgabe, die unterstützt werden soll? Eine gründliche Analyse der Arbeitsabläufe und deren Verständnis ist der Schlüssel, um die Aufgaben und Ziele der Nutzer zu verstehen und die Effektivität ihrer Umsetzung beurteilen zu können.
Abbildung 1: Wie viel Information ist notwendig, um die Uhrzeit anzuzeigen?
Effizienz: Schnell zum Ziel kommen. (Prinzip 2)
Ebenfalls besondere Beachtung verdient die Optimierung von Effizienz. Dem Nutzer soll es ermöglicht werden, eine Aufgabe in minimaler Zeit zu erledigen. Zugleich benötigt die Anwendung nur minimale Zeit zur Reaktion und zur Ausführung einer Aktion. Dieses Prinzip bezieht sich also auf die Arbeitsgeschwindigkeit von Nutzer und System. Anhaltspunkte dafür, dass der Nutzer nicht effizient arbeiten kann, sind beispielsweise für ihren Zweck unpassend eingesetzte Interface-Widgets, fehlende Default-Werte, unzutreffende Suchergebnisse und hochauflösende Bilder, welche eine schnelle Internetverbindung voraussetzen.
Hinweise auf eine geringe System-Effizienz sind hingegen verzögerte Reaktionen auf Eingaben in Form von „ruckelnden“ Mauszeigern, langsamen Interface-Widgets und fehlendem Feedback.
Steuerbarkeit: Der Nutzer hat die Macht! (Prinzip 3)
Der Nutzer hat, unter Beachtung seiner Berechtigungen im System, die Kontrolle über alle Aktionen. Er kann Vorgänge abbrechen, pausieren und zu einem späteren Zeitpunkt fortsetzen. Er hat die Möglichkeit, eine Aktion rückgängig zu machen und ggf. einen neuen Anlauf zu starten, falls das Ergebnis nicht zufriedenstellend war. Für die Steuerung der Anwendung hat der Nutzer weiterhin die Möglichkeit, entsprechend seinen persönlichen Anforderungen zur Maus alternative Eingabegeräte wie Tastatur, Screenreader und Braillezeile zu nutzen. Werden diese Punkte nicht eingehalten, führt das zu einer gesteigerten Frustration des Nutzers.
Individualisierbarkeit: Alles passt zum Nutzer. (Prinzip 4)
Die Anwendung soll flexibel genug sein, um verschiedene Herangehensweisen zur Erledigung einer Aufgabe zu unterstützen. Der Nutzer kann das System zudem an seine Vorerfahrungen, Kultur und Bedürfnisse anpassen, z.B. durch Änderung der Schriftgröße, Änderung von Default-Einstellungen und die Festlegung eigener Shortcuts. Ein gutes Beispiel für die Berücksichtigung von Individualisierbarkeit ist das Online-Portal http://www.elster.de/, über das man Steuererklärungen webbasiert erfassen und abgeben kann. Nach dem Login wird der Nutzer gefragt, welcher Benutzergruppe er angehört, um die Anwendung anschließend auf dessen Bedürfnisse anzupassen:
Abbildung 2: Individualisierbarkeit bei ELSTER Online
Konsistenz: Alles passt zusammen. (Prinzip 5)
Die Bedienung der Anwendung soll in jedem Aspekt den Erwartungen des Nutzers entsprechen und allgemeine Konventionen (Plattformen, Styleguides etc.) befolgen. Einen Beitrag dazu leistet die einheitliche Verwendung von Begriffen, Icons und Layouts innerhalb der Anwendung und zwischen Produkt-Familien. Auch Prozessstrukturen folgen einem einheitlichen Prinzip. Durch die Einhaltung von Konsistenz kann vom Nutzer ein einmal erlerntes Verhaltensmuster wiederverwendet werden. Zum Beispiel weiß (und erwartet) der Nutzer im Verlauf der Benutzung der Anwendung(en), dass sich der Button zum Schließen eines Dialogfensters immer oben rechts in der Ecke befindet. Wechselt er jedoch auf das Betriebssystem Mac OS X, muss er sich gänzlich neu eingewöhnen. Anhaltspunkte dafür, dass sich eine Anwendung nicht erwartungskonform und konsistent verhält, sind überraschte bis verwirrte Nutzer und z.B. die Verwendung verschiedener Begriffe für ein und dieselbe Funktion.
Design und Layout: Auf den ersten Blick verständlich. (Prinzip 6)
Dieses Prinzip umfasst alle Aspekte der visuellen Gestaltung einer Anwendung. Demnach sollen die Art der Gruppierung und Anordnung der GUI-Elemente sowie der bewusste Einsatz von Farbe den Nutzer bei der Erkennung von Zusammenhängen unterstützen. Informationen und Komponenten werden dem Nutzer generell so präsentiert, dass er sie wahrnehmen und Textinhalte gut lesen kann. Gegenanzeigen hierfür sind z.B. unklare Zuordnungen von Labels zu Datenfeldern, winzige Schriftarten und ein schwacher Farbkontrast zwischen Vorder- und Hintergrund.
Sprache: Die Sprache des Nutzers sprechen. (Prinzip 7)
Die Anwendung sollte grundsätzlich die Sprache des Nutzers widerspiegeln und dessen Denkweise entsprechen. Textelemente sollten daher eindeutig formuliert sein und einen für die Zielgruppe verständlichen Wortschatz gebrauchen. Dennoch werden Dinge oft systemtechnisch formuliert statt in der Sprache der Anwender. „Bestes“ Beispiel dafür sind Fehlermeldungen mit einem Detailgrad, in dem sie zwar für den Systementwickler von Wert sind, dem Nutzer aber nicht weiterhelfen. Um dies zu vermeiden, sollte der fachliche Sprachschatz der Endnutzer genau analysiert werden.
Sichtbarkeit: Der Nutzer erkennt seine Möglichkeiten. (Prinzip 8)
Damit der Nutzer seine Aufgabe erledigen kann und nicht die Orientierung verliert, muss er jederzeit wissen, wo in der Anwendung er sich befindet und welche Aktionen wie ausgeführt werden können. Auch weiß er jederzeit, in welchem Status sich das System gerade befindet. Das Hauptmenü sollte dem Nutzer daher dessen aktuelle Position anzeigen und bspw. über eine Breadcrumb-Navigation den Weg dorthin nachvollziehbar machen. Relevante Objekte, Funktionen und Optionen sollten sichtbar sein und den Nutzer das Gesuchte direkt finden lassen. Er soll beurteilen können, welche Folgen eine Aktion haben wird.
Feedback: Der Nutzer erfährt, was los ist. (Prinzip 9)
Das System sollte jederzeit auf Eingaben des Nutzers reagieren und ihn aktiv über Ereignisse informieren. Bei einem aufgetretenen Fehler sollte eine entsprechende Meldung dem Nutzer die Ursache des Fehlers aufzeigen und ihm, sofern möglich, einen Lösungsvorschlag unterbreiten. Weist die Anwendung in Sachen Feedback Defizite vor, ist dies beispielsweise bei einer komplexeren Operation an einem fehlenden Spinner-Icon ersichtlich und Nutzer-Eingaben werden gefühlt vom System ignoriert. Der Nutzer nimmt wahr, dass die Anwendung „hängt“.
Lernförderlichkeit: Leicht zu lernen. (Prinzip 10)
Das System sollte den Nutzer beim Kennenlernen der Benutzungsoberfläche unterstützen und ihn zum Ausprobieren von ihm unbekannten Funktionen ermutigen, ohne dass dies negative Auswirkungen für den Nutzer mit sich bringt. Vor allem in der ersten Phase der Benutzung sollte der Nutzer bei komplizierten Aktionen unterstützt und so mögliche Fehlschritte eingeschränkt werden. Hier helfen kurze Tutorials und beschreibende Texte. Eine Möglichkeit zum experimentellen Lernen bietet weiterhin ein Probemodus, d.h. ein gesonderter Testbereich in der Anwendung, in dem alle Funktionen ohne Konsequenzen ausprobiert werden können. Durch den Probemodus wird der Nutzer am System geschult und lernt den Umgang mit dem System, ohne einen Prozess vollständig durchführen zu müssen.
Hilfe und Dokumentation: Hilfe, die hilft. (Prinzip 11)
Hilfesysteme sollen leicht auffindbar bzw. möglichst in die Interaktion eingebettet sein. Zu eingebetteten Hilfen zählen Tooltipps, Platzhalter, kurze Hilfetexte und Assistenten. Ist dies nicht hinreichend, sollte die Wahl auf kontextuelle Hilfen wie einem Hilfe-Panel, Einstiegsseiten und Suchfunktion fallen. Zu beachten ist, dass die Hilfesysteme dem Nutzer nur dann eine Unterstützung sind, wenn sie sich auf die Aufgabe des Nutzers beziehen und konkret auszuführende Schritte zur Lösung des Problems auflisten.
Fehlertoleranz: Nutzerfehler verzeihen und vermeiden. (Prinzip 12)
Das System sollte von vornherein so gestaltet sein, dass der Nutzer aktiv vor Fehlern bewahrt wird, beispielsweise indem unzulässige Funktionen deaktiviert werden und die Einschränkung zusätzlich begründet wird. Passiert es doch einmal, sollten fehlerhafte Eingaben oder Aktionen vom System erkannt werden. Im Falle von Eindeutigkeit behebt das System den Fehler dann, wenn möglich, selbstständig. Gibt es mehrere Möglichkeiten, werden alternative Korrekturvorschläge aufgezeigt. Niemals hingegen darf der Fehler zum Datenverlust oder gar Systemabsturz führen.
Nutzungsgefühl (UX): Die Software fühlt sich gut an. (Prinzip 13)
Ein Aspekt, den wir bisher nicht berücksichtigt haben, ist die User Experience (abgekürzt UX). Das sogenannte Nutzungsgefühl resultiert aus dem Gesamterlebnis des Nutzers mit der Anwendung und setzt sich zusammen aus der tatsächlichen Nutzung, der Erwartung des Nutzers und der Vorerfahrung mit anderen Systemen. Die Anwendung vermittelt dem Nutzer ein Gefühl von Sicherheit und Zuverlässigkeit, macht Spaß und ist zweckdienlich. Das System begeistert den Nutzer, indem bestimmte Erwartungen nicht nur befriedigt, sondern auch übertroffen werden. Prinzip 13 wird also zum Großteil dadurch erfüllt, dass die zuvor genannten Prinzipien eingehalten werden. Eine langsame, inkonsistente Anwendung mit vielen Fehlermeldungen und Abstürzen wird hingegen nicht zur Zufriedenheit des Nutzers beitragen. Entsprechend sollte sich die Software immer auf dem aktuellen Stand der Technik befinden und aktuelle Steuerparadigmen unterstützen.
Abschluss
In diesem Blogbeitrag wurden 13 wichtige Prinzipien zur Erreichung einer nutzerfreundlichen, zufriedenstellenden Software vorgestellt. Zu beachten ist dabei, dass es keine einzig wahre, benutzungsfreundliche Lösung gibt. Wie gut eine Anwendung bedienbar ist, hängt immer von dem konkreten Anwendungsfall und der Nutzergruppe ab. Es ist daher zu empfehlen, die Bedürfnisse der Nutzer genau zu analysieren und sie durch Nutzertests einzubeziehen.
