Was ist ein Usability-Test, und wie macht man ihn?

Kurz gesagt

Bei einem Usability-Test setzen Sie einen Nutzer vor Ihr Produkt, geben ihm eine Aufgabe und schweigen. Während er versucht, die Aufgabe zu erledigen, beobachten Sie und machen Notizen. Am Ende haben Sie keine Meinungen in der Hand, sondern Beobachtungen.

Laut dem Grundlagenleitfaden von NN/g haben die meisten Tests drei Teile: Moderation, Aufgaben und Teilnehmende. Die Moderation führt die Sitzung und versucht, das Verhalten der Teilnehmenden nicht unbewusst zu beeinflussen. Die Aufgaben sind Dinge, die Teilnehmende im echten Leben tun könnten. Teilnehmende sind realistische Nutzer des Produkts oder Menschen mit ähnlichem Hintergrund wie die Zielgruppe.

Was der Test misst, ist Usability: wie leicht ein Produkt zu lernen und zu benutzen ist. Der Test liest diese Leichtigkeit am Verhalten der Nutzer ab.

Der Unterschied zu heuristischer Evaluation und UX-Audit

Bei der heuristischen Evaluation gibt es keine Nutzer; Fachleute prüfen die Oberfläche nach Grundsätzen. Ein UX-Audit fügt Prüfungen zu Barrierefreiheit und Inhalt hinzu. Der Leitfaden von NN/g zur heuristischen Evaluation schreibt es klar: Diese Methode ersetzt keine Nutzerforschung. Ich nutze beides nacheinander. Das Audit sagt mir, wo ich hinschauen soll, der Test zeigt, ob Nutzer dort wirklich hängen bleiben.

Wann man testet

Die kurze Antwort: solange Designänderungen noch günstig sind. Testen lässt sich ein Papierentwurf, ein klickbarer Prototyp oder das Produkt, das live ist. Laut Nielsen ist auch lautes Denken eine flexible Methode. Sie lässt sich in jeder Phase der Entwicklung und bei den meisten Arten von Oberflächen einsetzen.

Ich empfehle einen Test in diesen Momenten:

• Bevor ein Ablauf programmiert wird, in der Phase des Prototyps. Ein Problem, das hier gefunden wird, ist an einem Nachmittag behoben.
• Kurz vor dem Release, für die zwei, drei wichtigsten Aufgaben.
• Wenn in der Analyse die Abbruchrate eines Schritts steigt. Die Zahlen sagen, wo es abfällt, der Test zeigt, warum.
• Vor einem Redesign, mit dem alten Produkt. Wer das Neue zeichnet, ohne zu wissen, was funktioniert, wirft auch die guten Teile weg.

Ein Test beantwortet nicht jede Frage. „Wollen Nutzer diese Funktion?“ ist eine Frage für Interviews oder Marktforschung. Der Test schaut, ob sich ein vorhandenes Design benutzen lässt. Ob eine Idee für ein MVP Nachfrage findet, sagt er nicht.

Arten von Usability-Tests

Ich unterscheide Tests mit zwei Fragen: Moderiert jemand die Sitzung, und sind Sie mit der Teilnehmerin im selben Raum? Die dritte Unterscheidung liegt im Zweck. Ein Test sucht entweder Probleme oder sammelt Zahlen.

Moderiert und unmoderiert

Beim moderierten Test ist die Moderation die ganze Sitzung über bei der Teilnehmerin. Laut einem Artikel von Amy Schade bei NN/g kann die Moderation nach den Aufgaben mit Nachfragen ins Detail der Probleme gehen. Eine stille Teilnehmerin kann sie auch behutsam dazu bringen, mehr zu erzählen. Nach einer Aufgabe zu fragen „Was haben Sie dort erwartet?“, bringt Informationen, die Sie aus der Aufzeichnung nicht herauslesen können.

Beim unmoderierten Test macht die Teilnehmerin die Studie allein. Die Sitzung wird aufgezeichnet, Sie schauen sie später an. Vorab geschriebene Fragen lassen sich hinzufügen, Nachfragen in Echtzeit gibt es nicht. Schade hält diese Art für passend, wenn sich die Studie auf ein paar bestimmte Elemente konzentriert und die Zeit knapp ist.

