Zurück zur Übersicht

Heuristic evaluation

Alexandre Dürr

Die Heuristische Evaluierung unterscheidet sich auch von der empirischen Evaluierung, die ein teilweise lauffähiges System voraussetzt. Die Heuristische Evaluierung kann schon aufgrund von Beschreibungen, also noch nicht lauffähigen Systemen durchgeführt werden, also vor, während und nach der Implementierung. Des weiteren werden bei der Heuristischen Evaluierung professionelle Untersucher, so genannte User Interface Specialists eingesetzt, welche die Schnittstelle anhand vorgegebener Kriterien (Heuristiken) untersucht.

Nach Jakob Nielsen gibt es zehn Heuristiken.

Die erste Heuristik ist ein Einfacher und natürlicher Dialog - (Visibility of System Status) zwischen Benutzer und System, d. h. der Benutzer sollte vom System immer auf dem Laufenden gehalten werden, was gerade vor sich geht und sollte genau die Informationen zur richtigen Zeit am richtigen Ort präsentiert bekommen, die er benötigt.

Die zweite Heuristik lautet Sprich die Sprache des Benutzers - (Match between System and the real world), also das System sollte Terminologien verwenden, welche dem Nutzer bekannt vorkommen, also keine system-orientierten Ausdrücke, beispielsweise die Spezeialsprache einer Branche oder die Muttersprache des Benutzers.

Als drittes kommt Benutzerkontrolle und Freiheit - (User control and freedom) dazu. Nutzer sollten, wenn sie fälschlicherweise an einen Ort gelangt sind an den sie nicht gelangen wollten einen klaren Hinweis bekommen, der sie aus dieser Lage herausführt, genauso sollten Undo und Redo Operationen vorhanden sein, um dies zu gewährleisen.

Der vierte Punkt lautet Konsistenz und Einhaltung von Standards - (Consistency and standards). Platformübergreifende Standars sollten eingehalten werden und dieselbe Aktion sollte immer denselben Effekt zur Folge haben (Konsistenz).

Die fünfte Heuristik ist die Fehlervermeidung - (Error prevention), welche besser sind als überhaupt erst den Fehler zuzulassen und gute Fehlermeldungen auszugeben. Das Ziel hier ist also den Fehler erst gar nicht enstehen lassen, vor allem schwere und häufige Fehler.

Als sechster Grundsatz steht das Wiedererkennen anstelle von erinnern - (Recognition rather than recall), was bedeutet, dass das "Im Gedächtnis Behalten" von Informationen der Nutzer verringert werden soll und das Wiedererkennen und Verstehen gestärkt werden soll. Es ist nämlich leichter selbst schon erkanntes wiederzuerkennen als es selbst aus dem Gedächtnis zu reproduzieren.

Flexibiität und Effizienz - (Flexibility and efficiency of use) ist die siebte Heuristik. Jeder Nutzer ob Experte oder Laie sollte die selben Aktionen durchführen können.

Die nächste Heuristik ist das Ästhetische und minimalistische Design - (Aestehtic and minimalist design) der Nutzerschnittstelle. Dialoge sollten keine irrelevanten Informationen enthalten oder welche, die fast nie genutzt wird. Jede irrelevante zusätliche Information lenkt von der tatsächlichen Information ab. Dies ist somit kontraproduktiv.

Als vorletzte Heuristik gilt, Hilfe für den Benutzer um Fehler wahrzunehmen, zu erkennen und zu beheben - (Help user recogniz, diagnose and recover from errors). Fehlermeldungen, wenn sie denn nicht nach Heuristik fünf vermieden werden können sollten in einer einfachen Sprache gehalten werden, der Sprache des Benutzers (siehe Heuristik zwei), genau das Problem erläutern und dem Nutzer einen konstruktiven Vorschlag zur Behebung vermitteln.

Hilfe und Dokumentation - (Help and documentation) runden als letztes die Heuristiken nach Nielsen ab.

Im Allgemeinen werden heuristische Evaluierungen nicht von einzelnen Personen durchgeführt, da eine einzelne Person meist nicht alle Nutzbarkeitsprobleme aufdecken kann. Die Erfahrung aus mehreren Projekten hat gezeigt, dass verschiedene Menschen nun mal verschiedene Probleme entdecken.

