|
Im Allgemeinen plädiere ich für qualitative Benutzertests:
Eine
Hand voll Benutzer reicht, um
die meisten Designmängel aufzudecken. Dennoch haben quantitative Tests ihre
Berechtigung und kürzlich haben wir aus zwei
Gründen umfangreiche Tests durchgeführt:
Wir haben hunderte von Benutzern getestet, um für unser Eyetracking-Seminar tiefergehende Erkenntnisse zu
gewinnen. Um beispielsweise festzustellen, ob Männer und Frauen sich Webseiten unterschiedlich ansehen, muss man viele
Leute testen, währenddem sie die gleichen Webseiten nutzen. Das liegt daran, dass die Nutzer quer über die Sites wandern
und wir für jede Seite genügend Männer und Frauen testen müssen, um ein ausreichendes Sample zu erhalten.
Für einige Kunden führen wir gross angelegte Benchmarking-Tests
durch, damit sie ihre Design-Verbesserungen über die Zeit hinweg
nachverfolgen können. Diese Studien sind wirklich aufwändig und für kleine Projekte empfehlenswert. Für grosse Projekte
allerdings liefern sie ein gutes, langfristig wirksames Management-Werkzeug.
Mit all den neuen Daten, die mir durch diese Tests zur Verfügung standen, konnte ich nicht
widerstehen, die 1520 Messungen der „time-on-task“-Performanz der Nutzer für Websites und Intranets zu analysieren.
Folgt die Usability einer Normalverteilung?
Fast alle statistischen Analysen setzen voraus, dass die Daten einer Normalverteilung folgen. Die
meisten Leute vertrauen einfach darauf, dass dem so ist, weil es für viele Phänomene zutrifft. Gilt das auch für die
Usability?
Ein Weg die Verteilung eines Datensatzes zu überprüfen ist, ein QQ-Plot zu erstellen, in dem wir
den empirischen Wert jeder Beobachtung auf der x-Achse und den hypothetischen Wert auf der y-Achse einzeichnen, der bei einer
Normalverteilung auftreten würde. Wir zeichnen eine Gerade ein, die den Fall repräsentiert, dass empirische und
hypothetische Werte übereinstimmen.
Wenn unsere eingezeichneten Datenpunkte sehr dicht bei der Geraden liegen, schliessen wir daraus, dass
die empirischen Werte sehr dicht bei den hypothetischen Werten liegen. Mit anderen Worten, die beobachteten Daten sind
so wie die Theorie vorausgesagt hat; der Datensatz folgt also einer Normalverteilung.
Alle Datenpunkte, die weit von der Geraden entfernt liegen, stehen für Fälle, in denen reale
und theoretische Welt substanziell auseinander lagen – mit anderen Worten, die Daten folgen nicht der Normalverteilung.
Ich habe von unseren neuesten quantitativen Studien siebzig QQ-Plots
vorliegen und alle sehen gleich aus, gleichgültig ob sie aus
Website- oder Intranet-Studien stammen. Hier zwei typische Beispiele:
QQ-Plots von zwei Benutzerstudien: Einem Test einer an Inhalten orientierten Zeitschriften-Website links (New York Magazine) und
einem Test einer transaktions-orientierten E-Commerce-Website rechts (Kiehl’s).
Jeder Punkt repräsentiert die Aufgabenlösungszeit eines Benutzers. Die x-Achse zeigt die gemessene Leistung an, die y-Achse die theoretische Leistung
gemäss der Normalverteilung.
(Anmerkung: Weil meine Analyse Benutzer ausschliesst, die die Aufgaben nicht lösen konnten,
zeigen die Diagramme nur diejenigen Leute, die die Sites erfolgreich benutzt haben. Alle siebzig Studien haben die Zeit pro Aufgabe
gemessen – beachten Sie einen früheren Artikel zur Definition von Usability nach anderen wichtigen qualitativen
Eigenschaften.)
Die Punkte liegen zwar nicht exakt auf der Geraden, aber ziemlich nahe dran. Es gibt ein paar
Ausreisser, aber trotzdem kann man die Schlussfolgerung ziehen, dass die meisten Nutzer einer Normalverteilung folgen.
Die Punkte liegen in jedem Fall nah genug, um die Arbeit zu steuern – oder besser gesagt: nah genug für jede Analyse,
die Sie in einem praktischen Entwicklungsprojekt brauchen.
Ausreisser mit schneller Durchführung der Aufgaben
Ausreisser in der linken unteren Ecke jedes QQ-Plots sind als volle blaue Punkte gekennzeichnet.
Dies sind Benutzer, die schnell waren, aber nicht so schnell wie von der Theorie vorausgesagt. Tatsächlich
liegen im linken QQ-Plot zwei Punkte unterhalb der x-Achse, haben also negative y-Werte. Die Theorie hat vorausgesagt,
dass diese beiden Nutzer ihre Aufgabe hätten durchgeführt haben müssen, bevor sie angefangen haben, was natürlich unmöglich
ist.
Bei Usability-Tests gibt es einen klaren unteren Grenzwert für gemessene Aufgabenlösungszeiten: Die
Leute können nicht schneller sein als ein bestimmtes Minimum, gleichgültig, wie effizient sie die Site nutzen. Seiten
herunterzuladen und die Hand zwischen Maus und Tastatur hin und her zu bewegen, erfordert eine gewisse Zeit. Auch die
schnellsten User brauchen etwas Zeit, um Eingaben in Suchmaschinen einzugeben; auch die schnellsten Leser brauchen Lesezeit, unabhängig
davon, wie schnell sie die Informationen, auf die es ankommt,auf einer Seite finden.
Alle Studien, die ich analysiert habe, enthielten ein paar schnelle Ausreisser. Diese schnellen
Benutzer (die aber nicht schnell genug waren), sind aber leicht zu erklären, und ich denke, sie sollten unsere
Gedanken über Web-Usability nicht beeinflussen.
Ausreisser mit langsamer Durchführung der Aufgaben
Die Ausreisser in der rechten oberen Ecke
sind als volle rote Punkte gekennzeichnet. Das sind die
Nutzer, die dramatisch langsamer waren als die vorausgesagt
langsamsten Nutzer.
Unter den 1520 Fällen waren 87
Ausreisser mit extrem langen Aufgabenlösungszeiten. Das
heisst: 6% der Benutzer sind Ausreisser am oberen Ende der
Skala. Das sind zu viele Leute, als dass man sie
ignorieren könnte. Sicher, man sollte zuerst und vor allem
das Benutzererlebnis jener 94% der Benutzer verbessern, die
rund um den Mittelwert liegen. Es lohnt sich aber auch jenen
langsamen 6% ein paar Usability-Ressourcen zu widmen.
Die naheliegendste Erklärung für diese
Ausreisser ist, dass es einfach ein paar Leute gibt, die beim
Benutzen des Webs so gut wie inkompetent sind und dass sich
diese bei jedem Test als langsame Ausreisser bemerkbar machen.
Doch diese Hypothese ist falsch. Wenn wir Leute für
eine Studie rekrutiert haben, lassen wir sie allerlei Dinge
tun. Daher wissen wir, wie die langsamen Ausreisser bei
anderen Aufgaben abschneiden. Im Allgemeinen waren die
gleichen Benutzer, die bei einigen Aufgaben extrem langsam
waren, bei anderen Aufgaben schnell.
Für die 87 Ausreisserfälle waren 60
verschiedene Benutzer verantwortlich; auf jeden davon kamen
also im Schnitt 1,5 Ausreisser. Da die Benutzer quer durch
alle analysierten Studien im Schnitt mit 6,7 Aufgaben getestet
wurden, hatte jeder dieser Benutzer im Schnitt 5,2 »normale«
Aufgaben – 3,5-mal so viele wie Ausreisser-Aufgaben.
Dieses Thema erfordert deutlich mehr
Forschung und wäre für etliche Examensarbeiten gut. Im
Moment ist meine beste Schlussfolgerung die, dass langsame
Ausreisser eher vom Pech verursacht wurden als von einer
anhaltenden Eigenschaft der fraglichen Benutzer.
Glücksfälle in der Benutzerleistung
Ehe wir zum Pech übergehen, sollten wir
uns anschauen, dass im Web auch Glücksfälle vorkommen.
Manchmal haben die Leute "unverdientes" Glück auf einer
Website und bekommen das, was sie suchen, mit weniger Klicks
als erwartet. Sei es zum Beispiel, dass sie nach etwas suchen,
das glücklicherweise gerade an diesem Tag auf der Startseite
beworben wird. Sei es in anderen Fällen, dass Benutzer ein
schweres Usability-Problem glücklich umschiffen, das anderen
Benutzern grosse Schwierigkeiten und viel Frust eingebracht
hat.
Hier ein Beispiel für einen Glücksfall
aus einem Test mit behinderten Benutzern beim Versuch,
die Website der IRS (der amerikanischen Steuerbehörde) zu
benutzen. Eine blinde Benutzerin wollte herausfinden, ob sie
Geld von der Steuer absetzen konnte, das sie an ein
Schulorchester gespendet hatte.
Da die IRS-Seite lang und überfüllt
war, entschied sich die Benutzerin, ihren Bildschirmvorleser
die Liste der Links auf der Seite vorlesen zu lassen.
Ausserdem wies sie, da sie nach Steuerregeln über Spenden (donations)
suchte, den Bildchirmvorleser an, alle Links vorzulesen, die
mit D begannen. Wie sich herausstellte, verwendete die
IRS-Site den Begriff Abzüge (deduct) und nicht den
Begriff Spenden (donation) – was die Benutzerin nie
entdeckt hätte, wenn sie die Seite oder Website einfach nach
dem Begriff "donation" durchsucht hätte. Doch da beide Wörter
mit D beginnen und die Person einen Bildschirmvorleser
benutzte, traf sie leicht und glücklich auf "deduction" als
korrekten Link. Ein erfreulicher Ausgang, der aber rein auf
einem Glücksfall beruhte.
(Hier sind noch einige zusätzliche Anmerkungen zur
Usability zu machen. Erstens, indem sie den Begriff "deduction"
[Abzüge] verwendete und nicht "donation" [Spenden],
entschied sich die Site für einen system-orientierten
Sprachgebrauch und gegen einen Begriff, der die Handlung des
Benutzers beschreibt, die zu unterstützen vermutlich der
Zweck der Site ist. Zweitens ist der Gebrauch der
Abkürzungsfunktion im Bildschirmvorleser ein
Expertenverhalten; Sie sollten ihn nicht als Entschuldigung
für lange Seiten verwenden, die weniger erfahrenen Benutzern
von Bildschirmvorlesern schaden. Drittens und letztens ist
die Funktion »Links vorlesen« einer der Gründe für die
Richtlinie, nach der man Benennungen wie »Hier klicken« oder
»Mehr« vermeiden soll, die nur im Kontext Sinn machen.)
Pech bei der Benutzerleistung
Die meisten Web- und Intranet-Benutzer
kennen das Pech nur zu genau. Hier ein paar typische
Beispiele:
- Ein Klick auf den falschen Link, und man
ist für immer im falschen Teil der Site verloren.
-
Man verwendet die falschen Wörter. Im
Gegensatz zum obigen Beispiel für einen Glücksfall können
die Benutzer signifikant viel Zeit verlieren, wenn sie nach
einem Begriff suchen, den die Site nicht verwendet und den sie
auch nicht mit ihrem bevorzugten Begriff referenziert.
-
Unternehmen mit mehreren Websites werfen
die Benutzer oft auf die falsche Site, aber die Benutzer
bemerken den Fehler nicht.
Der Link oder der Hinweis, die der Benutzer
braucht, sind aus dem Bildschirm gerollt und deshalb
sieht der Benutzer ihn nicht.
-
Ein Pop-up-Fenster lenkt die Benutzer
gerade in dem Moment ab, wo sie dabei waren, den richtigen Weg
zu finden.
- Eine Registrierungspanne führt die
Benutzer auf Abwege, die so lange dauern, dass ihr Versuch Sachen zu
kaufen untergeht, selbst wenn sie erfolgreich
gefunden hatten, was sie wollten, und es sicher im Warenkorb
untergebracht hatten.
-
Viele kleine Probleme – von denen
jedes einzelne für sich leicht gelöst werden könnte –
tauchen in einer Reihe hintereinander auf und werfen die
Benutzer aus der Bahn.
Keines dieser Dinge ist wirklich ein Unglück
in dem abergläubischen Sinne, dass irgendetwas "Unnatürliches"
passiert. Es sind alles nur Kleinigkeiten, aber tatsächliche
Mängel in der Usability des Designs. Was diese Schwachstellen
als Pechnasen qualifiziert, ist ihre Fähigkeit, die Benutzer
unter bestimmten Umständen geradezu ins Unglück zu stürzen.
Wenn es nur ein klein bisschen anders gelaufen wäre – sagen
wir, ein Benutzer hätte nur eine Zeile weitergescrollt –
dann hätte er vielleicht Glück und ein sehr
befriedigendes Benutzererlebnis gehabt.
In Anbetracht der Tatsache, dass sich die
langsamen Ausreisser zu 6% der Internet-Nutzungsfälle
summieren, ist es inakzeptabel, sie einfach abzuschreiben.
Auch wenn die Daten zeigen, dass die meisten Benutzer bei der
nächsten Online-Aufgabe das Pech umgehen, können Sie nicht
sagen: "Beim nächsten Mal haben Sie mehr Glück!". Wenn Sie
das tun, wird ihr nächstes Benutzererlebnis wahrscheinlich
auf jemandes anderen Website stattfinden.
Die Leute verlassen Websites, die ihnen
schaden – sie wissen nicht, dass sie bloss Pech hatten und
es beim nächsten Mal besser treffen würden. Deshalb ist es
Ihre Aufgabe, die dem Pech zugrunde liegenden Ursachen zu bekämpfen
und seine Wurzeln auf Ihrer Site auszurotten.
|