Der Preis des unmoderierten Tests ist der Verlust an Kontrolle. Nachfragen werden vorab geschrieben und allen gleich gestellt. Ist der Aufgabentext schlecht, merken Sie es erst nach der Sitzung. Deshalb ist der Aufgabentext bei dieser Art doppelt wichtig.

Remote und vor Ort

Der moderierte Remote-Test ähnelt dem Test vor Ort sehr. Der Unterschied: Moderation und Teilnehmerin sind an verschiedenen Orten. Laut Schade kommuniziert die Moderation per Telefon, E-Mail, Chat oder einer Mischung davon. Laut NN/g kostet ein Remote-Test oft weniger Zeit und Geld als eine Studie vor Ort.

Beim Test vor Ort sehen Sie das Gesicht der Teilnehmerin und ihr Zögern. Auch Schade bevorzugt als allgemeine Regel den Test vor Ort. Sie ergänzt aber, dass ein Remote-Test besser ist als gar kein Test, wenn Budget oder Zeit nicht reichen.

Noch ein praktischer Hinweis für die Arbeit aus der Ferne: Derselbe Artikel empfiehlt, ein paar Personen mehr einzuladen, falls jemand nicht kommt. Auch Schweigen am anderen Ende ist mehrdeutig. Laut Schade kann jemand schweigen, weil er verwirrt ist, abgelenkt ist oder in den Inhalt vertieft.

Qualitativ und quantitativ

Die Unterscheidung von NN/g ist klar. Ein qualitativer Test ist am besten, um Probleme in der Erfahrung zu finden. Ein quantitativer Test sammelt Messwerte, die die Erfahrung beschreiben, etwa Aufgabenerfolg oder Zeit für eine Aufgabe. Er ist am besten für Benchmarks. Diese Seite beschreibt vor allem den qualitativen Test, weil Produktteams ihn am häufigsten brauchen.

Wie man einen Usability-Test macht: Schritt für Schritt

Ich baue einen Test in sieben Schritten auf. Die Reihenfolge ist wichtig: Ohne geschriebenes Ziel keine Aufgabe, ohne geschriebene Aufgabe keine Auswahl der Teilnehmenden.

1. Schreiben Sie das Ziel auf

Schreiben Sie in einem Satz, was Sie aus dem Test lernen wollen. „Können Gastnutzer den Zahlungsschritt ohne Hilfe abschließen?“ ist ein gutes Ziel. „Ist unsere Website nutzerfreundlich?“ lässt sich nicht beantworten.

Neben das Ziel schreibe ich, wer das Ergebnis nutzt und welche Entscheidung es beeinflusst. Gibt es keine Entscheidung, braucht es auch keinen Test.

2. Wählen Sie die Aufgaben

Wählen Sie Aufgaben, die dem Ziel dienen und die Nutzer wirklich erledigen. Mehr als ein paar Aufgaben kommen bei mir nicht in eine Sitzung. Wer müde wird, verliert bei den letzten Aufgaben die Aufmerksamkeit.

Schreiben Sie für jede Aufgabe ein Erfolgskriterium. Ein klarer Endpunkt wie „Die Teilnehmerin hat den Zahlungsscreen erreicht“ verhindert Diskussionen in der Analyse. Dieses Kriterium sagen Sie der Teilnehmerin nicht, nur Sie kennen es.

3. Finden Sie Teilnehmende

Teilnehmende sind echte Nutzer des Produkts oder Menschen mit denselben Bedürfnissen. Eine Banking-App von einer Kollegin aus dem Designteam testen zu lassen, sagt fast nichts.

Teilnehmende bekommen für ihre Zeit eine Aufwandsentschädigung. Laut dem Grundlagenleitfaden von NN/g kosten diese Zahlungen bei einer einfachen Studie zusammen meist ein paar hundert Dollar. Ich bevorzuge etwas, das die Teilnehmenden wirklich nutzen, etwa einen Gutschein.

Spricht Ihr Produkt sehr verschiedene Gruppen an, nehmen Sie aus jeder Gruppe eigene Teilnehmende. Wie viele es braucht, beschreibe ich unten eigens.

4. Schreiben Sie das Szenario

