Drucken
  • Facebook
  • Google+
  • Twitter
  • XING
05.03.2006

Ausreisser und Zufall in der Nutzerleistung

Sechs Prozent der Versuche, Aufgaben zu lösen, verlaufen extrem langsam und führen deshalb bei gemessenen Nutzerleistungen zu Ausreissern. Diese bedauerlichen Vorfälle werden durch Pech verursacht, das die Designer ausrotten könnten - und sollten.

 

by Jakob Nielsen (deutsche Übersetzung) - 06.03.2006

 

Im Allgemeinen plädiere ich für qualitative Nutzertests: Eine Hand voll Nutzer 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 Nutzern 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ährend dem 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 Normal­verteilung.

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 Nutzerstudien

QQ-Plots von zwei Nutzerstudien: 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 Nutzers. Die x-Achse zeigt die gemessene Leistung an, die y-Achse die theoretische Leistung gemäss der Normalverteilung.

(Anmerkung: Weil meine Analyse Nutzer 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 Nutzer, 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 Nutzer (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 Nutzer 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 Nutzererlebnis jener 94% der Nutzer 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 Nutzen 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 Nutzer, die bei einigen Aufgaben extrem langsam waren, bei anderen Aufgaben schnell.

Für die 87 Ausreisserfälle waren 60 verschiedene Nutzer verantwortlich; auf jeden davon kamen also im Schnitt 1,5 Ausreisser. Da die Nutzer quer durch alle analysierten Studien im Schnitt mit 6,7 Aufgaben getestet wurden, hatte jeder dieser Nutzer 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 Nutzer.

Glücksfälle in der Nutzerleistung

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 Nutzer ein schweres Usability-Problem glücklich umschiffen, das anderen Nutzern grosse Schwierigkeiten und viel Frust eingebracht hat.

Hier ein Beispiel für einen Glücksfall aus einem Test mit behinderten Nutzern beim Versuch, die Website der IRS (der amerikanischen Steuerbehörde) zu benutzen. Eine blinde Nutzerin 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 Nutzerin, 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 Nutzerin 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 Nutzers 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 Nutzern von Bildschirm­vorlesern 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 Nutzerleistung

Die meisten Web- und Intranet-Nutzer 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 Nutzer 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 Nutzer oft auf die falsche Site, aber die Nutzer bemerken den Fehler nicht. Der Link oder der Hinweis, die der Nutzer braucht, sind aus dem Bildschirm gerollt und deshalb sieht der Nutzer ihn nicht.
  • Ein Pop-up-Fenster lenkt die Nutzer gerade in dem Moment ab, wo sie dabei waren, den richtigen Weg zu finden.
  • Eine Registrierungspanne führt die Nutzer 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 Nutzer 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 Nutzer unter bestimmten Umständen geradezu ins Unglück zu stürzen. Wenn es nur ein klein bisschen anders gelaufen wäre - sagen wir, ein Nutzer hätte nur eine Zeile weitergescrollt - dann hätte er vielleicht Glück und ein sehr befriedigendes Nutzererlebnis 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 Nutzer 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 Nutzererlebnis 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.

 

© Deutsche Version von Jakob Nielsens Alertbox. Institut für Software-Ergonomie und Usability AG. Alle Rechte vorbehalten.

Kommentare auf diesen Beitrag

    Keine Kommentare

Kommentar hinzufügen

Die mit * gekenzeichneten Felder sind zwingend auszufüllen