Optimierung der Website Usability durch Heuristische Evaluation

Es gibt eine ganze Reihe von Methoden und Werkzeugen, um die Usability einer Website zu analysieren. Vom klassischen Usability Testing mit Testplan und Probanden über Prototyping bis hin zu umfangreichen Feldstudien. Obwohl alle Verfahren ihre Berechtigung und ihre spezifischen Vor- und Nachteile haben, bietet insbesondere die Heuristische Evaluation eine besonders gute Kosten-Nutzen-Effizienz.

Optimierung der Website Usability durch Heuristische Evaluation

Don’t make me think | photo by lucamascaro via Flickr

Was sind Heuristiken?

Im Grunde genommen sind Heuristiken einfache Verfahren (sozusagen „Faustregeln“), um sich einer Problemlösung anzunähern. Obwohl sie nicht den Anspruch haben fehlerfrei zu sein, sind sie durchaus nützlich, um eine Problemstellung innerhalb von kurzer Zeit zu analysieren.

Man kann die Heuristische Evaluation als Verfahren einsetzen, um die Usability einer Website zu analysieren (siehe auch: https://de.wikipedia.org/wiki/Heuristische_Evaluierung). Hierzu beurteilt ein kleiner Kreis von Experten (in der Regel 3-5 Personen) die Website anhand einer Liste von allgemein formulierten Heuristiken. Falls hierbei Hinweise auf Usability-Probleme gefunden werden, können diese den jeweiligen Heuristiken zugeordnet werden. Somit ist es möglich, allgemeine Aussagen darüber zu treffen, an welchen Stellen der User-Experience noch Optimierungsbedarf besteht.

Zwar muss ein solcher Experte kein Usability-Guru sein, er sollte aber schon über einige Jahre an praktischer Erfahrung im Bereich der Webgestaltung verfügen. Dafür kommen Frontend-Entwickler, Webdesigner, Webprojektleiter, aber natürlich auch auf Projektbetreuer auf Kundenseite in Frage. Wer regelmäßig mit Online-Projekten und der Gestaltung von Benutzeroberflächen zu tun hat, kennt die Prinzipien und Fallstricke der Usability und kann daher die Probleme in einem bestehenden System leicht identifizieren.

Es gibt verschiedene Heuristiken, die für die Heuristische Evaluation in Frage kommen. Im Folgenden werden beispielhaft die 10 Heuristiken vorgestellt, die Jakob Nielsen und Rolf Molich 1990 entwickelt haben und die Nielsen 1994 noch einmal verfeinert hat:

10 Heuristiken nach Nielsen

  1. Sichtbarkeit des Systemzustands
    Das System informiert den Nutzer darüber, was gerade passiert.
    Die Rückmeldungen sollen schnell erfolgen und eindeutig sein.
  2. Übereinstimmung zwischen System und Realwelt
    Das System verwendet bekannte Metaphern (z.B. „Diskette“ für „Speichern“).
    Technische Begriffe und Fehlercodes, die den Benutzer verwirren würden sollten vermieden werden.
  3. Benutzerkontrolle und Freiheit
    Ein System darf den Benutzer nicht in Situationen geraten lassen, aus denen er nicht wieder zurückfindet. Vielmehr sollte man als Nutzer Dialoge verlassen und Fehler korrigieren können. Aktionen sollten rückgängig gemacht und/oder wiederholt werden können.
  4. Konsistenz und Standards
    Benutzer sollten sich nicht über unterschiedliche Wortwahl für gleiche Situationen oder Aktionen wundern müssen. Plattformkonventionen sollten eingehalten werden
  5. Fehlerprävention
    Besser als gute Fehlermeldungen ist ein gutes Design, welches das Eintreten von Fehlern verhindert. Beispielsweise kann bereits bei der Eingabe von Werten eine unmittelbare Validierung erfolgen.
  6. Wiedererkennen statt sich erinnern
    Das Kurzzeitgedächtnis eines Benutzers ist begrenzt. Deshalb sollte er nicht gezwungen werden, sich an Informationen zu erinnern, die in einem anderen Bereich des Dialogs von Bedeutung waren. Objekte und Optionen sollten sichtbar sein und relevante Informationen die wieder benötigt werden permanent sichtbar bleiben.
  7. Flexibilität und Effizienz
    Das System sollte erfahrenen Nutzern die Möglichkeit bieten z.B. mit Tastaturkürzeln schneller ans Ziel kommen. Es sollte sich Präferenzen, die der Nutzer eingestellt hat merken.
  8. Ästhetik und minimalistisches Design
    Informationen sollten in einer natürlichen und logischen Ordnung erscheinen.
    Wichtiges darf nicht zwischen Unwichtigem „versteckt“ werden.
  9. Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern
    Fehlermeldungen sollten in einer einfachen Sprache gehalten sein (ohne Fehlercodes und ohne impliziten Vorwurf an den User). Sie sollten gut erkennbar sein, das Problem präzise beschreiben und konkrete Lösungsvorschläge anbieten
  10. Hilfe und Dokumentation
    Sofern Funktionalitäten erklärungsbedürftig sind, sollte eine Hilfe und/oder Dokumentation angeboten werden.

So führen Sie die Heuristische Evaluation durch

Zur Durchführung erhalten die Evaluatoren eine Tabelle. Darin können alle beobachteten Auffälligkeiten systematisch erfassen werden. Die Tabelle enthält Spalten für das Problem, die Stelle an der es aufgetreten ist, die verletzte Heuristik und der Schweregrad der Problematik.

Muster eines Evaluationsbogens

Muster eines Evaluationsbogens

Zugegeben – das Schema ist recht subjektiv. Dennoch lassen sich damit erfahrungsgemäß drei Viertel der Usability-Probleme einer Website identifizieren und für die Lösung priorisieren. Damit können bereits in einer frühen Phase der Projektentwicklung Usability-Probleme identifiziert und behoben werden. Dadurch erspart man sich teure nachträgliche Korrekturen. Deshalb ist die Heuristische Evaluation ein vergleichsweise kostengünstiges Verfahren.

Allerdings sollte eines nicht verschwiegen werden: Die „Experten“ stellen keine realen Nutzer dar. Um eine belastbare Aussage über die Effektivität, Effizienz und Nutzerzufriedenheit zu erhalten, sollte man auf einen zusätzlichen Usability-Test mit den eigentlichen Zielgruppen der Website nicht verzichten.

Merken

Merken

Alles Definitionssache – besonders in der Projektkonzeption

Amerikanische Wissenschaftler haben herausgefunden, dass über 70% aller Softwareprojekte in der Planungsphase zu wenig Zeit/Ressourcen in die Projektkonzeption investierten – und wenn amerikanische Wissenschaftler das noch nicht rausgefunden haben, dann sollten sie das schleunigst tun.

Was der Kunde beschrieb vs. Was der Kunde wirklich brauchte - klassisches Missverständnis in der Projektkonzeption

Aber ernsthaft: Wer schon mehr als eine Handvoll Projekte mitgemacht hat, kann mit ziemlicher Sicherheit eine ganze Reihe von Anekdoten erzählen. Was damals für schlaflose Nächte und zerraufte Haare gesorgt hat, wird mit der nötigen zeitlichen Distanz oft mit einem Lächeln erzählt werden und hatte hoffentlich einen Lerneffekt bei allen Beteiligten.

Was der Kunde sagt

Können Sie das nicht definieren? Sie haben da doch mehr Erfahrung…

Wer einer Feierlichkeit plant würde auf die Frage des Dienstleisters „Für wie viele Gäste müssen wir denn die Räumlichkeiten herrichten?“ wahrscheinlich nie die oben zitierte Antwort geben.
Woher sollte der Dienstleiter wissen, wie viele Personen eingeladen sind und wie viele dann im Endeffekt kommen?

In der IT hingegen sind solche Antworten nicht selten – z.B. in Bezug auf Serverdimensionierung. Das führt dann dazu, dass eine unterdimensionierte Infrastruktur von Anfragen überrannt wird, Benutzer verärgert werden und Kunden zornig bei Dienstleistern anrufen. Und dann muss „mit heißer Nadel“ in nächtlichen Sitzungen die Applikationssoftware optimiert oder die Hardware aufgestockt werden.

Gut – in Zeiten von Cloud-Lösungen und skalierenden Systemen kann recht dynamisch auf veränderliche Anforderungen reagiert werden, aber auch hier gibt es Grenzen. Denn was in der Programmierung nicht berücksichtigt wurde, kann auch durch mehr Hardware nur bedingt kompensiert werden. Und wenn im Vorfeld – wahrscheinlich aus Kostengründen – keine dynamische Lösung geplant wurde, nutzt auch die ganze Magie der Cloud nichts…

Natürlich kann man nicht erwarten, dass ein Auftraggeber über umfangreiche Erfahrung verfügt, welche IT-Lösung für die Anforderungen angemessen ist. Aber zumindest sollte er die eigenen Anforderungen kennen oder das zu erwartende Mengengerüst definieren können. Mitunter reicht es schon aus, wenn die notwendigen Hinweise gegeben werden, so dass man im Dialog eine belastbare Lösung planen und umsetzen kann.

Was die Projektkonzeption braucht

Mit der Aktion werden acht Millionen Personen angesprochen

Dann werden daraus zwar nicht zwangsläufig acht Millionen Nutzer, aber es gibt eine maximale Obergrenze. Und damit kann dann anhand von Erfahrungswerten die reale Nutzerzahl genauer eingegrenzt werden.

Die Kampagne wird von massiver Printwerbung flankiert

Das wird die Zahl der realen Nutzer mit großer Wahrscheinlichkeit erhöhen.

Am Wochenende sind TV- und Radiowerbung geschaltet und für Donnerstag ist Bannerwerbung bei einem großen Webportal gebucht

Das sind Zeiträume, in denen mit Besucherspitzen zu rechnen ist!

Aber was ist die Ursache, dass Kunden mit solchen wichtigen Informationen hinter dem Berg halten? Eine Vermutung ist – Achtung: Unterstellung! – dass Budgetverantwortliche beim Kunden primär auf die Initialkosten eines Projekts schauen. Dadurch werden sie dazu verleitet, bei den Projektkennzahlen eher zu untertreiben. Keiner möchte am Ende dafür verantwortlich sein, dass eine überdimensionierte Lösung in Auftrag gegeben wurde. Wer etwas Erfahrung hat, weiß, dass das eine Milchmädchenrechnung ist, denn nachträgliche Anpassungen an Applikationssoftware oder Infrastruktur generieren zusätzliche Kosten.
Kosten, die vom Kunden getragen werden müssen und so im Endeffekt das Projekt teurer machen.

Und mit Infrastructure as a Service und einem Content Delivery Network können sogar sehr schwer abzuschätzende Projekte oder Projekte mit stark schwankenden Nutzerzahlen umgesetzt werden, ohne dass Unsummen in eine ausreichend dimensionierte Infrastruktur gesteckt werden, die sich dann vielleicht zu 80% der Zeit „langweilt“.
Man bezahlt bei diesen Modellen – abgesehen von den Grundkosten – ja nur das, was auch wirklich an Ressourcen abgerufen wird.

Lerneffekt

Also: den Kunden in die Pflicht nehmen, ihn nicht mit ausweichenden Antworten oder Schulterzucken durchkommen lassen, auf belastbare Zahlen bestehen bzw. genauere Definitionen gemeinsam erarbeiten.
Eigentlich sollte die Aussicht auf ein gelungenes Projekt genug intrinsische Motivation für den Kunden sein um zielführend bei der Projektkonzeption mitzuarbeiten und „mit offenen Karten zu spielen“.
Aber manchmal braucht es da eine kleine Erinnerung oder ein „Anstubsen“.

(Bildquelle: Paragon Innovations, Inc.)

Merken