Das Szenario setzt die Aufgabe in eine Geschichte: Warum tut die Teilnehmerin das? Der Artikel von Marieke McCloskey bei NN/g gibt drei Tipps. Die Aufgabe ist realistisch, lässt die Teilnehmerin etwas tun und enthält weder Hinweise noch Schrittbeschreibungen. Der Artikel sagt außerdem, dass das Szenario Kontext geben soll.

Die nützlichste Warnung im Artikel: Nutzen Sie in der Aufgabe keine Wörter, die in der Oberfläche vorkommen. Statt „Melden Sie sich für den Newsletter an“ heißt es „Sorgen Sie dafür, dass Neuigkeiten zu Veranstaltungen regelmäßig in Ihr Postfach kommen“. Der Generator unten zeigt diesen Unterschied je nach Art des Produkts.

Probieren Sie die Aufgaben vor der ersten echten Teilnehmerin mit einer Kollegin aus. Ein unverständlicher Satz kann fünf Sitzungen auf einmal verschwenden.

5. Bitten Sie um lautes Denken

Sie bitten die Teilnehmerin, beim Erledigen laut zu sagen, was ihr durch den Kopf geht. Nielsen nennt lautes Denken in seinem Artikel von 2012 die vielleicht wertvollste einzelne Methode des Usability Engineering. Er reduziert die Methode auf drei Schritte: repräsentative Nutzer finden, ihnen repräsentative Aufgaben geben und schweigen.

Das Schweigen ist der schwerste Teil. Das ist auch eine der Schwächen, die Nielsen nennt: Greift eine ungeschulte Moderation ein, kann sie das Verhalten der Nutzerin leicht verändern. Bleibt die Teilnehmerin hängen, frage ich „Was versuchen Sie gerade zu tun?“, nicht „Haben Sie oben rechts geschaut?“.

Wissen Sie auch: Die Situation ist nicht natürlich. Laut Nielsen fällt es vielen schwer, ununterbrochen zu sprechen, und manche filtern, was sie sagen wollen. Eine kurze Erinnerung an eine stille Teilnehmerin reicht.

Ich führe die Sitzung jedes Mal in derselben Reihenfolge. Zuerst sage ich der Teilnehmerin, dass nicht sie getestet wird, sondern das Produkt. Ich füge hinzu, dass es keine falsche Antwort gibt und jede Stelle, an der sie hängen bleibt, uns hilft.

Dann höre ich mit ein paar Fragen zum Aufwärmen zu, wie sie das Produkt nutzt. Die Aufgaben gebe ich einzeln und schriftlich. Am Schluss frage ich nach ihrem Gesamteindruck und ob ihr noch etwas einfällt. Die Meinung ans Ende zu stellen, stört das Verhalten während der Aufgaben nicht.

6. Machen Sie Notizen

Notieren heißt aufschreiben, was Sie sehen, nicht, was Sie denken. „Hat den Preisfilter nicht gefunden, dreimal nach oben gescrollt“ ist eine Beobachtung. „Der Filter ist schlecht gestaltet“ ist eine Deutung und gehört in die Analyse.

Für jede Aufgabe fülle ich dieselben Zeilen aus: erfolgreich oder nicht, wo gezögert, was gesagt. Wenn möglich, zeichne ich die Sitzung auf, und jemand aus dem Team notiert getrennt. Wer moderiert und gleichzeitig schreibt, verpasst etwas.

7. Werten Sie aus

Wenn die Sitzungen vorbei sind, machen Sie aus den Notizen Probleme. Fassen Sie Teilnehmende, die an derselben Stelle hängen blieben, unter einem Problem zusammen und schreiben Sie dazu, wie viele es waren. Auch das Problem einer einzelnen Teilnehmerin kommt auf die Liste, aber mit dieser Angabe.

Ordnen Sie dann jedes Problem nach seinem Schweregrad. Ich nutze hier dieselbe Skala von 0 bis 4 wie im UX-Audit. Der Bericht ist kurz: die wichtigsten Probleme, für jedes ein Videoausschnitt als Beleg und ein konkreter Vorschlag zur Korrektur.

Wie viele Teilnehmende man braucht

Für einen qualitativen Test, der Probleme finden soll, reichen meist fünf Teilnehmende. Diese Zahl stammt aus Jakob Nielsens Artikel „Why You Only Need to Test with 5 Users“ von 2000. Die eigentliche Empfehlung des Artikels ist aber nicht, sich mit fünf zu begnügen, sondern kleine Tests zu wiederholen.

