Heuristische Evaluation

Seminar: Software-ergonomische Evaluation - Kosten und Nutzen

Veranstalter: Dr. Susanne Maaß, Sommersemester 1996

Birgit Labusch

7. Juni 1996


Inhaltsverzeichnis

1 Vorgehensweise bei einer Heuristischen Evaluation

2 Wer evaluiert und mit welchem Erfolg

3 Heuristische Evaluation im Vergleich mit Benutzungstests

4 Gestaltungsprinzipien, die bei der Heuristischen Evaluation zugrundegelegt werden können

5 Kosten und Nutzen von Heuristischer Evaluation

5.1 Ein Fallbeispiel Literatur
 
 

1 Vorgehensweise bei einer Heuristischen Evaluation

Bei der Heuristischen Evaluation setzt sich jeder Evaluator für sich allein an die zu untersuchende Schnittstelle. Dies ist wichtig, da verschiedene Evaluatoren verschiedene Probleme aufdecken. In Abbildung 1 kann man dies sehr schön erkennen. An einem Beispiel mit 19 Evaluatoren und 16 möglichen aufzudeckenden Fehlern ist aufgezeigt, wie unterschiedlich die Evaluatoren Fehler gefunden haben.


Abbildung 1

Nachdem alle Evaluationen durchgeführt sind, werden die Befunde (d.h. die von den Evaluatoren aufgedeckten Fehler) zusammengefaßt.

Die Ergebnisse können entweder als geschriebene Berichte von den Evaluatoren selbst festgehalten werden oder man setzt einen Beobachter zu jedem Evaluator, der dann ein Protokoll der Sitzung erstellt, wobei der Evaluator die ganze Zeit ,,laut denken" muß. Die zweite Methode ist der ersten vorzuziehen, da der Beobachter den Evaluatoren bei auftretenden Fragen oder Problemen – wie z.B. fehlenden Fachkenntnissen oder bei einem Absturz des Prototyps – behilflich sein kann. Außerdem wird die Arbeitslast der Evaluatoren verringert und die Ergebnisse stehen schneller zur Verfügung, da der Beobachter nur seine eigenen Notizen verstehen muß und nicht die anderer.

Man kann die Heuristische Evaluation erweitern, indem sich die Evaluatoren, die Beobachter und Vertreter des Entwickler-Teams nach der letzten Evaluation treffen und sich in einer Art Brainstorm einander mitteilen. Hier können wichtige Anregungen in bezug auf Folgeversionen des untersuchten Programms gesammelt werden oder generelle Probleme sowie positive Aspekte der Evaluation besprochen werden.

Heuristische Evaluation ist gut geeignet, um sowohl schwerwiegende, als auch nicht ganz so wichtige Probleme in einem User-Interface zu finden. Die schwerwiegenden Fehler werden dabei zwar leichter aufgefunden, von der Gesamtzahl der Fehler ausgehend werden aber mehr unwichtige als wichtige Fehler gefunden (was wohl für die Qualität der Prototypen spricht).
 
 

2 Wer evaluiert und mit welchem Erfolg

Es gibt vier Kategorien von möglichen Evaluatoren:

Die letzte Gruppe sollte aber nur in Notfällen herangezogen werden, da die Benutzer zwar mit ihrer Arbeit als solcher gut vertraut sind, sich aber nicht immer unbedingt ein Bild davon machen können, wie ihr Arbeitsplatz in der Zukunft aussehen könnte oder welche Möglichkeiten ihnen Computer bieten können oder auch nicht. Deshalb erlangt man bei Benutzern die besten Einsichten, wenn man ihnen eine konkrete Aufgabe stellt und sie dann bei der Problemlösung beobachtet. Die Vorschläge, die ein Benutzer macht, sollten deshalb eher als zusätzliche Inspiration, denn als die absolute Wahrheit angesehen werden.

Man sieht also, daß hier praktisch jeder evaluieren kann; dies geschieht nur meist mit unterschiedlichem Erfolg. Es gibt die unterschiedlichsten Kriterien, die dazu führen, daß ein Evaluator möglichst viele und wichtige Probleme aufdeckt. Da ist es z.B. wichtig, welche Erfahrung ein Evaluator hat: So fanden bei einer Testgruppe, die sich aus Anfängern (mit allgemeinen Computerkenntnissen), einfachen und doppelten Experten zusammensetzte, die doppelten Experten im Durchschnitt 60 Prozent der Fehler, wobei sie 2,7mal schneller als die Anfänger und 1,5mal schneller als die einfachen Experten waren. Die einfachen Experten fanden hingegen nur 41 Prozent der Fehler, mit einer 1,8mal höheren Geschwindigkeit als die Anfänger, die dann auch nur noch 22 Prozent der Probleme ausfindig machen konnten.