Typischerweise sollten heuristische Untersuchungen derart nicht länger als zwei Stunden dauern. Falls sie doch länger dauern (bei komplexeren Nutzerschnittstellen) ist es ratsam sie in mehrere Teile aufzusplitten, die sich dann jeweils auf  einen Bereich des Interfaces konzentrieren.

Während der Untersuchung geht der Gutachter das Interface mehrere Male durch und kontrolliert alle Punkte des Interfaces aufgrund der vorgegeben zehn Heuristiken auf Unstimmigkeiten. Des Weiteren können noch kategoriespezifische Heuristiken entwickelt und verwendet werden, beispielsweise für eine spezielle Art von Produkt.

Prinzipiell müssen die Gutachter selbst entscheiden, wie oft sie ihr Interface durchchecken. Zwei Male mindestens sollte dies schon geschehen, da man beim zweiten Mal Fehler noch genauer feststellen kann, während man beim ersten Durchgang noch allgemein das System abcheckt und es somit auch erstmal entdeckt. Ein Vorteil der heuristischen Evaluierung ist auch, dass die Evaluierung zu jedem Zeitpunkt durchgeführt werden kann, also auch wenn kein vollständiges oder teilweise implementiertes System vorliegt. Dies ist von enormem Vorteil, da somit die Evaluierung auch sehr früh vorgenommen werden kann.

Der Output, den die heuristische Evaluation liefert ist eine Liste von Nutzungsproblemen der Schnittstelle, mit einem Vermerk, gegen welche Heuristik mit welchem Fehler, also wann und wo, verstossen wurde. Die Fehler sollten so spezifisch wie möglich von den  Gutachtern benannt werden, ferner sollten alle Fehler separat aufgelistet werden; also beispielsweise wenn vier Fehler an einem Dialogelement auftauchen, so sollen diese vier Fehler benannt, inklusive einer Beschreibung, warum diese Fehler jetzt ein Usability-Problem darstellt.

Die zwei Hauptgründe für die Auflistung jeder einzelner Probleme sind zum einen das Risiko, dass ein Fehler, der in einem Dialogelement vorkommt wiederholt werden kann und zum anderen wird es nicht möglich sein alle Nutzungsprobleme eines Interface-Elements zu beheben.

Man muss noch dazu sagen, dass die heuristische Evaluierung kein Kochrezept ist mit dem jeder Fehler behoben werden kann, das heisst vor allem die Beschreibung der Fehler ist von grosser Bedeutung. Denn jeder Fehler oder besser: jede Abweichung der Heuristiken muss für das Problem individuell gelöst werden.

So ist nicht jede Inkonsistenz zum Beispiel der Schriftarten (falls mehrere Schriftarten an einem Interface vorkommen) gleich zu beheben. Es muss erst geklärt werden, welche Schriftart für das Redesign verwendet werden.

Eine Möglichkeit die heuristische Evaluierung fortzuführen wäre es nach der "tatsächlichen Evaluierung" noch ein Nachtreffen abzuhalten. Die Teilnehmer dieses Treffens umfassen die Gutachter des Nutzerschnittstelle, ein Beobachter, der die Gutachter beobachtet hat, sowie die Designer des Interfaces. Das Treffen sollte erst mit einem Brainstorming beginnen und dann in eine Diskussion übergehen, die sich dann um mögliche Redesigns der Seite dreht, natürlich ohne die festgestellten Probleme. Aber nicht nur Probleme können hervorgehoben werden, auch die positiven Aspekte der Schnittstelle können in der Diskussion zum Vorschein kommen.

Nach Jeffries et al. ist die heuristische Evaluierung eine sehr effiziente Nutzbarkeitsmethode im Bereich des Engineering.

Nach einer Fallstudiestudie von Jakob Nielsen hat sich eine Kosten Nutzen Rechnung für eine heuriste Evaluierung mit einem Gewinnkoeffizienten von 48 ergeben: Die Kosten nach der Evaluierung waren bei 10.500 Dollar, die Einsparungen und der Gewinn lagen bei 500.000 Dollar. Anzumerken ist aber, das die heuristische Evaluierung in dem Bereich des Engineering nicht garantiert "perfekte" Resultate liefert und somit nicht jedes Nutzbarkeitsproblem der Schnittestelle erkennt.

Alles in allem ist eine sehr gute Fehlerbeseitigungsquote mit der Anwendung der Heuristiken und den Leitlinien der heuristischen Evaluierung zu verzeichnen.