Usability-Tests haben zu Unrecht den Ruf, teuer und langsam zu sein. Wer „User Research“ hört, denkt an einen Einwegspiegel, einen Moderator mit Klemmbrett und einen Zeitplan von zwei Wochen. Diese Art des Testens gibt es, und sie hat ihre Berechtigung – aber sie ist nicht die Variante, die die meisten Produktteams die meiste Zeit brauchen.
Die Variante, die die meisten Teams brauchen, ist einfacher: fünf Nutzer, ein Figma-Prototyp oder eine Staging-Umgebung, ein Videocall und 45 Minuten pro Session. Gut gemacht, deckt das die Mehrzahl der gravierenden Usability-Probleme vor dem Release auf. Konsequent durchgeführt – und sei es nur einmal pro Sprint –, führt es zu einer kumulativen Verbesserung der Produktqualität, die keine Analytics nach dem Launch ersetzen kann.
So gehen Sie von Grund auf vor.
Fünf Teilnehmende sind für die meisten Usability-Tests die richtige Zahl. Jakob Nielsens Forschung hat gezeigt, dass fünf Nutzer rund 85 % der Usability-Probleme aufdecken, danach nehmen die Erträge ab. Drei Durchläufe mit je fünf Nutzern an verschiedenen Punkten des Designprozesses sind wertvoller als ein Durchlauf mit fünfzehn.
Die Rekrutierungskriterien sind wichtiger als die Anzahl. Ein Usability-Test mit fünf Personen, die Ihrer Zielgruppe genau entsprechen, deckt echte Probleme auf. Ein Test mit fünfzehn Personen, die nicht passen, erzeugt nur Rauschen. Legen Sie zwei oder drei Screening-Kriterien fest – Rolle, Nutzungskontext, technische Erfahrung – und halten Sie sich daran.
Der schnellste Rekrutierungsweg ist für die meisten Teams, bestehende Nutzer anzuschreiben, die der Kontaktaufnahme zugestimmt haben. Bieten Sie einen bescheidenen Anreiz – ein 20-£-Gutschein genügt für eine 45-minütige Session. Planen Sie die Sessions möglichst innerhalb derselben Woche; je größer der Abstand zwischen Rekrutierung und Test, desto höher die Ausfallquote.
Der häufigste Fehler beim Leitfaden: Aufgaben werden als Anweisungen formuliert – „Klicken Sie auf Einstellungen, navigieren Sie zu Benachrichtigungen und ändern Sie Ihre Einstellung auf …“. Das sagt dem Nutzer, was er tun soll – Sie testen also, ob er Anweisungen befolgen kann, nicht, ob die Oberfläche intuitiv ist.
Formulieren Sie Aufgaben stattdessen als Szenarien: „Stellen Sie sich vor, Sie erhalten zu viele Benachrichtigungen und möchten nur noch Hinweise bekommen, wenn Sie jemand direkt erwähnt. Zeigen Sie mir, was Sie tun würden.“ Das gibt dem Nutzer ein realistisches Ziel und lässt Sie beobachten, wie er tatsächlich navigiert – einschließlich der Stellen, an denen er sich verirrt.
Das Schwierigste beim Moderieren eines Usability-Tests ist, dem Impuls zum Helfen zu widerstehen. Ist ein Nutzer verwirrt, rät jeder Instinkt dazu, einzugreifen und zu zeigen, wo er klicken muss. Aber gerade die Verwirrung liefert die Daten. Ein Nutzer, der Mühe hat, sagt Ihnen, dass an der Oberfläche etwas nicht stimmt – und sobald Sie eingreifen, verlieren Sie das Signal.
Bitten Sie die Nutzer, während der gesamten Session laut zu denken: „Sagen Sie mir einfach beim Vorgehen, was Sie sehen und was Sie denken.“ So entsteht ein kontinuierlicher Datenstrom über ihr mentales Modell. Notieren Sie nicht nur Fehler, sondern auch Zögern – ein Nutzer, der drei Sekunden innehält, bevor er auf den richtigen Button klickt, hat ein Designproblem offenbart, auch wenn er am Ende erfolgreich war.
In der Auswertung entsteht der größte Teil des Werts – und genau hier schneiden die meisten Teams Ecken ab. Rohnotizen aus fünf Sessions sind noch keine Erkenntnisse. Sie werden es, wenn Sie als Team nachbesprechen, Beobachtungen nach Themen bündeln und Schweregrade vergeben.
Führen Sie die Nachbesprechung am Tag der Sessions durch, solange die Beobachtungen frisch sind. Ordnen Sie Probleme drei Kategorien zu: kritisch (Nutzer konnten die Aufgabe nicht abschließen), mittel (Nutzer schlossen die Aufgabe ab, aber mit erheblicher Mühe oder Fehlern) und gering (Reibung, die den Abschluss nicht verhindert hat). Kritische Probleme müssen vor dem Launch behoben werden. Mittlere Probleme sollten im nächsten Sprint priorisiert werden. Geringe landen im Backlog.
Fassen Sie die Ergebnisse auf einer einzigen Seite zusammen: die drei wichtigsten kritischen Probleme, jeweils mit Belegen von mindestens zwei Teilnehmenden, und ein Vorschlag für die Designänderung. Alles, was mehr Platz braucht, gehört in ein separates Dokument.