Die heuristische Evaluation ist eine Methode, um den Gebrauch einer Benutzeroberfläche zu optimieren, indem anhand von Faustregeln bestimmt wird, ob etwas bereits gut oder noch verbesserungswürdig ist. Wieso das gemacht wird und wie die Methode funktioniert, wird im folgenden Artikel näher erläutert.
Zunächst sei gesagt, dass Heuristiken (zu griech. Heuriskein „finden“) keine wissenschaftlich abgesicherten Regeln darstellen, sondern vielmehr sind sie Daumen- bzw. Faustregeln. Würde man als Beispiel einer Heuristik den Konsum von Pilzen heranziehen, so wäre die eine Regel: „Der Pilz mit Schwammgewebe ist essbar“ und die andere Regel wäre: „Dieser Pilz mit Lamellen ist ungenießbar bzw. giftig“. Da Ausnahmen die Regel bestätigen, gelten diese Regeln nicht zwangsläufig, stellen derweil eine gute Lösung dar, an derer man sich entlang hangeln kann.
Die Kritik an der heuristischen Evaluation ist, dass sie lediglich aufzeigt, in welchen Bereichen Probleme herrschen. Sie zeigt jedoch nicht, welche Lösungen es für die Probleme gibt. Darüber hinaus kritisiert sie nur, ohne aufzuzeigen, was überhaupt positiv zu betrachten ist.

Im Bereich der heuristischen Evaluation gibt es zwei unterscheidbare Verfahren: Das Bottom-Up- und das Top-Down-Verfahren. Beim Bottom-Up-Verfahren existiert keine systematische Suche, während beim Top-Down-Verfahren eine solche systematische Suche zugrunde liegt. Zieht man wieder das Beispiel des Pilzkonsums heran, so wäre im Falle des Bottom-Up-Verfahrens ein Vergleich mit einem normalen Waldspaziergang ratsam, bei dem sämtliche Pilze gesammelt werden und daraufhin auf ihre Genießbarkeit getestet werden. Das Top-Down-Verfahren würde einer Kartierung des Waldes inklusive der Prüfung auf Vorhandensein von Pilzen gleichkommen.

Wie läuft eine heuristische Evaluation (HE) ab?

Zunächst erfolgt eine individuelle Evaluation jedes einzelnen Inspektors. I.d.R. existieren pro Evaluation fünf Inspektoren. Mindestens erforderlich sind jedoch zwei Inspektoren. Bei fünf Inspektoren werden im Schnitt 75% der Probleme gefunden. Der Zuwachs durch mehr Inspektoren ist jedoch nur sehr gering, wohingegen die Kosten stetig steigen würden.
Die individuelle Evaluation umfasst das vertraut machen mit der Anwendung ohne eine Rücksprache mit anderen Inspektoren. Als Pilzvergleich wäre dies die Suche, Dokumentation und das Notieren der Regelverletzungen (essbar oder nicht, obwohl Schwamm bzw. Lamelle) eines jeden gefundenen Pilzes. Allerdings muss hierbei stets eine Maximalzeit angegeben werden und auch die Kürzel des jeweiligen Inspektors sollten angegeben werden, da im folgenden Schritt das Zusammentragen der jeweiligen Ergebnisse erfolgt. Während Anfänger meist eine Regel suchen und das System dann anhand von entsprechenden Problemen absuchen, so sehen erfahrene Evaluatoren zunächst ein Problem und ordnen erst im zweiten Schritt zu, welche Regel verletzt wird.
Das Herzstück der HE ist die Expertenrunde bzw. der zweite Schritt der Evaluation, weil hierbei eine Konsensdiskussion stattfindet. Hierbei werden oftmals tiefgehende, konzeptionelle Probleme entdeckt.
Der dritte Schritt umfasst die Auswertung und Dokumentation der Probleme, die an den Kunden weitergegeben werden. Hierzu eignen sich beispielsweise Excel-Tabellen, da man diese nach Heuristik, Schwerergrad etc. ordnen kann.

Die Bewertung des Schweregrads

Die Zuordnung von Schweregraden zu den gefundenen Problemen ist nützlich, um die Kosten für die Behebung mit dem Nutzen abzugleichen, den Schaden für das Business abzuschätzen oder die voraussichtliche User Annoyance zu dokumentieren. Dies geschieht häufig in einem Extra-Workshop im Anschluss an die HE. Die Bewertung des Schweregrades erfolgt in vier Stufen. Dabei kann das Diagramm hilfreich sein. Bei Schweregrad vier ist zu beachten, dass es wirklich ein massives Problem darstellt, das sofort behoben werden muss.
Durch diese Bewertung können die Probleme auch priorisiert werden. Im Englischen nennt man den Schweregrad „Severity Rating“.
Die vier Schweregrade sind:
1. Kosmetisches Problem
2. Kleines Usability Problem
3. Großes Usability Problem
4. Usability Katastrophe

Heuristiken nach Nielsen und Molich

Jakob Nielsen hat zehn Heuristiken für die HE aufgestellt. Diese Heuristiken werden auch als die „10 Gebote der HE“ bezeichnet. Hierbei wird die Sortierung nach Nielsen und Molich dargestellt. Die zehn Heuristiken werden im Folgenden dargestellt und näher erläutert.

1. Sichtbarkeit des Systemstatus:
Das System sollte immer angemessenes Feedback in einer angemessenen Zeit liefern. Das System sollte den Benutzer kontinuierlich darüber informieren, was es tut und wie es den Input des Benutzers verarbeitet.
Bspw. akustische Signale (Signalton bei Tastendruck), Fortschrittsbalken, Abbildung des eingezogenen Blattes beim Scanner, Validierung von Formfeldern.

2. Übereinstimmung zwischen dem System und der realen Welt:
Das System sollte die Sprache des Benutzers sprechen und systemorientierte Terminologien vermeiden. Der Dialog sollte so dargestellt werden, dass er sich mehr am Benutzer als am System orientiert.w Beispielsweise sind detaillierte Fehlercodes für den Benutzer uninteressant, da er klar und deutlich wissen möchte, was falsch gelaufen ist. Darüber hinaus möchte ein Benutzer nicht wissen, dass eine Datenbankabfrage läuft, wenn er nach Stichworten sucht.

3. Benutzerkontrolle und –freiheit:
Ein System sollte so strukturiert sein, dass Benutzer nie in Situationen geraten, aus denen sie nicht wieder zurückfinden. Benutzer werden immer Fehler machen, unabhängig davon, wie gut das Interface ist. Exits unterstützen das Lernen, da Operatoren / Alternativen gefahrlos ausprobiert werden können.
Es gibt viele Negativbeispiele, zum Beispiel das schwere Herauskommen aus Warenkörben. Das ist oft Absicht, um den Kunden doch zum Kauf oder zu weiteren Käufen zu bewegen.

4. Konsistenz und Standards:
Systembenutzer sollten nicht verwundert sein über eine unterschiedliche Wortwahl für gleiche Situationen oder Aktionen.
Dahinter verbirgt sich ganz klar die Erwartungskonformität. Nielsens Heuristiken sind nicht so weit weg von den Dialogprinzipien der ISO 9241.

5. Fehlerverhütung:
Ein gutes Design, das Fehler erst gar nicht zulässt bzw. das Fehlverhalten von Benutzern einschränkt ist deutlich besser als eine Fehlermeldung.
Regeln für Passwörter oder die Eingabe von Daten sollten vor der Eingabe angezeigt werden, statt danach fünf einzelne Fehlermeldungen herauszugeben. Bspw. Buttons, die nicht in den Flow passen sollte man weglassen oder ausgrauen, Pflichtfelder markieren, den Mainflow visuell highlighten.

6. Wiedererkennen statt sich erinnern:
Recognition ist einfacher als Recall.
Das Kurzzeitgedächtnis eines Benutzers ist begrenzt. Erkennen funktioniert besser als aktives Erinnern.
Wenn das Datumsfeld so vorformatiert ist, dass ersichtlich ist, ob das Jahr vier- oder zweistellig eingegeben werden soll, muss man nicht darüber nachdenken. Bspw. Kategorisieren, Shortcuts, Breadcrumbs, auf den Verlauf zugreifen können.

7. Flexibilität und Effizienz der Benutzung:
Erfahrene Benutzer empfinden Features oft als lästig, wenn diese dazu beitragen, ein System schnell zu verstehen. Daher sind gut gewählte Abkürzungen eine optimale Alternative. Vorher eingegebene Daten sollten vorgeschlagen werden. Bspw. konfigurierbare Favoriten, Shortcuts.

8. Ästhetik und minimalistisches Design:
Sämtliche Informationen sollten natürlich, aber auch logisch dargestellt werden. Den Gestaltgesetzen sollte Folge geleistet werden.

9. Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern:
Eine gute Fehlermeldung sollte so präzise, aber auch so konstruktiv wie möglich sein. Eine präzise Fehlermeldung gibt Benutzern exakte Informationen zur Ursache der Probleme. Hilf dem Benutzer, Fehler zu erkennen und zu verhindern. Fehlermeldungen bieten die Möglichkeit, beim Verständnis des Systems zu helfen. Fehlermeldungen sollten nicht mysteriös sein und für den Benutzer unverständliche „innere“ Computerzustände anzeigen.
Kryptische, angsteinflößende und wenig hilfreiche Fehlermeldungen sind zu vermeiden, wie zum Beispiel „Funktionstest ABC ist durchgefallen. Sie müssen das System abrüsten und neu starten.“. Im Fehlerdialog sollte nicht nur der Fehler genannt werden, sondern ein Lösungsvorschlag angeboten oder der Nutzer direkt zu den Einstellungen navigiert werden, damit er das Problem lösen kann.

10. Hilfe und Dokumentation: Benutzer brauchen schnelle, aufgabenorientierte Hilfe, die mit Beispielen arbeitet und leicht zu finden ist. Websites sollten ohne Hilfe auskommen.
Bei Apple wurde zum Beispiel das Suchen nach Befehlen gut umgesetzt.

Wenn man mit der HE beginnt, hat man die Heuristiken und die ISO-Regeln immer neben sich und kann sich orientieren. Allerdings sollte man sich von den Regeln zunächst lösen und selbst herausfinden, ob es Probleme gibt und wenn ja, wie scher diese wiegen. Bei der Präsentation sollte man jedoch die Probleme einer Regel zuordnen. Anhand eines Beispiels könnte das so aussehen: Man trifft sich, bespricht sich und brainstormt zunächst. Darüber hinaus könnte man ein Template erstellen oder sogar ein Usecase. Darauf folgt eine weitere Sitzung mit individueller Evaluation. Hierbei sollte die für jeden zur Verfügung stehende Zeit gleich sein. Im Anschluss daran folgt eine Expertensitzung. Diese dauert i.d.R. länger als die individuelle Betrachtung. Die letzten beiden Schritte enthalten die Auswertung bzw. Dokumentation und die darauffolgende Präsentation der Ergebnisse vor dem Kunden.