Nielsen stützt die Zahl auf ein Modell, das er 1993 mit Thomas Landauer auf der Konferenz INTERCHI veröffentlicht hat. Nach dem Modell berechnet sich die Zahl der mit n Nutzern gefundenen Probleme als N(1 − (1 − L)ⁿ). N ist die Gesamtzahl der Probleme im Design, L der Anteil, den ein einzelner Nutzer findet.

In den Projekten, die Nielsen untersucht hat, lag L im Schnitt bei 31 %. Ein einzelner Nutzer zeigt also fast ein Drittel der Probleme. Eine erste Studie mit fünf Teilnehmenden findet etwa 85 % der Probleme. Laut dem Artikel sehen Sie mit jedem weiteren Nutzer immer wieder dieselben Dinge und lernen immer weniger.

• 1 Person31 %
• 2 Pers.52 %
• 3 Pers.67 %
• 4 Pers.77 %
• 5 Pers.84 %
• 6 Pers.89 %
• 8 Pers.95 %
• 10 Pers.98 %
• 15 Pers.99,6 %

Abbildung: Anteile nach Nielsens Formel mit L = 31 %. Die Werte sind gerundet.

Die Formel ergibt für fünf Personen 84,4 %, der Artikel rundet das auf etwa 85 %. Achten Sie darauf, wie die Kurve nach fünf flacher wird. Die fünfzehnte Person zeigt fast kein neues Problem.

Nielsen folgert daraus: Um alle Probleme zu finden, braucht es mindestens 15 Nutzer, aber geben Sie dieses Budget nicht in einem Test aus. Machen Sie drei Tests mit je fünf Personen. Korrigieren Sie nach dem ersten Test das Design. Der zweite Test prüft die Korrekturen und findet die meisten Probleme, die die erste Runde übersehen hat. Der dritte braucht es für tiefe Probleme, die erst sichtbar werden, wenn die Probleme an der Oberfläche beseitigt sind.

Die Grenzen der Zahl fünf stehen im selben Artikel:

• Bestehen Ihre Nutzer aus sehr verschiedenen Gruppen, etwa Käufer und Verkäufer, nehmen Sie aus jeder Gruppe eigene Teilnehmende. Nielsen empfiehlt für zwei Gruppen 3 bis 4 pro Gruppe, für drei und mehr Gruppen 3 pro Gruppe.
• Für quantitative Studien, also wenn Sie Zahlen sammeln, verweist der Artikel auf eine spätere Empfehlung von NN/g: 20 Nutzer.
• Für Card Sorting nennt derselbe Artikel 15 Nutzer.

Auch der Grundlagenleitfaden von NN/g von 2019 liegt auf dieser Linie: Eine typische qualitative Studie wird mit fünf Teilnehmenden gemacht.

Generator für Aufgaben und Szenarien

Die Qualität eines Tests bestimmt vor allem der Aufgabentext. Dasselbe Ziel zeigt, gut geschrieben, das echte Verhalten des Nutzers. Schlecht geschrieben, flüstert es der Teilnehmerin die Antwort zu.

Aufgaben und Szenarien bauen

Onlineshop · Kauf oder Zahlung

Gut Aufgabe, die der Teilnehmerin vorgelesen wird

Ihre Tochter hat nächste Woche Geburtstag. Sie wollen ihr Kopfhörer kaufen, die Ihr Budget nicht sprengen. Das Geschenk soll vor Samstag da sein. Finden Sie ein passendes Produkt und gehen Sie bis zum Zahlungsschritt.

Erfolgskriterium (nur Ihre Notiz): Ein Produkt, das zu Budget und Liefertermin passt, liegt im Warenkorb, die Teilnehmerin ist auf dem Zahlungsscreen.

• Realistisch Eine Aufgabe, die im Leben der Teilnehmerin vorkommen kann.
• Lässt tun Lässt nicht erzählen, sondern die Aufgabe auf dem Screen erledigen.
• Kein Hinweis Kein Menüname und kein Buttontext.

Schlecht Dasselbe Ziel, schlecht geschrieben