Ein weiterer Aspekt ist die Häufigkeit, mit der eine Person schon heuristisch evaluiert hat. So hat man herausgefunden, daß man gute Evaluatoren bekommt, indem man sie möglichst viele Evaluationen durchführen und anschließend die Ergebnisse noch mit anderen Evaluatoren diskutieren läßt.

Der letzte, aber nicht zu unterschätzende Punkt ist die Tagesform des jeweiligen Evaluators. So gibt es für jeden Tage, an dem er relativ viele Probleme aufdecken kann und andere, an denen er nur mühselig etwas findet.
 
 

3 Heuristische Evaluation im Vergleich mit Benutzungstests

Beide Verfahren finden Benutzbarkeitsprobleme, die auch durch das jeweils andere Verfahren gefunden werden; die Ergebnisse überlappen sich also. Dies ist keineswegs unerfreulich, da ein doppelt gefundenes Problem ja auch auf die Notwendigkeit der Beseitigung des Fehlers aufmerksam macht. Aus diesem Grund und weil beide Verfahren sich gut ergänzen, werden in einer Evaluation oft beide Verfahren angewendet. Meist wird zuerst eine Heuristische Evaluation durchgeführt, mit der möglichst viele ,,augenscheinliche" Probleme aufgedeckt werden. Nach einer Überarbeitung des Programms wird dann ein Benutzungstest durchgeführt, um die restlichen Probleme aufzudecken. Man wählt diese Reihenfolge, damit ,,unbedarfte" Benutzer, die oft schwer zu finden sind, nicht schon bei der Heuristischen Evaluation ,,verschlissen" werden.
 
 

4 Gestaltungsprinzipien, die bei der Heuristischen Evaluation zugrundegelegt werden können

Nielsen gibt in [Molich90] einige Gestaltungsprinzipien vor, die ein Evaluator bei seiner Arbeit beachten sollte (dies ist kein Muß, aber für einen unerfahrenen Evaluator ist es ohne gewisse Hilfsmittel sehr schwer, eine einigermaßen erfolgreiche Heuristische Evaluation durchzuführen):

Dialoge sollten keine irrelevanten oder wenig benötigten Informationen enthalten. Jede unwesentliche Information konkurriert mit wichtiger und vermindert das Sehen dieser durch den Benutzer. Jegliche Information sollte in einer natürlichen und logischen Ordnung erscheinen. Der Dialog sollte in klaren Worten, Phrasen und Konzepten ausgedrückt werden, die sich eher am Benutzer als am System orientieren. Das Kurzzeitgedächtnis der Benutzer ist begrenzt. Sie sollten sich deshalb nicht an Information erinnern müssen, die in einem ganz anderen Bereich des Dialogs von Bedeutung war. Anweisungen für die Benutzung des Systems sollten eindeutig oder zumindest leicht reparierbar sein. Komplizierte Anweisungen sollten vereinfacht werden. Benutzer sollten sich nicht über unterschiedliche Wortwahl, Situationen oder Aktionen wundern müssen, die das Gleiche bedeuten. Das System sollte den Benutzer immer ,,auf dem Laufenden" halten, indem es angemessenes Feedback in einer vernünftigen Zeit liefert. Ein System sollte Benutzer nie in Situationen geraten lassen, aus denen sie nicht wieder zurückfinden bzw. keinen Ausgang finden. Benutzer wählen Systemfunktionen oft falsch aus und brauchen einen klar markierten ,,Notausgang", um aus dem ungewollten Zustand wieder herauszugelangen. Dies sollte außerdem sofort geschehen, ohne daß der Benutzer durch einen aufgeblähten Dialog gehen muß. Features, die es einem 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 daß beide Benutzergruppen zufrieden sind. Gute Fehlermeldungen sind defensiv, präzise und konstruktiv. Defensive Fehlermeldungen schieben das Problem auf Systemschwächen und kritisieren niemals den Benutzer. Präzise Fehlermeldungen geben dem Benutzer genaue Informationen über die Ursache des Problems. Konstruktive Fehlermeldungen geben dem Benutzer nützliche Hinweise darauf, was er als nächstes tun kann. Besser als gute Fehlermeldungen ist ein cleveres Design, das das Eintreten von Fehlern erst gar nicht zuläßt. 5 Kosten und Nutzen von Heuristischer Evaluation

