Usability Evaluation

Usability Evaluation

Brainstorming Wie könnte die Usability einer Applikation evaluiert werden? Wer evaluiert? Was wird evaluiert? Wie und wann wird evaluiert? Wo wird evaluiert?

Überblick Ziele und Arten von Software-Evaluation Expertentests Walkthrough Experteninspektion und Heuristische Evaluation Benutzertests Usability Lab/Tests Klassifizierung von Erhebungsmethoden Beobachtung Lautes Denken (Thinking Aloud) Eye Tracking Meinungsbasierte Evaluationsmethoden Fallstudie zu Usability Evaluierung im medizinischen Bereich

Teil des Software Engineerings Usability-Engineering ergänzt das klassische Software-Engineering http://www.userfocus.co.uk/resources/getstencil.html

Ziele von Software-Evaluation Welche Lösung ist besser? Alternative Softwaresysteme oder Designalternativen werden miteinander verglichen, um das am besten geeignete auszuwählen Wie gut? In welcher Ausprägung wurden vorab definierte Usabilityziele oder Normen erreicht; zielt auf Bewertung eines Softwaresystems ab Worin schlecht? Schwachstellen und Gestaltungsvorschläge für eine Systemweiterentwicklung werden gesucht, Gründe identifizieren, Anstoß für Verbesserungen

Summative und formative Evaluation Formative Evaluation Begleitende Evaluation Ergebnisse haben Konsequenzen für die weitere Entwicklung einer Software Schwerpunkt ist die Verbesserung und Qualitätsentwicklung eines Produktes Summative Evaluation Evaluation wird an einem (fast) fertigen System durchgeführt und ein globales Urteil abgegeben

Expertentests Expertentests Produkt oder Entwurf der Benutzungsschnittstelle Ergonomie-Experten beurteilen aufgrund der Normen und ihrer Erfahrung Experten sollten die zu erledigenden Aufgaben kennen Vorteil Erfahrene Tester entdecken viele nicht-offensichtliche Einschränkungen Nachteil Schlechte Bewertbarkeit und Reproduzierbarkeit von Erfahrung Experten sind nicht die Nutzer Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

Walkthrough Inspektionsmethode, bei der ein bzw. mehrere Experten ein System beurteilen Evaluationsgegenstand: Systementwurf, ein Prototyp oder ein fertiges System Aufgabenabläufe in Form von Bildschirmansichten präsentiert Ohne User-Einbindung, möglichst früh Pluralistic Walkthrough: verschiedene Experten Cognitive Walkthrough: kognitive Verhalten des Users, wenn er die Aufgabe versuchen würde zu bearbeiten, simuliert Nachteil: fehlende Möglichkeit zur eigenständigen Exploration

Experteninspektion & Heuristische Eval. Software wird von Spezialisten begutachtet Genaue Kenntnisse über Usability, Nutzer und Aufgabenanforderungen Oftmals mit Hilfe von detaillierten Kriterienkatalogen durchgeführt Heuristische Evaluation Spezielles Beispiel der Experteninspektion durch Heuristiken angeleitet, die besonders benutzerfreundliche Software beschreiben

Beispiel zu Katalogen: EVADIS ΙΙ Software nach den Kriterien der ISO 9241-10 bewertet

Beispiel: 10 Heuristiken von Nielsen und Mack (1994) + Aspekte f. Mobile Geräte 1. Einfacher und natürlicher Dialog 2. Software spricht die Sprache des Benutzers 3. Gedächtnisbelastung des Benutzers ist minimal 4. Konsistenz (dieselbe Aktion führt immer zum selben Ergebnis) 5. Feedback (Rückmeldung des Systemstatus an den Benutzer) 6. Klar gekennzeichnete Ausstiegspunkte (Möglichkeiten zum Beenden von Aktionen) 7. Shortcuts ( Abkürzungen für häufig benötigte Operationen) 8. Gute Fehlermeldungen 9. Fehlervermeidung (Software ist so gestaltet, dass Fehler erst gar nicht auftreten) 10. Hilfe und Dokumentation 11. Ergänzung: Ergonomie

1 Einfache und natürliche Dialoge Ästhetik und minimalistisches Design Jegliche Information sollte in einer natürlichen und logischen Ordnung erscheinen. http://www.chip.de/news/neuer-google-play-store- Version-5-gibt-Ausblick-auf-Android-L_73255887.html

2 Ausdrucksweisen der Benutzenden Übereinstimmung zwischen dem System und der realen Welt Das System sollte die Sprache der Benutzer sprechen und systemorientierte Terminologien vermeiden. https://www.youtube.com/watch?v=g6ghsd3mfdu

3 Minimale mentale Belastung Recognition: Wiedererkennen statt sich erinnern Das Kurzzeitgedächtnis eines Benutzers ist begrenzt. Deshalb sollten sie sich nicht an Informationen erinnern müssen, die in einem ganz anderen Bereich des Dialogs von Bedeutung waren.

4 Konsistenz Konsistenz und Standards Benutzer sollten sich nicht über unterschiedliche Wortwahl für gleiche Situationen oder Aktionen wundern müssen.

5 Rückmeldungen Sichtbarkeit des Systemstatus Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.

6 Klare Auswege Benutzerkontrolle und Zufriedenheit Ein System sollte Benutzer nie in Situationen geraten lassen, aus denen sie nicht wieder zurückfinden. Bsp.: Button beim Play Store alles grün (Spiele) mit Pfeil kommt man wieder zurück Home Button

7 Abkürzungen Flexibilität und Effizienz der Benutzung Features, die es einfach machen ein System zu erlernen, sind für den erfahrenen Benutzer häufig lästig. Gut gewählte Abkürzungen, die der Anfänger nicht sieht, können in ein System aufgenommen werden, so dass beide Nutzergruppen zufrieden sind.

8 Gute Fehlermeldungen Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern Gute Fehlermeldungen sind defensiv, präzise und konstruktiv. Präzise Fehlermeldungen geben dem User genaue Informationen über die Ursache des Problems.

9 Fehlervermeidung Prevention: Fehlervermeidung Besser als gute Fehlermeldungen ist ein gutes Design, welches das Eintreten von Fehlern erst gar nicht zulässt.

10 Hilfe und Dokumentation Hilfe und Dokumentation Jede kleine Website sollte ohne Hilfe auskommen.

Ergonomie Physikalische Interaktion und Ergonomie Größe, Form und UI Elemente des Gerätes sollen der natürlichen Handhaltung entsprechen Physikalische Buttons für die Hauptfunktionen in erkennbarer Position

Benutzertests Charakteristika von Benutzertests Echte Anwender testen Ausgewählte, typische spätere Benutzer (vgl. Persona ) Prototyp oder (fast) fertiges Produkt Möglichst vollständige Arbeitsschritte (vgl. Aufgabenanalyse) Interviews oder/und Fragebögen Vorteil Finden fehlende Daten oder Funktionen, nicht passende Abläufe Nachteil Benutzer sind nicht genormt (Ergebnis hängt auch von der Tagesverfassung ab) Ergebnisse sind oft nicht genau reproduzierbar Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

Beispiel: Mobiltelefon (Video) http://de.youtube.com/watch?v=5ijirlvwgeo

und wo kann getestet werden? An Ort(en) und Stelle(n): Feld-Studie Remote im Labor Vorsicht: Mobile Applikationen müssen auch im realen Anwendungskontext getestet werden, nicht nur unter Laborbedingungen, da die Ergebnisse nicht ausreichend übertragbar sind.

Usability Lab http://www.sensible.com/secondedition/index.htm l

Usability Lab Anwender testen Software unter reproduzierbaren Bedingungen Aktionen werden aufgezeichnet Tastatur- und Maus-Aktionen. Bildschirminhalt wird dokumentiert Benutzer wird gefilmt Methode des lauten Denkens Äußerungen, Mimik, Gesten dokumentieren Physiologische Werte (Stresslevel) Puls, Blutdruck oder Herzrhythmus (EKG) Orientierung des Benutzers Eye-Tracking-Systeme Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

Usability Lab Bedingungen Aufwändige technische Ausstattung Software-Hersteller Dienstleister Reproduzierbare Bedingungen An einem echten Arbeitsplatz nicht machbar Keine Störungen Räume sollten gegen äußere Störungen isoliert sein Normale Atmosphäre (Büro oder Zuhause) Überlastetes Firmennetz Klingelnde Telefone Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

Usability Lab - Nutzen Software-Umgebung des Kunden Aufwändig nachzustellen Eher Standardumgebungen, -daten und -aufgaben Vergleichbarkeit gegeben Quantitative Daten Klicks, Anschläge und Zeitintervalle Entwickler erleben echte Anwender mit ihrer Software Live oder per Videoaufzeichnung Video (Windows 8) http://www.youtube.com/watch?v=v4botbv9_nu Video (whatusersdo) http://www.youtube.com/watch?v=h-mneoirsny Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

Evaluations-Tools für mobile HCI Touch Heatmaps Screencasts In-App Analytics Statistiken zur Verwendung von Funktionen, Verweildauer, etc. AppSee: http://www.appsee.com UXCam: https://www.uxcam.com http://www.appsee.com

Usability-Test: Durchführung 1 1. Motivation -> Startpunkt Warum wird das System nicht so verwendet wie geplant? 2. Zielgruppe analysieren 3. System kennen lernen 4. Spezifizieren wo und wie getestet wird (Testdesign) 5. Aufgaben definieren 6. Testpersonen rekrutieren 7. Material für das Testen zusammenstellen; Vorgehen definieren 8. Durchführungen der Tests (Wichtig: Briefing) 9. Auswertung und Aufbereitung der Ergebnisse (Ranking) 10. Präsentation

Usability-Test: Durchführung 2 Tester ist stiller Beobachter Ziel: Aufgabe lösen (evtl. zunächst Exploration) Zuerst leichte Aufgaben Sicherstellen ob es auch für die Testperson lösbar ist Hinweise: Nach einer gewissen Zeit Wenn Testperson nicht mehr weiter weiß Zeit nicht vergessen Insgesamt nicht länger als 1.5 Stunden

Was ist eine gute Aufgabe? Relevant für die Zielgruppe und realistisch Relevant für den Erfolg des System Soll nicht zu allgemein aber auch nicht zu spezifisch sein Hat einen eindeutigen Endpunkt Lösungswege sollen eindeutig sein Soll als ein wirklichkeitsnahes Szenario beschrieben werden Nicht länger wie nötig, aber mit allen nötigen Infos In Benutzersprache und verständlich

Usability Test Beispiel Zielperson: Jugendliche System: Webportal Vorinterview Erfahrungen mit ähnlichen Portalen Erwartung vom Portal Aufgaben mit jeweils Abschlussfragen Zufriedenheit mit dem System Verbesserungsvorschläge Abschlussinterview Allgemeine Eindrücke Gut bzw. schlecht gefallen Orientierung Erwartungen erfüllt?

Quantitative/ Qualitative Daten Quantitative Daten In Zahlen messbare Ergebnisse Dauer der Bearbeitung, Anzahl Klicks, Anzahl Fehler Befindlichkeit oder Zufriedenheit der Benutzer Qualitative Daten Von Beobachtungen / Konversation Sprachlich ausgedrückte Ergebnisse Allgemeiner Eindruck Probleme bei der Interaktion Mixed Methode Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

Beobachtung von trainierten Beobachtern durchgeführt eignet sich besonders gut, wenn Benutzer nicht gut verbalisieren können Beobachtung im Nutzungskontext auch Arbeitsumstände werden miteinbezogen Beobachtungen im Labor eine mit dem Verhalten des Nutzers zeitgleiche Beobachtung ist schwierig wegen Fülle an Informationen meist retrospektiv mit Videoaufzeichnungen durchgeführt

Lautes Denken (Think Aloud Protocols) Benutzer werden gebeten, alle Gedanken und Überlegungen, die im Zusammenhang mit der Aufgabenlösung stehen, zu verbalisieren präaktional periaktional postaktional -> Videokonfrontation Probleme: schwierig, komplexe, innere Abläufe zu verbalisieren künstliche Situation Beispiel: http://de.youtube.com/watch?v=l7opr2atglm

Thinking Aloud Beispiel 1 Runtastic ist eine Sport-Tracking-App Aufgabe: Du verwendest diese App für herzfrequenzbasiertes Lauftraining. Bei der letzten Ruhepulsmessung hast du festgestellt, dass dieser nun 10 Schläge langsamer ist als bei der Messung zuvor. Nun möchtest du die Herzfrequenzzonen in der App ändern.

Thinking Aloud runtastic start screen Aufgabe Ändern der Herzfrequenzzonen Thinking aloud Alle Gedanken laut aussprechen

Thinking Aloud runtastic side menu Aufgabe Ändern der Herzfrequenzzonen Thinking aloud Alle Gedanken laut aussprechen

Thinking Aloud runtastic settings Aufgabe Ändern der Herzfrequenzzonen Thinking aloud Alle Gedanken laut aussprechen

Thinking Aloud Beispiel 2 Runtastic ist eine Sport-Tracking-App Aufgabe: Während du läufst, stehen dir einige Quick-Settings zur Verfügung. Diese werden durch Symbole repräsentiert. Welche Funktion könnte sich hinter den Symbolen verstecken?

Thinking Aloud Beispiel 2 runtastic icons Aufgabe Was könnte dieses Symbol bewirken? Thinking aloud Alle Gedanken laut aussprechen

Thinking Aloud Beispiel 2 runtastic icons Aufgabe Was könnte dieses Symbol bewirken? Thinking aloud Alle Gedanken laut aussprechen

Eye tracking (Video) http://de.youtube.com/watch?v=lo_a2cfbugc

Meinungsbasierte Evaluationsmethoden Wenige standardisierte mündliche Interviewmethoden Fragebögen im Bereich der Software Usability vorrangig zum Ausfüllen durch Benutzer und nicht unbedingt durch Experten Operationalisierung der 7 Kriterien der Isonorm 9241/10: Isonorm 9241/10, Isometrics, Ergonorm Weitere Fragebögen: Quis, Eu-Con 2, IfADo, Sumi, Ergonorm, NASA-TLX

ISONORM 9241/10 -Fragebogen Jochen Prümper, Michael Anft 1993 Orientiert sich an der DIN 9241, Teil 110 Sieben Gestaltungsgrundsätze à fünf Fragen: Aufgabenangemessenheit Unterstützt die Software die Erledigung Ihrer Arbeitsaufgaben, ohne Sie als Benutzer unnötig zu belasten? Selbstbeschreibungsfähigkeit Gibt Ihnen die Software genügend Erläuterungen und ist sie in ausreichendem Masse verständlich? Steuerbarkeit Können Sie als Benutzer die Art und Weise, wie Sie mit der Software arbeiten, beeinflussen? Erwartungskonformität Kommt die Software durch eine einheitliche und verständliche Gestaltung Ihren Erwartungen und Gewohnheiten entgegen?

ISONORM 9241/110 -Fragebogen Lernförderlichkeit Ist die Software so gestaltet, dass Sie sich ohne grossen Aufwand in sie einarbeiten konnten und bietet sie auch dann Unterstützung, wenn Sie neue Funktionen lernen möchten? Fehlertoleranz Bietet Ihnen die Software die Möglichkeit, trotz fehlerhafter Eingaben das beabsichtigte Arbeitsergebnis ohne oder mit geringem Korrekturaufwand zu erreichen? Individualisierbarkeit Können Sie als Benutzer die Software ohne grossen Aufwand auf Ihre individuellen Bedürfnisse und Anforderungen anpassen?

ISONORM 9241/110 -Fragebogen Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de Fragebogen steht für persönlichen Nutzung zur Verfügung unter: http://www.ergo-online.de/site.aspx?url=html/software/verfahren_zur_beurteilung_der/fragebogen_isonorm_online.htm

ISONORM -Fragebogen - Ergebnis Kurze Angaben über die Expertise Zusammenfassendes Urteil über die Software Freitext für Kommentar In 15 bis 20 Minuten zum Beantworten Ergebnis Erster Eindruck der Gebrauchstauglichkeit Keine Details Keine speziellen Aspekte Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

Isometrics 7 Gestaltungsgrundsätze von der Isonorm 9241/10 Die Gestaltungsgrundsätze werden mit jeweils 7 bis 12 Items erhoben Insgesamt besteht der Fragebogen aus 75 Items, die auf einer 5- stufigen Ratingskala beantwortet werden

ErgoNorm 7 Gestaltungsgrundsätze von der Isonorm 9241/10

QUIS und SUMI QUIS - Questionnaire for User Interface Satisfaction 5.4. Messages which appear on screen: confusing clear 1 2 3 4 5 6 7 8 9 NA Mit dem Fragebogen werden erfasst: Zufriedenheit Bildschirmgestaltung Informationsgestaltung Erlernbarkeit Effizienz Geschwindigkeit Zuverlässigkeit Qualität der Handbücher Online Hilfe

QUIS und SUMI SUMI - Software Usability Measurement Inventory Subjektiv wahrgenommene Usability: Affect (emotional gefärbte Beurteilung des Programms) Control (wahrgenommene Kontrolle über das Programm) Efficiency (Effizienz der Aufgabenbearbeitung) Helpfulness (Selbstbeschreibungsfähigkeit) Learnability (Lernförderlichkeit)

Freude mit AttrakDiff messen Messen von hedonische Qualität Nutzungserlebnis, dass der Nutzer bei der Bedienung erfährt Interviews mit Fragen zur Befindlichkeit und Zufriedenheit Qualitative Ergebnisse Nicht gut vergleichbar Evaluationsverfahren AttrakDiff Quantitative Analyse Bedienbarkeit, Aussehen, Attraktivität 23 gegensätzliche Begriffspaare sympathisch unsympathisch, verwirrend übersichtlich Skala von 1 bis 7 www.attrakdiff.de Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, www.swergonomie.de

AttrakDiff Quelle:http://www.uidesign.de/attrakdiff2/eval/attrakdiff.php?step=3

Methoden: Übersicht Evaluierung Mit Nutzern vs. Ohne Nutzer Quantitative vs. Qualitative Field Studies vs. Lab Studies Pre-Design, During-Design, After-Design Formativ vs. Summativ / Usability vs. Utility

Health-ITUEM Health-IT Usability Evaluation Model von der Theorie zur Praxis

Health-ITUEM Übersicht Mobile Health-IT / ehealth- & Gesundheits-Apps >100.000 Apps Usability oftmals mangelhaft Spezielle Anforderungen komplexe Systeme, aber einfachste Handhabung angestrebt Zielgruppe Kranke Health-ITUEM = Usability-Evaluierungsmodell für mhealth

Health-ITUEM Hintergrund Ein Startup entwickelt eine Webapp zur Arzt-/Patientenkommunikation Die Webapp soll zum ersten Mal von Usern getestet werden Planung des Usability-Tests Testdurchführung auf verschiedenen Endgeräten Quelle: Stonebird IT Solutions

Health-ITUEM Prozess Modellauswahl Health- ITUEM Methodenauswahl Beobachtung, Thinking Aloud, Logs/Protokolle, Usability Lab, Videoanalyse Fragebogen Durchführung & Auswertung im Rahmen eines Hackathons

Health-ITUEM Das Modell - Entstehung Modell Methode Fokusgruppen analysierten Health-Apps Fragebögen, Beobachtungen und Freitext-Fragen wurden ausgewertet 9 Kriterien entwickelt mit jeweils positiven, negativen und neutralen Ausprägungen Test

Health-ITUEM Das Modell Modell Methode Test

Health-ITUEM Kriterien (Auswahl) Modell Methode Test Effektivität & Effizienz sind messbar Fehlervermeidung: Fehlermeldungen, Rückgängig-F., Eingabehilfen Vollständigkeit: Assistenten/Helfer, Fortschrittsanzeige Merkfähigkeit: Aufgabenerledigung wird gemerkt Flexibilität/Anpassbarkeit Sicherheit: die Benutzer fühlen sich sicher, eine Aufgabe erledigen zu können

Health-ITUEM Fragebogen Modell Methode Test

Health-ITUEM Fragebogen nach Attrak-Diff Modell Methode Test

Health-ITUEM Test-Aufgaben Modell Methode Test

Health-ITUEM Usability Lab Modell Methode Test Geeigneter Arbeitsplatz Testgeräte Kamera + Stativ Licht Extra-Monitor Mikrofon Sensorik

Health-ITUEM Usability Lab Modell Methode Test

Health-ITUEM Usability Lab Modell Methode Test Bild & Ton testen, sind Mimik & Gestik Sprache Blickpunkt (ca.) Mauszeiger Tastatureingaben Web-App erkennbar?

Health-ITUEM Fotos des Hackathons Modell Methode Test

Health-ITUEM Fotos des Hackathons Modell Methode Test

Health-ITUEM Auswertung Modell Methode Test

Health-ITUEM Lessons learned Inhaltlich zu wenig aussagekräftige Fehlermeldungen zu wenig Hilfe beim Eingeben von Daten Lernkurve ist gut (einmal kapiert, immer funktioniert) Modell Methode Test Methodisch keine großen Unterschiede der Testergebnisse bei mobilen Devices unser Usability-Lab reichte vollkommen aus die Videoanalyse war sehr hilfreich

Health-ITUEM Quelle Bei Fragen: christoph.berdenich@stonebird-it.com Alle Fotos Stonebird IT Solutions GmbH / Christoph Berdenich Health-ITUEM: Assessment of the Health IT Usability Evaluation Model (Health- ITUEM) for evaluating mobile health (mhealth) technology William Brown III, Po-Yin Yen, Marlene Rojas, Rebecca Schnall