Heuristische
Evaluation
"Discount
Engineering Method for Usability Testing"
Vortrag
im Rahmen des Seminars "Software-Ergonomie"
an der Humboldt Universität Berlin
von
Henning
Brau
Einleitung
Maßnahmen zur Evaluation von
Software Usability wurden lange Zeit nicht oder
nur selten durchgeführt, obwohl jedem, der
bereits mit einer problembehafteten Oberfläche
arbeiten mußte, klar sein dürfte, daß
dies wahrlich nicht der richtige Ort ist, mit der
Kostensenkung zu beginnen.
Tatsächlich kann eine Applikation
alle Funktionalitäten aufweisen, um sie im
Grundsatz zu einem wahren Verkaufsschlager zu machen:
Wenn der Zugang zur Problemlösung unnötig
erschwert wird - der User also sich an die Software
anpassen muß, anstelle seine Erwartungen hinsichtlich
der Bedienung erfüllt zu sehen - dann ist zumindest
wirtschaftlich zunächst mit dem Schlimmsten
zu rechnen.
Das die vorhandenen Evaluationsmaßnahmen
für Software Usability nicht eingesetzt wurden,
war zumeist eine Funktion der Gestaltung dieser
Methoden – also quasi ebenfalls ein Usabilityproblem:
Sie waren zu umständlich und damit nur schwer
und langwierig zu erlernen, sie waren zu aufwendig
und ihr Einsatz damit insgesamt zu teuer.
Die Folge war, daß oftmals
auch gravierende Designfehler erst aufgedeckt wurden,
nachdem ein Programm
in den Markt eingeführt wurde. Damit machte
man den Käufer zu einer Art "Beta-Tester",
der erst auf überarbeitete Versionen warten
mußte, um zu einem befriedigenden oder zumindest
befriedigenderen Arbeiten zu kommen. Insofern nach
Abschluß der Hauptprogrammierarbeiten grundlegende
Korrekturen am Interface überhaupt noch möglich
waren.
Zwar wird es niemals eine wirklich
optimale Software geben, denn Nutzer werden immer
wieder Verbesserungsmöglichkeiten aufdecken,
aber eine gründliche Evaluationsmaßnahme
vor Markteinführung und schon während
des Softwaredesigns sollte in der Lage sein, die
meisten kritischen Punkte aufzudecken.
Obwohl der Benefit solcher Evaluationsmaßnahmen
von wohl allen softwareproduzierenden Unternehmen
anerkannt wird, sehen die meist knappen Budgets
keine oder nur wenige Spielräume für umfassende
Usabilitytests vor. Hier schlägt auch der gnadenlose
Preiskampf und der rasende Veralterungscharakter
von Software auf dem Markt zu Buche.
Ziele
der heuristischen Evaluation
Mit der heuristischen Evaluation
schlagen Nielsen & Molich (1990) eine Vorgehensweise
vor, die einen anderen Weg als die bis dahin vorliegenden
Methoden geht. Nicht länger sollen strategisch
alle Probleme ohne Rücksicht auf Zeit und Kosten
aufgedeckt werden, sondern möglichst viele bei einem
gegebenen (zuvor errechneten) Aufwand. Wenn z.B.
das Budget lediglich 10.000,- Euro für Usabilitytests
vorsieht, dann muß mit eben diesem Betrag
ein möglichst optimales Ergebnis erzielt werden.
Dieses entspricht dem ökonomischen Maximalprinzip.
Ziel ist also nicht, wissenschaftlich
genaue Ergebnisse zu produzieren, sondern ganz pragmatisch
einen möglichst hohen wirtschaftlichen Benefit
zu ermöglichen. Vor allen Dingen sollte die
heuristische Evaluation im Hause durchgeführt
werden können, um zusätzliche Institutskosten
zu vermeiden.
Um diese Ziele zu erreichen, muß
dieses Verfahren drei Kriterien erfüllen:
Es muß leicht
zu erlernen sein (schneller Zugriff von Softwareexperten
auf die Vorgehensweise der Methode).
Es muß schnell
durchzuführen sein (ein bis zwei Tage).
Es muß möglichst
günstig sein; die Kosten der Maßnahme
müssen je nach den Möglichkeiten des
evaluierenden Unternehmens zu Lasten der Genauigkeit
der Ergebnisse anpaßbar sein.
Newman & Lamming (1996) beschreiben
das heuristische Vorgehen als eine Orientierung
an Faustregeln und erlernten Zusammenhängen.
Dies bedeutet also, daß die aufgestellten
Richtlinien (Heuristiken) nicht standardisiert sind
und das Vorgehen der Evaluatoren informell und subjektiv
ist.
Die
Evaluatoren
Die heuristische Evaluation ist als
Verfahren konzipiert, das von Experten durchgeführt
wird. "Experte" bezieht sich hier weniger
auf die Erfahrenheit im Softwaredesign oder gar
-programmierung, sondern eher auf das Wissen um
Usability im allgemeinen. Ein in Ergonomiefragen
erfahrener Ingenieur, der sich bis dato ausschließlich
mit dem Design von Fräsmaschinen auseinandergesetzt
hat, kann schon nach relativ kurzer Einarbeitungszeit
eher ein Experte im Sinne der heuristischen Evaluation
sein, als ein langjährig erfahrener Programmierer,
der sich noch nicht mit Nahtstellendesign auseinandergesetzt
hat. Die entscheidende Frage ist also der geschärfte
Blick für potentielle Problembereiche im Design
einer Systemoberfläche, nicht das Wissen um
technische Hintergründe. Eine Kombination aus
beidem wäre natürlich noch besser. Die
Evaluatoren können sich durchaus auf unterschiedliche
Weise qualifizieren. So sind erfahrene Anwender
denkbar, die über ein tiefes Verständnis
einer Anwendung und deren empirische Evaluierung
verfügen, Medien- und Systemberater, die sich
auf Benutzbarkeitsaspekte spezialisiert haben, sowie
natürlich MCI-Spezialisten.
Empirische Untersuchungen haben gezeigt,
daß unterschiedliche Evaluatoren auch verschiedene
Usability Probleme in einer Mensch-Maschine-Nahtstelle
finden. Deswegen kann generell gesagt werden, daß
die heuristische Evaluation nicht nur von einem
Evaluator durchgeführt werden sollte. Tatsächlich
kann es sein, daß eine Person deutlich weniger
Probleme insgesamt findet, als ihre Kollegen im
Durchschnitt, sie dafür aber zwei oder drei
Probleme aufdeckt, die kein anderer gesehen hat.
Sehr verallgemeinert gesprochen, gilt eine Gruppe
von drei bis fünf Evaluatoren als Richtempfehlung
(vgl. Grafik). Bei fünf Evaluatoren werden
nach empirischen Untersuchungen immerhin 75% aller
im Design vorhandenen Probleme gefunden.
Je komplexer allerdings die Applikation,
desto größer die Gefahr von problematischen
Punkten, desto höher sollte die Anzahl der
Evaluatoren sein. Hier wird man zunächst eine
Kosten-Nutzen-Rechnung vornehmen müssen, um
die jeweils optimale Anzahl von Evaluatoren zu bestimmen,
denn natürlich bringt der Einsatz von weiteren
Evaluatoren auch weitere Kosten mit sich.
IV. Vorgehensweise
Jeder Evaluator geht bei der heuristischen
Evaluation das Interface mindestens zwei mal alleine
durch. Die Wiederholung dient dabei einer möglichst
vollständigen Erfassung der Probleme, nachdem
man sich mit den grundlegenden Funktionsweisen der
Software vertraut gemacht hat.
Grundsätzlich gilt: Je mehr
Durchgänge, desto besser; meist werden aber
bereits zwei bis vier Durchgänge ausreichend
sein. Die tatsächliche Anzahl der Durchgänge
wird sich wiederum nach Überlegung einer Kosten-Nutzen-Analyse
richten.
Eine gute Idee ist es sicherlich,
die Evaluatoren ihre Ergebnisse an einen unabhängigen
Experimentator zur Auswertung weitergeben zu lassen,
der den Evaluatoren auch während der Durchführung
bei Problemen im Umgang mit der Software an sich
behilflich sein kann. Aus Kostengründen empfiehlt
es sich hier, diese Berichte mündlich zu geben
und eine schriftliche Zusammenfassung erst danach
durch den Experimentator schreiben zu lassen. Eine
Kommunikation der Evaluatoren über ihre Ergebnisse
wird erst nach Abschluß der Durchgänge
gestattet, um eine unabhängige Beurteilung
zu garantieren und eine Fokussierung auf nur wenige
Probleme zu vermeiden.
Die Vorgehensweise mag nicht sonderlich
den Idealen einer nachvollziehbaren wissenschaftlichen
Dokumentation entsprechen, aber noch einmal: Die
heuristische Evaluation ist ein pragmatisches und kostenorientiertes
Verfahren.
In Informatikerkreisen wird so ein Vorgehen auch
gerne als "Quick
and Dirty" umschrieben: Die gewünschten
Ergebnisse auf eine unelegante aber effiziente Weise
erzielen.
Das Evaluationsszenario kann man
sich wie in einer Schulklasse bei einer Klausur
vorstellen. Die Evaluatoren sitzen getrennt voneinander
an ihrem Bildschirm und dürfen nicht miteinander
kommunizieren. Immer, wenn ein Evaluator einen Problembereich
gefunden hat, signalisiert er dies dem Experimentator,
der dann hinzukommt und aufnimmt, wo und gegen welche
Heuristik verstoßen wurde.
Der Experimentator muß also ein
Experte für die vorliegende Software (günstigstenfalls
auch der Problemdomäne) sein, während
dieses bei den Evaluatoren selber nicht unbedingt
erforderlich ist. Dieses eröffnet die Möglichkeit,
auch Experten als Evaluatoren einzusetzen, die keine
Erfahrung mit vergleichbaren Applikationen haben.
Ebenfalls sind Tests mit Anwendern
möglich, die vielleicht keine Ahnung von Software
Usability haben, dafür aber Experten in dem
Anwendungsbereich der Software sind. Denn damit
verfügen sie bereits über mentale Modelle
über den Einsatzbereich der Software und können
Hinweise für eine potentielle Gestaltung geben.
Im geringsten Fall wird für einen ersten Evaluationsschritt
bereits eine ausgedruckte Papierversion der Software
ausreichen, um einen grundlegenden Überblick
über die Erwartungen von potentiellen Nutzern
an die Applikation zu erlangen. Dies eröffnet
also eine Möglichkeit zur Evaluation zu einem
Zeitpunkt, an dem die Software als solche noch in
der reinen Planungsphase ist ("kalte Einschätzung").
Der Experimentator kann dann die Kommentare der
User aufzeichnen und muß nicht ihre Aktionen
interpretieren. Dennoch ist die heuristische Evaluation
ein Expertenverfahren, so daß Usertests eher
als Ergänzung zu den Ergebnissen der Softwareexperten
gesehen werden sollten.
Handelt es sich um eine "Walk-up-and-use"-Nahtstelle,
wie sie z.B. bei Fahrkarten- oder Geldspielautomaten
vorkommen, oder wenn die Evaluatoren zugleich Experten
der Anwendungsdomäne sind, wird man auf eine
weitere Einführung in die Domäne verzichten
können. Ansonsten hat sich die Beschreibung
eines typischen Szenarios aus dem Arbeitsalltag
der späteren Nutzer der Software, mit allen
nötigen Arbeitsschritten zur Bewältigung
der Situation, bewährt um die Inspektoren für
den Arbeitsbereich der Software zu sensibilisieren.
Um dieses anbieten zu können verlangt es allerdings
zuvor einer detaillierten Aufgabenanalyse der realen
Arbeitsumgebung.
Der Output der heuristischen Evaluation
besteht in einer Liste von einzelnen Usability Problemen
mit Referenzierungen zu den verletzten Prinzipien
und Begründungen, inwieweit diese Prinzipien
verletzt wurden. Da es nicht immer möglich
sein wird, alle Probleme eines Nahtstellenelementes
zu lösen, sollten die Probleme nicht zusammengefaßt,
sondern jeweils einzeln dokumentiert werden, damit
später möglichst viele kritische Stellen
behoben werden können. Auch scheint es so zu
sein, daß das Finden und das Analysieren von
Problemen unabhängige Prozesse sind, die nicht
in einen Durchgang gezwungen werden sollten. Eine
Interpretation erfolgt also zum Zeitpunkt der Evaluation
noch nicht, weil dies den Suchprozeß als solchen
stören würde. Der Evaluator erhält
erst anschließend eine Liste "seiner"
Probleme wieder und gibt eine Bewertung hinsichtlich
ihrer Fatalität ("Severity") und
in wie fern gegen eine Heuristik verstoßen
wurde, ab.
Diese kumulierten Schwerebewertungen
der einzelnen Inspektoren führen später
zu einer Priorisierung von Problemen, d.h., die
Probleme einer Oberfläche werden erfaßt
und dahingehend gefiltert, daß schwer zu behebende
oder weniger gravierende Probleme in der Betrachtung
zurückgestellt werden. Dieses Vorgehen war
nicht Bestandteil der ersten Version der heuristischen
Evaluation. Es hat sich aber herausgestellt, daß
es gerade diese Möglichkeit der Bewertung der
gefundenen Probleme durch Usability Experten eine
der Kernstärken der Methode ausmacht, da hier
konkrete Entscheidungshilfen für eine relevante
Optimierung gegeben werden können. Mit steigender
Anzahl der beteiligten Evaluatoren an dieser Bewertung
steigt auch deren Reliabilität. Es ist also
empfehlenswert, nach Möglichkeit alle Evaluatoren
zu einer Stellungnahme zu bewegen.
Da die Probleme mit Usability Prinzipien
verbunden werden, ergeben sich viele Lösungsansätze
schon aus deren Wortlaut. Wenn das Problem darin
besteht, daß eine Inkonsistenz von Groß-
und Kleinschrift desselben Datensatzes auf zwei
unterschiedlichen Screens besteht, dann wird die
Lösung eben sein, die Darstellung zu standardisieren.
Die heuristische Evaluation gibt aber keinen Hinweis
darauf, welche der beiden Möglichkeiten in diesem
speziellen Fall die Bessere ist. Eine Möglichkeit,
das Verfahren in die Richtung einer systematischen
Lösungsfindung zu erweitern ist das Einführen
einer Debriefingsitzung. Sie wird im Anschluß
an die Evaluationssitzungen mit den Evaluatoren,
dem Experimentator und Mitglieder des Designteams
durchgeführt. Thema sind die gefundenen Usability
Probleme und die Diskussion über verschiedene
Lösungsansätze.
Aus Fallstudien hat sich folgendes
Vorgehen empfohlen:
A. Prä-evaluatives Training
Einführung in die
Methode und den Heuristiken generell, um eine
einheitliche Terminologie sicherzustellen.
Überblickshafte
Erläuterungen zur Domäne der Applikation
und ihrer zugrundeliegenden Problemstellung.
Schrittweise Präsentation
des Beispielszenarios ohne Screenshots zur Vermeidung
von Bewertungsbiases.
B. Evaluationssitzung
C. Debriefing
Besprechung aller gefundenen
Probleme mit möglichst allen beteiligten
Evaluatoren, dem oder den Experimentator(en)
und Mitgliedern des Designteams.
Diskussion über
grundlegende Charakteristika des Interface und
Vorschläge für potentielle Verbesserungen
für Hauptprobleme.
D. Fatalitätsbewertung
der gefundenen Probleme
Bewertung der aller gefundenen Probleme
durch die Evaluatoren anhand von vier Faktoren:
Frequenz des Auftretens
des Fehlers (einmalig bis laufend)
Einfluß des Problems
auf die Arbeitsabläufe (Nichtigkeit bis
schwerwiegende Störung)
Persistenz des Auftretens
(zufälliges bis regelmäßiges
Auftreten)
Markteinfluß (Wenn
ein schlechter Eindruck durch das Problem über
die Software insgesamt auftritt, ist die Frage
nach der objektiven Fatalität eher zweitrangig)
V.
Die Heuristiken
Die Evaluatoren bekommen - wie gesagt
- eine Liste mit standardisierten Heuristiken, die
sie auch noch um eigene Gedanken, die in einem spezifischen
Dialogelement wichtig sind, erweitern können.
Zusätzlich sind noch kategoriespezifische Heuristiken
möglich, die für eine Klasse von ähnlichen
Produkten als Erweiterung dienen, z.B. Heuristiken
für Tabellenkalkulationen. Hierzu wären
allerdings zunächst vergleichende Analysen
von existierenden Produkten einer Kategorie zur
Abstraktion neuer Prinzipien notwendig. Dies wird
also eher eine Arbeit für Usability-Institute
sein, die dann ihre Ergebnisse an Unternehmen weitergeben.
Die Originalliste von Usability Heuristiken
nach Molich und Nielsen (1990) umfaßt zehn
Einträge. Diese sollen hier nicht bis ins Detail
besprochen, sondern inhaltlich umrissen werden.
Einfache und natürliche
Dialoge:
Das User Interface sollte so einfach
wie möglich und komplex wie nötig gestaltet
werden, da jede Information im Interface interpretiert
werden muß, mißverstanden werden kann
oder von der gesuchten Information ablenkt. Das
Design sollte der natürlichen Arbeitsumgebung
der Anwender entsprechen, damit vorhandene mentale
Modelle auf die Software übertragen werden
können, z.B. die Desktop-Metapher nach der
die Oberfläche eines Betriebssystems einer
Büroumgebung nahekommt.
Gelingt dies, sind eine erhöhte
Fehlerstabilität und verkürzte Einarbeitungszeiten
der Erfolg. Möglichst alle Abläufe sollten
frei gestaltbar sein und nur dort chronologisch
festgelegt, wo ein Abweichen von der Sequenz das
Ergebnis gefährden könnte, z.B. bei Sicherheitssystemen.
Es muß verstanden werden, daß
ein gelungenes Screendesign der Schlüssel zum
Verständnis der Softwareoberfläche ist.
Deshalb sollte diese Aufgabe auch Grafikdesignern
und nicht den Programmierern als Designlaien überlassen
werden.
Als Meßmöglichkeit für
den hoffentlich gelungenen Einsatz von Designelementen
kann man die sogenannten "Mumblescreens"
heranziehen. Diese Screens beinhalten die normalen
Datensätze und Displayitems des fertigen Produktes.
Anstelle der Texte sind hingegen sinnlose Buchstabenfolgen
eingesetzt. Ist der Betrachter trotz der fehlenden
Textinformation in der Lage, die Funktionen und
Anzeigen des Layouts zumindest annähernd richtig
zu identifizieren, kann das Design so schlecht nicht
gewesen sein.
Das Design sollte die Regeln der
Gestaltpsychologie (Wertheimer et. al., 1912) beachten,
mit ihren berühmten Gesetzen. Damit soll die
Struktur des Screens auch für den ungeübten
Anwender auf einen Blick deutlich werden. Exemplarisch
seien hier noch einmal die hier "wichtigsten"
benannt:
Gesetz der guten Gestalt
Gesetz der Nähe,
Gesetz der Geschlossenheit,
Gesetz des guten Verlaufs,
Gesetz der Ähnlichkeit,
Gesetz des gemeinsamen
Schicksals.
Viel schärfer als bis hierhin
kann man Designempfehlungen nicht benennen, ohne
in die Scharlatanerie abzudriften. Genaue Designgesetze
gibt es nicht, da die sinnvolle Darstellung immer
eine Funktion der Aufgabenstellung der Software
ist. So macht es wenig Sinn zu sagen, daß
nicht mehr als sieben Items auf einen Bildschirm
dargestellt werden sollten, wenn die Aufgabenstellung,
z.B. bei der Flugsicherung, hunderte von Items verlangt.
Die weiteren Hinweise sind deshalb mehr als Anstöße,
denn als Richtlinien zu verstehen.
Blinktexte und die durchgängige
Nutzung von GROßBUCHSTABEN für Hervorhebungen
sind zwar beliebt, belasten aber die Arbeitseffizienz,
da erstere den Anwender unnötig ablenken
und zweitere das schnelle Textscannen erschweren.
"Weniger ist mehr!"
denn
zusätzliche Information kann den User wie gesagt
von der Hauptinformation ablenken. Deswegen ist
es wichtig, die angebotenen Daten auf die jeweilig
signifikante Information zu reduzieren und redundante
Daten zu vermeiden. Eine Aufgabenanalyse kann die
jeweils wichtigste Information für bestimmte
Vorgänge identifizieren. Zusätzlich muß
die Option gegeben sein, auf Wunsch auch weitere
Information auf weiteren Screens anzufordern.
Info, die mit dem Programm
als solches zu tun hat (Versionsnummer, Kontaktadressen,
etc.), sollte auf den Start- oder Infoscreen
beschränkt bleiben.
Nach Studien von Springer
(1987) dauert das Suchen einer Information auf
einem Screen, die im oberen Viertel eines halb
mit Informationen gefüllten Schirm versteckt
ist, 0.9 Sekunden kürzer, als wenn der
Screen komplett mit Information gefüllt
ist. Das Auge verlangt also nach "white
Spaces" zur Orientierung anstelle überfrachteter
Screens.
Je mehr Optionen dem
User angeboten werden, desto verwirrender ist
die Auswahl gerade für ungeübte User.
Sinnvoll mögen Trainingseinstellungen sein,
die zunächst jeweils nur eine Option je
Aktion anbieten und damit eine Grundübersicht
geben. Geübte User können gleich höhere
Level mit mehr Optionen und somit wachsender
Komplexität anwählen. Durch ein derartiges
Trainingssystem wird die Software durch ungeübte
User schneller erlernt!
2. Spreche
die Sprache des Nutzers
Auch wenn Computer dazu verführen:
Die Sprache des Systemdialogs orientiert sich immer
an gesprochener Sprache, nicht an Systemausdrücken.
Der Nutzer geht davon aus, daß es sich bei
den Programmierern um fachkompetente Spezialisten
handelt, sie benötigen keinen Beweis dafür.
Und noch viel weniger werden sie sich Wörterbücher
Deutsch – Fachidiotisch kaufen, damit sie die Oberflächensprache
verstehen können.
Konkret heißt dies: Soweit
möglich sollte die jeweilige gesprochene Muttersprache
in den Systemdialog eingeführt werden. Das
wiederum verlangt die Vermeidung von Neologismen
und neuen Bedeutungen von vermeintlich bekannten
Ausdrücken.
Natürlich kann man nicht immer
auf domänenspezifisches Vokabular verzichten,
da gewisse Ausdrücke nicht, nur unzureichend
oder zu umständlich durch gesprochene Sprache
umschrieben werden können, z.B. in Statistikprogrammen
wie SPSS. Hier bleibt aber wichtig, daß auch
domänenspezifisches Vokabular nur dann angewandt
werden darf, wenn es für die User als Standard
und bekannt angenommen werden kann.
Wenn für Bedienelemente verschiedene
Begriffe angemessen scheinen, sollten dieses Naming
im Vorfeld in Absprache mit späteren potentiellen
Nutzern stattfinden. Die Nutzer sollten auch die
Möglichkeit haben, komplexe oder selbsterstellte
Befehlsketten, z.B. Makros, selbst zu benennen.
Auf jeden Fall empfiehlt es sich,
über eine Aufgabenanalyse der Domäne gute
Mappings für vorhandene mentale Modelle in
das System herausfinden (Metaphern). Allerdings
ergibt sich hierbei immer das Problem der kulturellen
Übertragbarkeit, so sind die Metaphern "Trashcan"
(Mülleimer) oder "Desktop" (Schreibtisch)
nur in Kulturen mit westlicher Büroausstattung
verständlich.
3. Minimierung
der Arbeitsspeicherbelastung der Nutzer
Soviel ist klar: Das Speichern von
sinnleeren, abstrakten oder mathematischen Daten
können Computer besser als wir. Stellt sich
die Frage, warum wir es ihm nicht einfach überlassen
sollten? Vielfach sind diese Möglichkeiten
bereits in bekannten Betriebssystemen umgesetzt,
doch es werden sich immer noch Optimierungsmöglichkeiten
finden lassen.
Beispiele für Gedankenstützen:
Menüs dienen
als Gedankenhilfe für mögliche Befehle.
Der Rename-Befehl zeigt
zunächst den alten Namen an.
Kommandos unter DOS
zeigen alle möglichen Optionen und
Eingabeformate an.
Im Allgemeinen werden
wahrscheinliche Werte und Maßeinheiten
in Applikationen voreingestellt und
können optional verändert und gespeichert
werden.
Nutzung von generischen
Befehlen, die für alle Bereiche
und Applikationen gleich sind ("Strg-X"
für Löschen)
4. Konsistenz
Wenn der User die Reaktionen und
Darstellungen einer Applikation für voraussagbar
hält, erhöht dieses das Vertrauen in die
eigene Leistung und in die der Software. Dies kann
dazu führen, daß der Anwender sich explorativ
den Funktionen annähert und von sich aus die
Applikation und ihre Möglichkeiten erlernt.
Diese Voraussagbarkeit erlangt man vor allen Dinge
dadurch, daß man die Aktionen konsistent hält.
So sollte identische Information immer auf die gleiche
Art präsentiert werden.
Am leichtesten ist dies durch Einhaltung
von Interfacestandards (GUI-Styleguides) zu erreichen,
welche die Implementierung von Items bereits detailliert
beschreiben. Mindestens ebenso wichtig ist aber
eine Konsistenz der Aufgaben- und Funktionsstruktur.
Einen nicht unmaßgeblichen Beitrag hieran
haben generische Befehle, insbesondere eine verläßliche
und mehrstufige Undo-Funktion.
5.
Feedback
Der Anwender sollte laufend Feedback
über seine Aktionen und deren Interpretation
seitens des Systems erhalten - sowohl positiv als
auch negativ. Dazu gehören insbesondere konkrete
Wiedergaben der Eingaben des Users hinsichtlich
ihrer Folgen, z.B. eine Warnungsmeldung vor dem
endgültigen Formatieren einer Festplatte. Ist
der Computer zu schnell, wie beim Scrollen von Informationen
in einer langen Liste, muß das Feedback so
verzögert werden, daß der Anwender die
Informationen dennoch scheinbar zeitgleich wahrnehmen
kann, obwohl der Rechner mit der eigentlich Operation
bereits fertig ist.
Ein anderer wichtiger Punkt ist die
wahrgenommene Unterbrechung der Systemaktivitäten
während einer Phase der Berechnung. Beträgt
die Antwortzeit weniger als eine Sekunde wird keine
"wirkliche" Unterbrechung wahrgenommen,
d.h., zwar bemerkt man eine Verzögerung, es
wird aber kein Feedback benötigt. Dieses ändert
sich aber mit der zunehmenden Zeit der Unterbrechung.
Bis zehn Sekunden fokussiert der Anwender seine
Aufmerksamkeit im allgemeinen auf den Dialog. Danach
will er darüber hinaus bereits andere Aktionen
ausführen, bis der Computer fertig ist – und
sei es nur Blumengießen. Hier indiziert ein
sogenannter Prozentbalken, wie lange der Computer
voraussichtlich noch benötigt, dient als optische
Ablenkung zur Überbrückung der Wartezeit
und – besonders wichtig! – indiziert, daß
der Rechner nicht abgestürzt ist, sondern noch
aktiv in der Berechnung steckt. Denn wohl nichts
ist für einen Anwender schlimmer, als wenn
er nicht erkennen kann, ob noch alles in Ordnung
ist, oder die Arbeit von zwei Stunden verloren gegangen
ist.
Deshalb ist insbesondere im Falle
eines Systemfehlers ein Feedback unerläßlich.
Wenn es gar nicht anders geht, mag auch eine abstrakte
Mitteilung genügen, wie der allseits gefürchtete
"schwere Ausnahmefehler" unter Windows.
Dennoch sollte man schon in der Planung Fehlersituationen
bedenken und Routinen implementieren, die im Falle
eines Crashes unabhängig von der eigentlichen
gerade abgestürzten Applikation eine Meldung
in verständlicher Sprache ausgeben und Lösungsmöglichkeiten
anbieten.
6. Klar
markierte Ausgänge
Je mehr Ausstiegs- und Cancelmöglichkeiten
der Anwender erkennen kann, desto größer
ist sein Gefühl der eigenen Kontrolle über
die Applikation. Eine mehrstufige Undo-Funktion
ermöglicht dabei ein exploratives Verhalten
auch für unerfahrene Anwender, da sie sich
darauf verlassen können, daß ihre Eingaben
keine unwiderruflichen gravierenden Fehler hervorrufen
können. Sie sollte als generisches Kommando
immer im Sichtfeld sein.
Der Grundgedanke ist dabei: Der größte
Fehlermultiplikator sitzt immer vor dem Computer.
Denn User – erfahren oder unerfahren - machen immer
Fehler, unabhängig von allen Verbesserungen
des Interfaces. Dafür sind wir schließlich
Menschen. Aus diesem Grund müssen alle Aktionen,
wenn irgend möglich, reversibel sein.
Aber auch der Abbruch von laufenden
Prozessen ist wichtig, da Bearbeitungszeiten oftmals
falsch eingeschätzt oder falsche Parameter
zu einer erheblich verlängerten Bearbeitungszeit
führen können. Man stelle sich vor, die
erste Berechnung eines Computers zu wissenschaftlichen
Zwecken überhaupt – nämlich die Berechnung
der Entfernung des Mondes von der Erde, die in "nur"
drei Tagen bewerkstelligt werden konnte – hätte
wiederholt werden müssen, weil ein Programmierer
ein Komma falsch gesetzt hat...
7.
Abkürzungen
Dem erfahrenen Anwender sollten immer
auch Dialogabkürzungen als Angebot zum effizienteren
Arbeiten angeboten werden. Hierbei empfehlen sich
Wortabkürzungen, Belegung der Funktionstasten,
generische Befehle über die Steuerung-Taste
(STRG), Doppelklick zum Ausführen der Hauptfunktionen
einer Datei sowie die Anwendung von Makros und Skripten
zur Abarbeitung von Blockbefehlen.
8.
Gute Fehlermeldungen
Fehlermeldungen sind gleich auf zwei
Arten für das Usability Engineering wichtig:
Der User hat Probleme,
hier muß geholfen werden.
Der User könnte
hier lernen, besser mit dem System umzugehen.
Bei der Ausgabe von Fehlermeldungen
gibt es daher vier Regeln:
Klare, konkrete Sprache
ohne obskure Codes ("Schwerer Ausnahmefehler
$33366-88776qxl-dd77&%9b" ist nicht
wirklich hilfreich für Nicht-Systemspezialisten)
Präzise Angabe
der Fehlerquelle ("Kein Zugriff auf Datei
A:/Dokumente/Brief1.txt – Datei ist schreibgeschützt"
anstelle "Kein Zugriff")
Konstruktive Hilfestellung
und Versuch der Interpretation der fehlerhaften
Eingabe durch das System ("Do What I Mean"
anstelle von "Do What I Say")
Höflich und nicht
herabwürdigend, denn wer läßt
sich schon gerne von einem Haufen Silicium-Halbleitern
beschimpfen?
Multiple-Level Messages ermöglichen
durch die Verbindung von der Fehlermeldung zu einer
entsprechenden Stelle des integrierten Manuals via
Hypertext die Einbindung konkreter Lösungsvorschläge
für den Anwender.
9.
Fehler vermeiden
Standardsituationen, die als fehlerträchtig
bekannt sind, sollten möglichst durch ein cleveres
Systemdesign vermieden oder entschärft werden.
Texteingaben sind immer
problematisch, da Anwender sich vertippen können.
Wenn möglich sollten Auswahltexte angeboten
werden.
Eingaben mit ernsthaften
Konsequenzen sollten vor der Ausführung
mittels eines Systemdialogs konfirmiert werden.
Dieses Stilmittel ist aber sparsam einzusetzen,
da die Nutzer sonst diese Warndialoge automatisch
wegklicken.
Verfügt eine Applikation
über verschiedene Modi, verliert der User
schnell die Übersicht, in welchem Modus
er sich gerade befindet, was zu Fehlern führen
kann. Mal ehrlich: Wer hat noch nie versucht
im Seitenansichtsmodus von Word oder Excel Daten
einzugeben? Man sollte also auf Modi weitgehend
verzichten und dort, wo ein Verzicht unmöglich
ist, den Modus mittels farblicher Kodierung
deutlich machen.
Vermeidung von zu ähnlichen
Kommandos generell. Eine Searchfunktion die
nur Worte findet, die korrekt groß bzw.
Klein geschrieben sind, arbeitet zwar höchst
präzise, aber meist zu umständlich.
Zumal ein ansonsten klein geschriebenes Verb
am Satzanfang groß geschrieben wird. Eine
case-sensitive Suche müßte hier also
doppelt durchgeführt werden.
10.
Hilfe und Dokumentation
Das Vorhandensein eines Manuals darf
noch lange keine Entschuldigung für ein problematisches
Interface sein. Die fundamentale und ungemein schockierende
Wahrheit ist: User lesen keine Manuale. Das ist
keine rücksichtslose Gemeinheit gegenüber
den Programmierern, sondern ein Eindruck ihrer hohen
Motivation. Denn Anwender wollen - sobald die Software
fertig installiert ist - produktiv loslegen. In
konkreten Problemsituationen wird dann nach einer
akuten Problemlösungshilfe ohne langes Suchen
verlangt. Deswegen:
Das Manual sollte im
Programm selber integriert sein und in separaten
kleinen Fenstern angeboten werden, damit die
Sicht auf die Applikation nicht verdeckt wird
und die Lösungsvorschläge während
des Lesens in der Applikation ausprobiert werden
können,
es sollte hypertextuell
sein, um Querverweise nutzen zu können,
es sollte kontextsensitiv
sein und somit auf die Nöte des Anwenders
reagieren und
es sollte die Möglichkeit
der aufgabenorientierten Abfrage anbieten.
Manuale sind heute zumeist de facto
Unterprogramme der Applikation und damit wieder
kritisch auf Usability Probleme zu durchleuchten.
Insbesondere da sie ohne weitere Hilfestellung zugänglich
sein müssen, da ein Manual für das Manual
nicht sehr sinnvoll erscheint.
Aber wichtiger als der Zugang zum
Manual ist die Qualität der Texte selber. Hier
scheint es unumgänglich das Textdesign durch
Medienberater oder technische Schreiber ausführen
zu lassen.
IV.
Literaturangaben
Nielsen, J. & Mack, R.L. (1994).
"Heuristic Evaluation". In Wiley, J. "Usability
Inspection Methods", 25 - 61.
Nielsen, J. (1993). "Usability
Engineering". AP Professional.
Redmond-Pyle, D. & Moore,
A. (1995) "Graphical User Interface Design
and Evaluation". Prentice Hall.
Preim, B. (1999) "Entwicklung
interaktiver Systeme". Springer.
|
|