Das beste Kosten-Nutzen-Verhältnis erhält man bei drei bis fünf Evaluatoren.


Abbildung 2

Die Kurve in Abbildung 2 zeigt dies anhand des Verhältnisses von Benutzbarkeitsproblemen in einer Schnittstelle, die von einer unterschiedlichen Anzahl von Evaluatoren gefunden wurden. Es wurden insgesamt sechs Fallstudien in der Figur berücksichtigt. Man sieht, daß hier schon fünf Evaluatoren 75% der Fehler aufdecken können. Nimmt man aber zehn weitere Evaluatoren hinzu, so werden nicht sehr viel mehr Fehler gefunden, aber die Kosten schnellen durch die zusätzlichen Gehälter der Personen in die Höhe.


Abbildung 3

Abbildung 3 zeigt das unterschiedliche Verhältnis von Kosten und Nutzen für verschiedene Anzahlen von Evaluatoren in einem Beispielprojekt. Die Kurve zeigt, daß die optimale Anzahl von Evaluatoren hier vier beträgt, was bestätigt, daß die Heuristische Evaluation am besten mit drei bis fünf Evaluatoren durchzuführen ist.

Den Kostenpunkt bei der Heuristischen Evaluation hat Nielsen in [Nielsen94a] sehr schön zusammengefaßt:

Heuristic evaluation is one of the main discount usability engineering methods. lt is easy (can be taught in a half-day seminar); it is fast (about a day for most evaluation); and it is as cheap as you want it.   Um eine exakte Kosten-Nutzen-Analyse einer Heuristischen Evaluation zu machen, braucht man zwei vollständig implementierte Versionen der Benutzungsschnittstelle: Eine ohne jegliche Veränderungen und eine, in denen die Ergebnisse der Heuristischen Evaluation berücksichtigt sind.

Nun gibt es zwei verschiedene Vorgehensweisen. In der ersten müssen genügend viele ,,echte" Benutzer beide Systeme genügend lange an ,,echten" Aufgaben testen. Dies liefert dann genaue Messungen, an denen man festmachen kann, wie hoch der jeweilige Lernaufwand und die Performanz ist. Ein Problem besteht hierbei darin, daß es sich bei den Systemen nur um Prototypen handelt, die dann mit der gleichen Benutzungsschnittstelle implementiert werden müßten, ohne Rücksicht auf die noch gefundenen Fehler, da andernfalls die vorangegangenen Untersuchungsergebnisse keine Gültigkeit mehr hätten.

Eine Alternative bietet eine detaillierte Arbeitsstudie, die die verschiedenen Arbeitsabläufe eines Arbeitstages der Benutzer in bezug auf Häufigkeit und Dauer untersucht. Außerdem kann man formale Modelle über Benutzungszeiten heranziehen, um jeden Schritt mit jedem Schritt eines alternativen Benutzungsschnittstellen-Designs zu vergleichen. Leider sind die Ergebnisse, die man so erhält, nicht unbedingt sehr zuverlässig und zusätzlich braucht man sehr viel Zeit für die Auswertung.

Man sollte sich deshalb lieber auf Abschätzungen (z.B. durch die Evaluatoren) als nur auf reine Meßdaten verlassen.
 
 

5.1 Ein Fallbeispiel

In Tabelle 1 ist ein Beispiel dafür angegeben, was eine Heuristische Evaluation kosten kann. Es wird ein Expertengehalt von $100 pro Stunde angenommen, womit die Gesamtkosten der Evaluation $10.500 betragen.

Die Kosten sind damit ermittelt; jetzt fehlt nur noch eine Summe für die Ersparnis, die durch die Evaluation und Anwendung der Ergebnisse erreicht wird. Hierzu wurden 11 Evaluatoren aufgefordert, die Verbesserung der Benutzbarkeit abzuschätzen; indem sie alle 44 aufgefundenen Benutzbarkeitsprobleme betrachten und dann auf folgende Benutzbarkeitsparameter abbilden sollten:

  1. Reduzierung des Lernaufwands

    2. Wieviel weniger Zeit würde ein Benutzer brauchen, um die Benutzung des Systems zu erlernen? Lernaufwand wird als ein Benutzbarkeitsparameter betrachtet, der einen einmaligen Gewinn von produktiver Zeit für jeden neuen Benutzer, der das System erlernt, bedeutet. Jegliche Ersparnis wäre einmalig.
     
  2. Erhöhte Arbeitsleistung

    3. Wenn der Benutzer sich einmal in das System eingearbeitet hat, ist er dann in der Lage die Aufgaben schneller zu lösen, wenn er ein ,,überarbeitetes" System hat (sprich: die Benutzbarkeitsprobleme sind eliminiert) oder mit dem ursprünglichen System? Dieser Benutzbarkeitsparameter repräsentiert einen kontinuierlichen Vorteil für den Benutzer, so daß jede Ersparnis für die gesamte Lebensdauer des Systems gilt.
