Usability-Inspektion und Variationen von Evaluationen

Transkript

1 Universität zu Köln Historisch-Kulturwissenschaftliche Informationsverarbeitung User Interfaces und ihre Evaluierung, WS 2012/13 Dozent: Prof. Dr. Thaller Usability-Inspektion und Variationen von Evaluationen Kapitel 26 Inspections of the User Interface und Kapitel 27 Variations and More Comprehensive Evaluations aus D. Stone et al.: User Interface Design and Evaluation Referat von Stefan Grund

2 - Damit die Nutzer bei einer,user observation nicht auf allzu große Probleme stoßen, ist es empfehlenswert vorher eine,inspection of the user interface ( deutsch: Usability-Inspektion) durchzuführen. - Bei einer Usability-Inspektion wird ein System bzw. dessen User-Interface auf einen Katalog von Richtlinien, auch Heuristiken genannt, hin überprüft. Daher wird diese Methode auch,heuristic inspection oder,heuristic evaluation genannt. Screenshot: usability-artikel/usability-test-inspektion/

3 - Zunächst müssen die Richtlinien gewählt werden, auf deren Einhaltung das System hin überprüft werden soll. z.b. Style Guide eines Unternehmens, (inter-)nationale Standards,... - Problem: Richtlinienkataloge übersehen oft einzelne Problemzonen. - Lösung z.b.: Nielsen s Heuristics - Häufig wird daher auf die Heuristiken zurückgegriffen, die der Usability-Experte Jakob Nielsen 1990 vorgestellt hat ( Ten Usability Heuristics auf Nielsens Webseite: - Mithilfe dieser Heuristiken sollen sich möglichst viele (potentielle) Usability-Probleme auffinden lassen, die spätere reale Nutzer bei der Verwendung eines Systems haben könnten.

4 Nielsen s Ten Usability Heuristics 1. Visibility of system status Das System sollte den Benutzer zu jedem Zeitpunkt und in angemessener Zeit mitteilen, womit es sich gerade beschäftigt. 2. Match between system and the real world Das System sollte die Sprache des Benutzers sprechen, also weniger systemorientierte Meldungen, insbesondere keine (Fehler-)Codes ausgeben, sondern den Konventionen der realen Welt folgen. 3. User control and freedom Da es bei der Benutzung des Systems zu Fehlern kommt, sollte es immer einen Notausgang geben, um Unerwünschtes rückgängig zu machen. Undo und Redo sollten unterstützt werden. 4. Consistency and standards Für Aktionen und Situationen, die dieselbe Sache beschreiben, sollten einheitliche Terminologien verwendet werden. Plattformkonventionen sollten eingehalten werden. 5. Error prevention Ein umsichtiges Design, welches Fehlern vorbeugt, bevor sie auftreten können, ist besser als eine gute Fehlermeldung.

5 6. Recognition rather than recall Objekte, Aktionen und Optionen sollten immerzu sichtbar sein. Der Benutzer soll sich nicht an jeden Arbeitsschritt erinnern müssen; Instruktionen sollten erreichbar sein, wann immer sie gebraucht werden. 7. Flexibility and efficiency of use Vor allem für erfahrenen Anwender sollte die Möglichkeit bestehen, Arbeitsschritte zu beschleunigen und anzupassen. 8. Aesthetic and minimalist design Irrelevante Informationen sollten ausgeblendet werden, da jede zusätzliche Information im Wettbewerb mit den relevanten Informationen steht und deren Sichtbarkeit vermindert. Dargestellte Informationen sollten so kurz und gehaltvoll wie möglich sein. 9. Help users recognize, diagnose, and recover from errors Fehlermeldungen sollten verständlich formuliert sein (keine Fehlercodes!), das Problem präzise beschreiben und Lösungen anbieten. 10. Help and documentation Zwar ist es besser, wenn ein System ohne Dokumentation verwendet werden kann, dennoch sollten (nicht zu lange) Hilfe-Dokumente angeboten werden. Diese sollten durchsuchbar sein, zielgerichtet auf die Arbeitsschritt des Nutzers sein und Schritt-für-Schritt-Anleitungen bereitstellen.

6 - Anhand dieser Heuristiken soll dann ein,inspector ( deutsch: Gutachter) überprüfen, inwieweit sich die Umsetzung des UI daran hält. - Gutachter sind idealerweise Experten für Mensch-Computer-Interaktion, die sich mit dem Anwendungsgebiet des überprüften Systems auskennen. Aber auch: Experten für das Anwendungsgebiet des Systems (dies können also auch reale oder repräsentative Nutzer des Systems sein) User-Interface-Designer oder Entwickler Nicht-Experten, nachdem diese in die heuristische Evaluierung eingewiesen wurden - Laut Nielsen ist eine Gruppe von bis zu fünf Gutachtern ausreichend, da das Kosten-Nutzen-Verhältnis bei mehr Gutachtern kaum noch steigt. - Da verschiedene Gutachter evtl. unterschiedliche Bewertungskriterien haben, empfiehlt es sich diese zunächst gemeinsam zu diskutieren. Nielsen empfiehlt z.b. folgende Bewertungsskala: 0 = I don't agree that this is a usability problem at all 1 = Cosmetic problem only: need not be fixed unless extra time is available on project 2 = Minor usability problem: fixing this should be given low priority 3 = Major usability problem: important to fix, so should be given high priority 4 = Usability catastrophe: imperative to fix this before product can be released

7 Durchführung einer heuristischen Evaluierung - Der Gutachter benutzt das System; hier können, ähnlich wie bei der,user observation, Aufgaben gestellt werden, die der Gutachter durchführen muss (was vor allem für unerfahrene Gutachter hilfreich sein kann). - Die Usability-Fehler, die der Gutachter dabei bemerkt, werden auf einem speziellen Fragebogen notiert und den jeweiligen Heuristiken, die sie verletzen, zugeordnet. - Der Gutachter kann bereits selbst eine Fehlerbeschreibung formulieren. ( Im Gegensatz zur,user observation, bei der die von den Nutzern gefundenen Fehler erst während der anschließenden Analyse ausformuliert werden.) - Abschließend sollten die Usability-Fehler hinsichtlich der Notwendigkeit ihrer Behebung priorisiert werden und endgültige, genaue Handlungsempfehlungen zur Verbesserung des System gegeben werden.

8 Beispiel eines Formulars zu Daten-Sammlung und -Analyse bei einer Heuristischen Inspektion

9 Beispiel aus einem,heuristic Evaluation Report für itunes

10 Vorteile und Einschränkungen von Usability-Inspektionen + Usability-Inspektionen sind günstiger als Usability-Tests und können bereits im Vorfeld zu den Nutzertests viele Fehler aufzeigen. + Die Gutachter schlagen häufig gleich Lösungen für die gefundenen Probleme vor. Da bei der Usability-Inspektion keine realen Nutzer anwesend sind, können einige Fehler auf die diese in ihrem normalen Workflow stoßen, nicht gefunden werden. Die Gutachter haben jeweils eigene Design-Vorlieben und Vorkenntnisse, die ihre Bewertungen beeinflussen. Die Ergebnisse sind abhängig davon, inwieweit sich die Gutachter mit User Interfaces und dem Anwendungsgebiet des überprüften Systems auskennen. Usability-Inspektionen sollten nicht anstelle von Usability-Tests, sondern (im Vorfeld) ergänzend zu diesen durchgeführt werden.

11 Unterschiede zwischen,user observation und,heuristic inspection - es geht um die Meinung und Probleme der Nutzer - es geht darum, dass ein Gutachter überprüft, inwieweit Richtlinien eingehalten wurden - Nutzerverhalten wird beobachtet - Gutachter beobachtet sich selbst dabei, wie er Arbeitsschritte, die von einem typischen Benutzer ausgeführt würden, durchführt - Nutzer kommentiert seine Arbeitsschritte und Klicks - Gutachter stellt sich Fragen wie Ist das ein gut und einfach formulierter Dialog? es geht um die Effizienz des User Interface es geht um die Fehler im User Interface

12 Auszug aus dem Corporate-Design-Handbuch der Universität zu Köln

13 Varianten der heuristischen Evaluierung: - Guideline Reviews Anstelle von Nielsens Heuristiken werden eigene Richtlinien oder bestimmte, etwa firmenweite Style Guides verwendet. - Participatory Heuristic Evaluations Eine vom IBM-Mitarbeiter M.J. Muller und seinen Kollegen erweiterte Version von Nielsens Heuristiken, mit der durch genauere Erklärungen auch normale Nutzer die Usability-Inspektion durchführen können. - Standards Inspections Die Usability-Inspektion findet anhand eines bestimmten Standards statt, z.b. ISO 9241, der die Richtlinien der Interaktion zwischen Mensch und Computer beschreibt. - Cognitive Walkthrough Ein Usability-Experte versetzt sich in einen hypothetischen Benutzer und analysiert konkret vorgegebene Handlungsabläufe.

14 Grundelemente einer Evaluierung nach der britischen Wissenschaftlerin Denise Whitelock - Observe: Benutzer werden beim durchführen von Arbeitsschritten beobachtet; der Gutachter beobachtet während der Überprüfung seine eigenen Arbeitsschritte. - Compare: Ein User Interface wird mit einem bestimmten Regelwerk, das ein gutes Interface beschreibt, verglichen. - Listen: Es wird sich angehört, was die Nutzer oder der Gutachter über ein User Interface sagen. Dies kann sowohl formell, als auch informell ablaufen. Auch das Lesen von Fragebögen, die Nutzer oder Gutachter ausgefüllt haben, wird hierzu gezählt. - Measure: Das Ziel der Evaluierung ist nicht nur festzustellen, ob ein User- Interface-Design gut oder schlecht ist, sondern auch wie gut oder wie schlecht es ist. Das heißt, dass während der Evaluation quantitative Daten gesammelt werden müssen. So kann z.b. die Zeit gestoppt werden, die ein Nutzer braucht, um eine bestimmte Aufgabe zu erfüllen oder die Anzahl der aufgetretenen Fehler während einer Sitzung wird festgehalten.

15 Grundelemente der Evaluierung bei,user observations und,heuristic inspections Nächte Folie: Variationsmöglichkeiten bei diesen vier Grundelementen

16

17 Weitere Varianten -,user observation als Videokonferenz - Online-Umfrage - Focus Groups, in denen Nutzer mit einem Moderator ihre Meinungen und Hoffungen für ein (meist zukünftiges) Produkt diskutieren - Card Sorting: Nutzer gruppieren oder priorisieren Karten mit Begriffen nützlich um z.b. Ober- und Unterkategorien zu erstellen Evaluations without People Accessibility Checkers und HTML-/CSS-Validators Usability Checkers: Tools um eine Webseite bspw. nach fehlerhaften Attributwerten, Broken Links usw. zu durchsuchen Hybrid-Methoden, meist kommerzielle Angebote

18 Evaluationen haben verschiedene Ziele Es wird unterschieden zwischen formativen Evaluationen, die während des Entwicklungsprozesses durchgeführt werden, und summativen Evaluationen, die nach Fertigstellung eines System durchgeführt werden. Der Usability-Experte Jeffrey Rubin unterscheidet zudem zwischen: Exploratory Evaluations Evaluation, bei der bereits frühzeitig während der Entwicklung Nutzer befragt werden, in dem diesen ein Prototyp gezeigt wird. Validation Evaluations Evaluation, die nach Fertigstellung des System durchgeführt wird, um herauszufinden, inwieweit sich das User Interface des fertigen Systems an die (bereits vorher) festgelegten Richtlinien hält. Assessment Evaluations Werden zur Mitte des Entwicklungsprozesses durchgeführt, nachdem das Feedback aus den Exploratory Evaluations bereits umgesetzt wurde. Hier werden die quantitativen Ergebnisse erstmals wichtig und werden festgehalten. Comparison Evaluations Können zu jedem Zeitpunkt durchgeführt werden. Bei einem Vergleich von z.b. zwei unterschiedlichen Designs bietet es sich jedoch an, diese so früh wie möglich evaluieren zu lassen.

19 Bei,Comparison Evaluations ist zudem zu beachten: - Soll der Vergleich,within subjects oder,between subjects durchgeführt werden, d.h.: Sollen die Nutzer beide User-Interface-Versionen testen (,within subjects ) oder soll jeweils eine Gruppe eine Version und eine andere Gruppe die andere Version (,between subjects ) testen? - Es lässt sich zumeist nicht genau feststellen, ob Version A besser als Version B ist. Vielmehr sind meist einige Bestandteile von Version A besser als bei B und andere Bestandteile von Version B besser als bei A. -,Identical twins -Problem: Während der Auftraggeber die kleinsten Unterschiede beider Versionen genau kennt, sehen sie für den Nutzer meist nahezu identisch aus.

20 Quellen - Nielsen, Jakob: How to Conduct a Heuristic Evaluation. URL: - Nielsen, Jakob: Severity Ratings for Usability Problems. URL: - Nielsen, Jakob: Ten Usability Heuristics. URL: