Usability Evaluation

Transkript

1 Usability Evaluation

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

3 Ü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

4 Teil des Software Engineerings Usability-Engineering ergänzt das klassische Software-Engineering

5 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

6 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

7 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,

8 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

9 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

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

11 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

12 1 Einfache und natürliche Dialoge Ästhetik und minimalistisches Design Jegliche Information sollte in einer natürlichen und logischen Ordnung erscheinen. Version-5-gibt-Ausblick-auf-Android-L_ html

13 2 Ausdrucksweisen der Benutzenden Übereinstimmung zwischen dem System und der realen Welt Das System sollte die Sprache der Benutzer sprechen und systemorientierte Terminologien vermeiden.

14 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.

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

16 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.

17 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

18 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.

19 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.

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

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

22 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

23 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,

24 Beispiel: Mobiltelefon (Video)

25 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.

26 Usability Lab l

27 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,

28 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,

29 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) Video (whatusersdo) Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm,

30 Evaluations-Tools für mobile HCI Touch Heatmaps Screencasts In-App Analytics Statistiken zur Verwendung von Funktionen, Verweildauer, etc. AppSee: UXCam:

31 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

32 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

33 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

34 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?

35 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,

36 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

37 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:

38 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.

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

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

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

42 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?

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

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

45 Eye tracking (Video)

46 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

47 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?

48 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?

49 ISONORM 9241/110 -Fragebogen Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm, Fragebogen steht für persönlichen Nutzung zur Verfügung unter:

50 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,

51 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

52 ErgoNorm 7 Gestaltungsgrundsätze von der Isonorm 9241/10

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

54 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)

55 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 Quelle: Pearson Studium, Grundlagen der MCI, M. Dahm,

56 AttrakDiff Quelle:

57 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

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

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

60 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

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

62 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

63 Health-ITUEM Das Modell Modell Methode Test

64 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

65 Health-ITUEM Fragebogen Modell Methode Test

66 Health-ITUEM Fragebogen nach Attrak-Diff Modell Methode Test

67 Health-ITUEM Test-Aufgaben Modell Methode Test

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

69 Health-ITUEM Usability Lab Modell Methode Test

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

71 Health-ITUEM Fotos des Hackathons Modell Methode Test

72 Health-ITUEM Fotos des Hackathons Modell Methode Test

73 Health-ITUEM Auswertung Modell Methode Test

74 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

75 Health-ITUEM Quelle Bei Fragen: 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