Bestimmung geeigneter Dialogabläufe für die Heuristische Evaluation: 4 Personen à 2 Stunden
8 Stunden
Ein außenstehender Evaluator (also einer, der nicht aktiv evaluiert) macht sich mit dem Bereich und dem Szenario vertraut
8 Stunden
Finden und Benachrichtigen der Evaluatoren: 1,8 Stunden + 0,2 Stunden pro Evaluator
4 Stunden
Vorbereitung der Einführung in die Evaluation
3 Stunden
Vorbereiten des Szenarios für die Evaluatoren
2 Stunden
Einführung in die Evaluation: 1 Systemexperte, 1 Evaluationsexperte; 11 Evaluatoren à 1,5 Stunden
19,5 Stunden
Erstellung des Prototyps für die Evaluatoren
5 Stunden
Tatsächliche Evaluation: 11 Evaluatoren à 1 Stunde
11 Stunden
Beobachtung der Evaluationssitzungen: 2 Beobachter à 11 Stunden
22 Stunden
Brainstorming: 3 Evaluatoren, 3 Entwickler, 1 Evaluationsexperte à 1 Stunde
7 Stunden
Schreiben der Liste der Benutzbarkeitsprobleme, die auf den Aufzeichnungen aus den Evaluationssitzungen basieren
2 Stunden
Schreiben der Problembeschreibungen für die Benutzung in den Abschlußfragebögen
6 Stunden
Exakte Beurteilung (anhand der Fragebögen): 11 Evaluatoren à 0,5 Stunden
5,5 Stunden
Analyse der Beurteilung
2 Stunden
Summe
105 Stunden

Tabelle 1

Zusammen mit den Evaluatoren ist man zu folgenden Ergebnissen gekommen:

Man nimmt an, daß 2.000 Personen das System benutzen werden (dies ist eine sehr pessimistische Einschätzung, wenn man beachtet, daß etwa 3.000 Leute diese Arbeit verrichten). Diese 2.000 sparen jeweils einen halben Tag, um das System zu. erlernen, was eine einmalige Ersparnis von 1.000 Benutzertagen ausmacht. Haben sich die Leute richtig eingearbeitet, arbeiten sie 3,3%mal schneller und sparen damit 67 Benutzerjahre pro Kalenderjahr, was 13.000 Benutzertage sind. Die Ersparnis für das erste Jahr beträgt also 14.000 Benutzertage.

Um die totale Kostenersparnis zu ermitteln, nimmt man an, daß ein Benutzertag $100 kostet. Weiterhin nimmt man an, daß nicht alle Fehler, sondern nur die Hälfte behoben werden. Außerdem muß man noch den Zinsverlust beachten, der dadurch entsteht, daß das System nicht sofort eingesetzt werden kann. Damit kommt man dann zu einer Kostenersparnis von $540.000.

Da man aber durch die Untersuchungen einen zusätzlichen Aufwand für die Erstellung bzw. Verbesserung des Systems hat, kommt noch ein zusätzlicher Aufwand von 400 Stunden für das Software-Engineering hinzu. Geht man von einem Expertengehalt von $100 aus, wird die Kostenersparnis somit um $40.000 gesenkt. Trotz allem liegt man aber immer noch bei der beeindruckenden Summe von $500.000 Ersparnis, die den Aufwand von $10.500 für die Heuristische Evaluation schnell vergessen lassen.
 
 

Literatur
[Molich90] ROLF MOLICH und JAKOB NIELSEN "Improving a Human-Computer Dialoge" in: "Communications of the ACM, March 1990, Vol. 33/3", Seite 338-348

[Nielsen94a] JAKOB NIELSEN "Heuristic Evaluation" in: JAKOB NIELSEN und ROBERT L. MACK (Hrsg.) "Usability Inspection Methods", Wiley, 1994, Seite 25-62

[Nielsen94b] JAKOB NIELSEN "Cost-Benefit Analysis of Heuristic Evaluation: A Case Study" in: BIAS, MAYHEW "Cost-justifying Usability", Academic Press, 1994, Seite 257-267