Tippen Sie „Kopfhörer“ in die Suchleiste und drücken Sie „In den Warenkorb“. Sagen Sie dann, ob Ihnen die Zahlungsseite gefällt.

• Nennt die Schritte Wird der Weg beschrieben, kann der Test nicht messen, ob die Oberfläche den Weg zeigt.
• Nennt das Label der Oberfläche Die Teilnehmerin erfährt das gesuchte Wort aus der Aufgabe. Dieses Wort auf dem Screen zu finden, ist leichter, als die Aufgabe zu verstehen.
• Fragt nach Meinung Eine Frage nach Gefallen zeigt kein Verhalten. Sie wollen sehen, wo die Teilnehmerin beim Erledigen hängen bleibt.

Wählen Sie die Art des Produkts und das Ziel des Nutzers. Die linke Karte zeigt einen guten Aufgabentext, der der Teilnehmerin vorgelesen wird, die rechte dasselbe Ziel schlecht geschrieben und warum es schlecht ist. Die Aufgaben sind meine Beispiele, nicht aus einem echten Kundenauftrag.

Die meisten schlechten Beispiele gehen an derselben Stelle kaputt: Wer die Aufgabe schreibt, kennt den Screen auswendig. Sehen Sie in Ihrer Aufgabe einen Menünamen oder einen Buttontext, ersetzen Sie ihn durch das Wort, das der Nutzer selbst benutzen würde.

Häufige Fehler

Wörter der Oberfläche in der Aufgabe. Die Teilnehmerin liest die Aufgabe, sucht auf dem Screen dasselbe Wort und findet es. Der Test wirkt erfolgreich, hat aber nichts gemessen.

Erzählen lassen statt tun lassen. McCloskey empfiehlt, die Teilnehmerin die Aufgabe erledigen zu lassen, statt sie erzählen zu lassen, wie sie es tun würde. Die eigene Schilderung ist ungenauer und verdeckt, wie leicht oder frustrierend die Oberfläche ist.

Teilnehmende aus dem eigenen Team. Wer das Produkt kennt, sieht die Probleme nicht. Teilnehmende sollen echten Nutzern ähneln.

Der Teilnehmerin helfen. Eine Teilnehmerin zu retten, die hängt, ist ein natürlicher Reflex. Aber in dem Moment, in dem Sie helfen, sind die Daten dieser Aufgabe verloren. Fragen Sie zuerst: „Was haben Sie hier erwartet?“

Ein einziger großer Test. Ein Test mit zwanzig Personen heißt, dasselbe Problem zwanzigmal zu sehen. Nielsens Empfehlung ist, kleine Tests mit je fünf Personen zu wiederholen.

Beobachtung und Deutung vermischen. Schreiben Sie statt „war verwirrt“ auf, was sie getan hat. Gedeutet wird in der Analyse, mit Blick auf mehrere Sitzungen.

Ergebnisse in einem Bericht begraben. Ein langer Bericht, den niemand liest, verschwendet den Test. Eine kurze Liste der Probleme und ein paar Videoausschnitte bringen das Team schneller in Bewegung.

Ein mobiles Produkt am Desktop testen. Kommen Ihre Nutzer vom Handy, wird auch auf dem Handy getestet. Wo der Daumen hinkommt, bringt Probleme ans Licht, die am Desktop gar nicht zu sehen sind.

Meine Notiz

Der Schritt, mit dem sich Teams am schwersten tun, ist nicht das Schreiben der Aufgaben, sondern das Schweigen in der Sitzung. Bleibt der Nutzer hängen, will man ihm als Erstes den Weg zeigen. In diesen Momenten zähle ich innerlich bis fünf und frage dann nur, was er erwartet hat.

Meine zweite Beobachtung: Der wertvollste Ertrag des ersten Tests sind oft die Fehler in den Aufgabentexten. Lassen Sie deshalb die Pilotsitzung nicht aus. Eine halbe Stunde zur Probe mit einer Kollegin rettet die echten Sitzungen.

Reicht Ihr Budget nicht für einen Test, bestimmen Sie zuerst mit einem Audit den riskantesten Ablauf. Geben Sie das Testbudget für diesen Ablauf aus. Für einen Blick über das ganze Produkt gibt es den UX Audit Pro.