Etwa neunzig Sekunden nach Beginn eines Usability-Tests entsteht oft eine ganz bestimmte Stille. Die Teilnehmerin bewegt die Maus nicht mehr. Sie schaut auf einen Screen, den Ihr Team entworfen, geprüft und ausgeliefert hat, und weiß nicht, was sie als Nächstes tun soll.
Niemand im Produktteam hätte diese Pause vorhersagen können, denn alle im Produktteam wissen längst, wo der Button ist. Genau darin liegt der ganze Wert des Usability-Tests: Er ist die einzige Forschungsmethode, die Ihnen zuverlässig die Teile Ihres Produkts zeigt, die für die Menschen, die es gebaut haben, unsichtbar sind.
Dieser Leitfaden erklärt, was ein Usability-Test ist, welche sechs Methoden es gibt und wann sich welche lohnt, welche Metriken etwas aussagen, wie viele Teilnehmende Sie wirklich brauchen, einen Prozess in sieben Schritten, den Sie noch diese Woche umsetzen können, und ein kopierfertiges Skript für den Flow, in dem Usability-Probleme am teuersten sind: das Onboarding.
Das Wichtigste in Kürze
- Verhalten beobachten, keine Meinungen sammeln. Ein Usability-Test bedeutet, jemandem eine realistische Aufgabe zu geben und zu beobachten, was passiert. Sobald Sie fragen „Gefällt Ihnen das?“, testen Sie keine Usability mehr.
- Fünf Teilnehmende pro Gruppe finden die meisten Probleme. Fünf ist die richtige Zahl für qualitative Tests, die Probleme aufdecken sollen. Es ist die falsche Zahl, wenn Sie einen Prozentwert berichten wollen.
- Die Erfolgsquote ist die zentrale Metrik. Können die Leute die Aufgabe ohne Hilfe erledigen? Alles andere (Bearbeitungszeit, Fehler, Einfachheitswerte) erklärt diese Zahl, statt sie zu ersetzen.
- Moderiert findet das „Warum“, unmoderiert das „Wie viele“. Nutzen Sie moderierte Sessions für frühe, komplexe oder mehrdeutige Flows und unmoderierte für klar definierte Aufgaben, die Sie in großer Zahl testen wollen.
- Usability-Tests und A/B-Tests folgen aufeinander, sie konkurrieren nicht. Testen Sie, um die Ursache zu finden und die Lösung zu entwerfen, und prüfen Sie die Lösung dann per A/B-Test im großen Maßstab.
- Das Onboarding ist der wertvollste Flow für einen Test. Es ist der einzige Teil Ihres Produkts, den wirklich jeder Nutzer erlebt, genau einmal und ohne angesammeltes Wissen, auf das er zurückgreifen kann.
Was ist ein Usability-Test?
Definition Usability-Test: eine Forschungsmethode, bei der repräsentative Nutzer realistische Aufgaben in einem Produkt ausführen, während ein Beobachter festhält, wo sie Erfolg haben, zögern oder scheitern. Ziel ist zu messen, wie leicht sich eine bestimmte Aufgabe tatsächlich erledigen lässt, nicht Meinungen zum Design einzusammeln.
Diese Unterscheidung ist wichtiger, als sie klingt. Fragen Sie jemanden, was er von einem Screen hält, und er wird höflich, hilfsbereit und fast vollständig falsch antworten, nicht weil er lügt, sondern weil Menschen schlechte Zeugen ihrer eigenen Verwirrung sind. Bitten Sie dieselbe Person, auf diesem Screen eine Aufgabe zu erledigen, und schauen Sie zu: Innerhalb einer Minute haben Sie Dinge beobachtet, die sie selbst nie hätte in Worte fassen können.
Wofür sich Usability-Tests eignen
- Die genaue Stelle des Scheiterns finden. Analysen zeigen Ihnen, dass 40 % der Nutzer bei Schritt drei abspringen. Ein Usability-Test zeigt Ihnen, dass es daran liegt, dass primärer und sekundärer Button identisch aussehen.
- Begriffsprobleme aufdecken. Interne Begriffe sickern ständig in Oberflächen durch, und Nutzer umgehen Wörter, die sie nicht verstehen, statt nachzufragen.
- Testen, bevor Sie bauen. Einen klickbaren Prototyp können Sie an einem Nachmittag testen. Eine ausgelieferte Funktion kostet ein Quartal.
- Interne Diskussionen günstig beenden. Drei Aufzeichnungen echter Menschen, die an etwas scheitern, beenden eine Debatte schneller als jede Menge Meinungen.
Wofür sich Usability-Tests nicht eignen
- Herausfinden, ob Menschen das Produkt wollen. Das ist eine Frage der Begehrlichkeit und des Markts und liegt näher an Jobs-to-be-Done-Research als an Usability.
- Statistisch belastbare Zahlen aus kleinen Stichproben liefern. „Vier von fünf Teilnehmenden sind gescheitert“ ist ein Signal, keine Messung.
- Langfristiges Verhalten vorhersagen. Eine in einer Session erledigte Aufgabe sagt nichts darüber aus, ob jemand nächste Woche wiederkommt.
- Analysen ersetzen. Tests erklären Verhalten, das Sie bereits erkannt haben. Um Verhalten überhaupt erst zu erkennen, sind sie ein schlechtes Werkzeug.
Usability-Test vs. UX-Research vs. A/B-Test
Diese drei Begriffe werden in Planungsmeetings austauschbar verwendet, beantworten aber wirklich unterschiedliche Fragen. Wer den falschen wählt, landet bei einer schönen Research-Präsentation, die nichts verändert, oder bei einem A/B-Test, der beweist, dass Version B schlechter ist, ohne je zu erklären, warum.
| Methode | Beantwortete Frage | Stichprobengröße | Ergebnis |
|---|---|---|---|
| Usability-Test | Können Menschen diese Aufgabe erledigen, und wo genau haben sie Schwierigkeiten? | 5–8 pro Gruppe | Beobachtete Fehlerstellen, Zitate, eine priorisierte Liste von Korrekturen |
| User- bzw. UX-Research (Interviews, Feldstudien) | Was wollen Menschen eigentlich erreichen, und in welchem Kontext? | 8–15 | Jobs, Bedürfnisse, mentale Modelle, Segmentdefinitionen |
| A/B-Test | Welche von zwei Versionen schneidet bei einer Metrik besser ab? | Hunderte bis Tausende | Ein statistisch vergleichbarer Gewinner, ohne Erklärung |
| Produktanalysen | Wo springen Nutzer im großen Maßstab ab? | Alle Nutzer | Funnels, Abbruchraten, Verhalten von Kohorten |
Die Reihenfolge, die funktioniert: Analysen zeigen, wo Nutzer abspringen → der Usability-Test erklärt, warum → Sie entwerfen eine Lösung → ein A/B-Test beweist, dass die Lösung im großen Maßstab wirkt. Wer den mittleren Schritt überspringt, erklärt, warum so viele Experimente ergebnislos bleiben: Ohne Diagnose ist Version B nur eine Vermutung im Laborkittel.
Die 6 Methoden des Usability-Tests
Jeder Usability-Test liegt irgendwo auf zwei Achsen: ob ein Researcher anwesend ist und ob Sie Dinge zählen oder erklären. Aus diesen zwei Entscheidungen ergeben sich die sechs praktischen Formate unten.
1. Moderierter Remote-Test
Researcher und Teilnehmerin teilen per Video einen Bildschirm. Die Teilnehmerin arbeitet die Aufgaben ab und denkt dabei laut; der Researcher bleibt still und fragt nur nach, wenn etwas Interessantes passiert. Für die meisten SaaS-Teams ist das die Standardmethode: Sie bietet die Tiefe eines Tests vor Ort ohne Anreise, und die Aufzeichnungen lassen sich mühelos mit dem restlichen Team teilen.
Kosten: mittel. Dauer: ein paar Tage. Ideal für: alles, bei dem Sie unsicher sind.
2. Unmoderierter Remote-Test
Die Teilnehmenden erhalten Aufgaben und erledigen sie allein, während Bildschirm und Stimme aufgezeichnet werden. Sie bekommen zehn Sessions über Nacht statt fünf in einer Woche, verlieren aber die Möglichkeit, genau in dem Moment, auf den es ankam, zu fragen: „Was hatten Sie an dieser Stelle erwartet?“
Unmoderierte Tests funktionieren gut, wenn die Aufgabe eindeutig ist und das Produkt tatsächlich funktioniert. Bei groben Prototypen funktionieren sie schlecht, denn dort sind die Teilnehmenden die ganze Session über eher vom Test verwirrt als vom Design.
3. Moderierter Test vor Ort
Immer noch die Option mit der höchsten Genauigkeit, weil Sie Körperhaltung, Zögern und die kleinen körperlichen Signale sehen, die einen Videocall nie überstehen. Die Kosten sind real, daher reservieren die meisten Teams diese Methode für Flows mit viel Gewicht (eine Preisänderung, ein Checkout, die Neugestaltung eines zentralen Workflows) oder für Teilnehmende, die anders kaum zu erreichen sind.
4. Guerilla-Test
Fünf Minuten, eine Aufgabe, wer gerade bereit ist. Die Stichprobe ist nicht repräsentativ, und dazu sollten Sie ehrlich stehen. Lautet Ihre Frage aber „Versteht überhaupt jemand, was dieser Button macht?“, beantwortet ein Guerilla-Test sie heute statt in drei Wochen, und ein klares Scheitern ist aufschlussreich, ganz gleich, wer die Person war.
5. First-Click- und Tree-Test
Enge, quantitative Methoden, die auf die Navigation zielen. Der First-Click-Test fragt, wohin jemand klicken würde, um ein Ziel zu erreichen; der Tree-Test bittet die Teilnehmenden, einen Eintrag in einer abgespeckten Version Ihrer Informationsarchitektur ganz ohne visuelles Design zu finden. Beide skalieren auf Hunderte Teilnehmende, beide sind günstig, und beide sind ungewöhnlich gut darin zu beweisen, dass eine Menübezeichnung, über die nie jemand gestritten hat, still und leise scheitert.
6. Benchmark-Test
Dieselben Aufgaben, dasselbe Skript, alle paar Monate an denselben Metriken gemessen. Einzelne Runden sind weniger interessant als der Trend: Eine Erfolgsquote, die über drei Releases von 78 % auf 61 % sinkt, sagt Ihnen, dass angesammelte Funktionen einen zentralen Flow erschwert haben. Genau das ist der Mechanismus hinter den meisten Fällen von Feature Bloat.
Usability-Metriken, auf die es ankommt
Kleine qualitative Studien liefern Beobachtungen, keine Statistik. Erfassen Sie die Zahlen trotzdem; sie disziplinieren die Auswertung und machen den Vergleich von Runde zu Runde möglich, aber seien Sie ehrlich, welche davon bei n=5 Gewicht haben.
| Metrik | Was sie misst | Wie man sie liest |
|---|---|---|
| Erfolgsquote (Task Success Rate) | Anteil der Teilnehmenden, die die Aufgabe ohne Hilfe abschließen | Die zentrale Zahl. Alles unter etwa 78 % bei einer Kernaufgabe verdient sofortige Aufmerksamkeit |
| Bearbeitungszeit (Time on Task) | Wie lange die Erledigung dauert | Nützlich im Vergleich mit sich selbst über die Zeit oder mit einer realistischen Erwartung, nicht mit einem willkürlichen Zielwert |
| Fehlerrate | Falsche Klicks, falsche Wege, falsche Eingaben pro Aufgabe | Häufungen desselben Fehlers deuten auf einen behebbaren Designfehler hin, nicht auf unaufmerksame Nutzer |
| Hilfestellungen | Wie oft die Moderation eingreifen musste | Eine Hilfestellung ist ein Scheitern mit höflichem Namen. Zählen Sie sie ehrlich |
| Single Ease Question (SEQ) | Eine Bewertung von 1–7, direkt nach jeder Aufgabe abgefragt | Eine Frage, gestellt, solange das Erlebnis frisch ist. Die günstigste nützliche subjektive Metrik, die es gibt |
| System Usability Scale (SUS) | Ein Fragebogen mit 10 Fragen am Ende der Session, Wertung 0–100 | Etwa 68 ist der Durchschnitt. Aussagekräftig vor allem als Trend über Runden oder im Vergleich mit Ihrem eigenen früheren Wert |
| Abbruchpunkt | Der konkrete Schritt, an dem die Teilnehmenden aufhören | Das am besten umsetzbare Ergebnis der ganzen Session, und das, das sich direkt auf Ihren Funnel übertragen lässt |
Berichten Sie keine Prozentwerte von fünf Personen. „60 % der Nutzer sind gescheitert“ heißt bei einer Stichprobe von fünf: drei Personen, und das Konfidenzintervall um diese Zahl ist riesig. Sagen Sie lieber: „Drei von fünf Teilnehmenden sind am selben Schritt gescheitert, alle aus demselben Grund.“ Das ist ehrlicher und in der Praxis deutlich überzeugender.
Wie viele Teilnehmende brauchen Sie?
Das ist die meistdiskutierte Frage beim Usability-Test, und sie hat eine langweilige Antwort: Es hängt ganz davon ab, ob Sie Probleme finden oder messen wollen.
✅ Fünf passen, wenn…
- Sie Usability-Probleme finden wollen, nicht zählen
- die Teilnehmenden zu einer einigermaßen homogenen Gruppe gehören
- Sie beheben wollen, was Sie finden, und dann erneut testen
- Sie einen Prototyp oder einen einzelnen Flow testen
❌ Fünf passen nicht, wenn…
- Sie eine Zahl brauchen, die Sie berichten oder vergleichen wollen
- Sie wirklich unterschiedliche Segmente bedienen (dann fünf pro Segment)
- Sie ein Benchmarking von Release zu Release machen
- die Entscheidung teuer und nicht umkehrbar ist
Die Regel der „fünf Nutzer“ stammt aus Jakob Nielsens Beobachtung, dass etwa fünf Teilnehmende rund 85 % der Usability-Probleme in einem Flow aufdecken, weil Probleme nicht gleichmäßig verteilt sind: Die schwerwiegenden treffen fast alle. Diese Logik gilt für das Finden von Problemen und bricht beim Messen komplett zusammen; dort wollen Sie in der Regel 20 oder mehr pro Gruppe.
Die nützlichere Sichtweise: mehr Runden statt größerer Runden. Drei Runden mit je fünf Teilnehmenden und Korrekturen dazwischen verbessern ein Produkt weit mehr als eine Runde mit fünfzehn, weil die Runden zwei und drei etwas Besseres testen als Runde eins.
Einen Usability-Test in 7 Schritten durchführen
Eine Frage festlegen, die der Test beantworten muss
Realistische, ergebnisorientierte Aufgaben formulieren
Die richtigen Teilnehmenden rekrutieren
Skript und Umgebung vorbereiten
Die Session durchführen und still bleiben
Nach Mustern auswerten, nicht nach Anekdoten
Beheben, ausliefern und erneut testen
1. Eine Frage festlegen, die der Test beantworten muss
„Lass uns das neue Dashboard testen“ ist keine Forschungsfrage. „Kann ein neuer Nutzer ohne Hilfe einen Bericht erstellen und teilen?“ ist eine. Eine einzige präzise Frage bestimmt Ihre Aufgaben, Ihre Teilnehmenden und das, was als Ergebnis zählt, und sie verhindert, dass die Session in ein allgemeines Gespräch über Produktfeedback abdriftet.
Die beste Quelle für solche Fragen ist Ihr eigener Funnel. Überall, wo Onboarding-Analysen einen unerklärten Abbruch zeigen, haben Sie eine Frage, die fünf Sessions wert ist.
2. Realistische, ergebnisorientierte Aufgaben formulieren
Eine Aufgabe sollte ein Ziel und einen Kontext beschreiben und darf keine Anleitung zu ihrer Lösung enthalten. Der häufigste Weg, einen Usability-Test zu ruinieren, ist, den Button in der Aufgabe zu nennen.
✅ Gute Aufgabenformulierung
- „Ihre Vorgesetzte möchte die Zahlen vom letzten Monat vor Freitag haben. Schicken Sie ihr einen Bericht, den sie öffnen kann.“
- „Sie sind gerade diesem Team beigetreten. Finden Sie heraus, woran Sie als Erstes arbeiten sollen.“
- „Eine Kollegin soll das prüfen, bevor es rausgeht. Sorgen Sie dafür, dass das passiert.“
❌ Formulierungen, die die Antwort verraten
- „Klicken Sie auf Berichte, wählen Sie dann Exportieren und anschließend PDF.“
- „Nutzen Sie die Teilen-Funktion, um das Dokument zu teilen.“
- „Finden Sie die neue Navigation intuitiv?“
3. Die richtigen Teilnehmenden rekrutieren
Repräsentativ schlägt bequem. Wenn Sie ein Erlebnis beim ersten Start testen, ist das einzige Ausschlusskriterium die Vertrautheit mit Ihrem Produkt. Das schließt Ihre Kolleginnen und Kollegen, Ihre Investoren und alle bestehenden Kunden aus.
Quellen, die funktionieren: kürzlich registrierte Nutzer, die sich noch kein zweites Mal angemeldet haben, Nutzer aus einer abgewanderten Kohorte, ein Rekrutierungspanel oder eine gezielte In-App-Umfrage, die Nutzern mit einem bestimmten Verhalten eine Belohnung anbietet. Wählen Sie nach dem Verhalten aus, auf das es ankommt, nicht nach der Jobbezeichnung.
4. Skript und Umgebung vorbereiten
Schreiben Sie das Skript auf, einschließlich der Einleitung, und lesen Sie jedes Mal dieselbe Einleitung vor. Zwei Dinge gehören hinein und werden regelmäßig vergessen: der ausdrückliche Hinweis, dass Sie das Produkt testen und nicht die Person, und die Erlaubnis zur Aufzeichnung.
Prüfen Sie dann die Umgebung. Ein Testkonto voller ordentlicher Demodaten verdeckt jedes Empty-State-Problem, das Sie haben; ein wirklich leeres Konto bildet das echte Erlebnis beim ersten Start nach. Entscheiden Sie bewusst, was von beidem Sie testen.
5. Die Session durchführen und still bleiben
Schweigen ist das wichtigste Werkzeug der Moderation und der schwierigste Teil der Aufgabe. Wenn jemand zögert, ist der Drang zu helfen überwältigend, und Helfen zerstört genau die Daten, wegen derer Sie gekommen sind. Warten Sie. Zählen Sie bis zehn. Meistens lösen die Teilnehmenden es selbst, und Sie lernen genau, wie.
Drei Sätze decken fast jede Situation ab:
- „Was denken Sie gerade?“: bei Schweigen
- „Was würden Sie erwarten, wenn Sie darauf klicken?“: bei Zögern
- „Was würden Sie tun, wenn ich nicht hier wäre?“: bei einer direkten Bitte um Hilfe
6. Nach Mustern auswerten, nicht nach Anekdoten
Listen Sie nach den Sessions jedes beobachtete Problem mit der Nummer der Teilnehmerin und dem Schritt auf, an dem es auftrat. Gruppieren Sie die Probleme dann. Ein Problem, das einmal auftrat, ist eine Notiz; ein Problem, das in vier von fünf Sessions am selben Schritt auftrat, ist ein Defekt mit einem Platz in der Warteschlange.
Ordnen Sie die Gruppen nach Schweregrad (hat es die Aufgabe blockiert?) und Häufigkeit (wie viele Teilnehmende waren betroffen?). Blockierend und häufig kommt zuerst. Die verführerische Falle ist hier das eine lebhafte Zitat einer redegewandten Teilnehmerin: Es bleibt aus dem Debriefing am stärksten in Erinnerung und ist nicht unbedingt das Wichtigste.
7. Beheben, ausliefern und erneut testen
Ein Usability-Test, der in einem Dokument endet, ist gescheitert. Das Ergebnis sollte eine kurze priorisierte Liste sein, jeder Punkt mit einer verantwortlichen Person, die meisten davon klein: eine Beschriftung, ein Standardwert, ein umsortierter Schritt, eine Erklärung, die dorthin verschoben wird, wo die Verwirrung entsteht.
Bei dieser letzten Kategorie lohnt es sich zu verweilen. Ein beachtlicher Teil der Usability-Befunde sind keine Layoutprobleme, sondern fehlende Erklärungen in einem bestimmten Moment. Diese brauchen kein Redesign, sondern einen Tooltip oder eine kurze Produkttour, verankert an genau dem Element, an dem vier von fünf Personen innegehalten haben. Mit Kompassify können Sie diese Korrektur noch am selben Nachmittag ausliefern, ohne Release, und in der Woche darauf erneut testen.
So testen Sie die Usability Ihres Onboarding-Flows
Das Onboarding verdient einen eigenen Abschnitt, weil es die üblichen Testregeln bricht. Jeder Nutzer erlebt es, jeder erlebt es genau einmal, und es ist der einzige Flow, in dem die Teilnehmenden keinerlei angesammeltes Wissen haben, auf das sie zurückgreifen können. Es ist auch der Flow, den Ihr eigenes Team am wenigsten beurteilen kann, weil niemand von Ihnen sein Wissen über das Produkt wieder vergessen kann.
Am echten Anfang beginnen
Nicht beim Dashboard. Nicht bei einem vorkonfigurierten Konto. Am tatsächlichen Einstiegspunkt, der Landingpage oder dem Registrierungsformular, denn ein überraschend großer Teil der Reibung beim ersten Start entsteht, bevor sich überhaupt jemand angemeldet hat: in Form eines verwirrenden Felds, eines unerwarteten Pflichtschritts oder einer Lücke zwischen dem, was die Marketingseite versprochen hat, und dem, womit das Produkt startet. Unser Leitfaden zum Registrierungsprozess behandelt diesen Abschnitt im Detail.
Eine ergebnisorientierte Aufgabe stellen, dann nichts mehr sagen
Eine Aufgabe, formuliert als das Ergebnis, wegen dessen der Nutzer gekommen ist: „Kommen Sie an den Punkt, an dem Sie wissen, ob sich dieses Tool für Sie lohnt.“ Dann hören Sie auf zu reden. Die Versuchung, alles zu kommentieren, ist hier am größten, und jeder Satz, den Sie hinzufügen, macht den Test weniger realistisch.
Vier Dinge festhalten
- Die Zeit bis zum ersten sinnvollen Ergebnis, die beobachtbare Version der Time to Value
- Den ersten Moment des Zögerns, meist früher, als irgendjemand im Team erwartet
- Jede laut gestellte Frage, denn jede ist ein Stück fehlender Text im Produkt
- Ob sie den Aha-Moment überhaupt erreicht haben und, falls ja, ob sie ihn bemerkt haben
Den Empty State bewusst testen
Das häufigste Scheitern im Onboarding ist ein Nutzer, der auf einem leeren Screen landet und keine Ahnung hat, was er dort hineinsetzen soll. Bei internen Reviews fällt das nie auf, weil interne Konten voller Daten sind. Schicken Sie mindestens eine Teilnehmerin durch ein wirklich leeres Konto und beobachten Sie, was passiert. Lesen Sie danach unseren Leitfaden zu Empty States.
Den Kreis im Produkt schließen
Befunde aus dem Onboarding lassen sich ungewöhnlich direkt in Korrekturen im Produkt übersetzen. Die Teilnehmenden blieben am leeren Dashboard hängen? Das ist eine Checkliste. Niemand hat die Funktion gefunden, die den Mehrwert liefert? Das ist eine Produkttour, die beim ersten Aufruf startet. Alle haben bei Schritt drei dieselbe Frage gestellt? Das ist eine Zeile Microcopy.
Weil das Konfiguration statt Code ist, können Sie am Montag korrigieren und am Donnerstag erneut testen. Genau das macht das Onboarding zu dem Flow, in dem sich Usability-Tests am schnellsten auszahlen. Die Produktanalysen von Kompassify zeigen Ihnen dann, ob die Korrektur den Funnel für alle verbessert hat und nicht nur für Ihre fünf Teilnehmenden.
Ein Usability-Testskript zum Kopieren
Passen Sie die Teile in eckigen Klammern an. Behalten Sie die Struktur bei, und halten Sie die Einleitung in jeder Session identisch: Diese Einheitlichkeit macht fünf Sessions überhaupt erst vergleichbar.
Einleitung (2 Minuten)
- „Danke, dass Sie sich die Zeit nehmen. Das dauert etwa [30] Minuten.“
- „Wir testen das Produkt, nicht Sie. Es gibt keine falschen Antworten; wenn etwas verwirrend ist, liegt das Problem bei unserem Design.“
- „Bitte denken Sie laut. Sagen Sie mir, was Sie sehen, was Sie erwarten und was Sie überrascht.“
- „Ich bleibe meistens still, damit ich sehe, wie Sie das allein benutzen würden.“
- „Ist es in Ordnung, wenn ich Bildschirm und Ton aufzeichne? Die Aufnahme bleibt intern.“
Aufwärmen (3 Minuten)
- „Erzählen Sie mir ein wenig über Ihre Rolle und wie eine typische Woche aussieht.“
- „Wie erledigen Sie [die Aufgabe, für die dieses Produkt da ist] heute?“
- „Warum haben Sie nach etwas Neuem gesucht?“: die Push-Kraft, in einer einzigen Frage
Aufgaben (20 Minuten)
- Aufgabe 1 (erster Eindruck): „Schauen Sie sich diese Seite an. Ohne etwas anzuklicken: Sagen Sie mir, was das Ihrer Meinung nach macht und für wen es gedacht ist.“
- Aufgabe 2 (die Kernaufgabe): „[Realistisches Szenario]. Kommen Sie an den Punkt, an dem Sie haben, was Sie brauchen.“
- Aufgabe 3 (der verdächtige Flow): „[Der konkrete Schritt, an dem laut Ihrem Funnel die Leute abbrechen].“
- Nach jeder Aufgabe: „Wie leicht oder schwer war das auf einer Skala von 1 bis 7?“ (SEQ)
Abschluss (5 Minuten)
- „Was war daran am verwirrendsten?“
- „Wenn Sie eine Sache ändern könnten, welche wäre das?“
- „Hätten Sie weitergemacht, wenn ich nicht hier gewesen wäre? An welchem Punkt hätten Sie aufgehört?“
- Optional: die System Usability Scale mit 10 Fragen
Häufige Fehler beim Usability-Test
✅ Tun
- Mit Menschen testen, die das Produkt noch nie gesehen haben
- Aufgaben als Ergebnisse formulieren, nie als Anleitungen
- Beim Zögern still bleiben
- Sessions aufzeichnen und die Clips teilen, nicht nur die Zusammenfassung
- Nach Schweregrad und Häufigkeit zusammen priorisieren
- Oft in kleinen Runden testen statt selten in einer großen
- Nach der Korrektur erneut testen
❌ Lassen
- Mit Kollegen, Freunden oder bestehenden Power-Usern testen
- Den Button nennen, auf den sie klicken sollen
- Fragen, ob ihnen das Design „gefällt“
- Teilnehmende retten, sobald sie innehalten
- Prozentwerte von fünf Personen berichten
- Auf einem Demokonto voller ordentlicher Beispieldaten testen
- Die Befunde in einer Präsentation enden lassen
Der Fehler, der alles entwertet: die Teilnehmenden lenken. Das passiert in kleinen Schritten: eine Aufgabe, die den Menüpunkt nennt, eine Moderatorin, die sagt „Haben Sie es schon oben rechts versucht?“, ein Nicken, wenn sich jemand der richtigen Antwort nähert. Jedes einzelne wirkt harmlos, und zusammen verwandeln sie einen Usability-Test in eine geführte Demo, die bestätigt, was Sie ohnehin schon glaubten.
Beheben Sie, was Ihre Usability-Tests finden, ohne auf ein Release zu warten
Mit Kompassify fügen Sie Produkttouren, Tooltips, Onboarding-Checklisten und In-App-Umfragen genau dort ein, wo Nutzer hängen bleiben, ohne Code und ohne Deployment. Messen Sie das Ergebnis mit den integrierten Produktanalysen. Kostenlos bis 100 monatlich aktive Nutzer, DSGVO-konform und in der EU gehostet.
Kostenlos starten →Häufig gestellte Fragen
Was ist ein Usability-Test?
Ein Usability-Test ist eine Forschungsmethode, bei der echte Nutzer realistische Aufgaben in einem Produkt ausführen, während ein Beobachter festhält, wo sie Erfolg haben, zögern oder scheitern. Ziel ist nicht, Menschen zu fragen, ob ihnen die Oberfläche gefällt, sondern zu beobachten, was tatsächlich passiert, wenn sie sie benutzen. Ein Usability-Test misst, wie leicht sich eine bestimmte Aufgabe erledigen lässt, und bringt zuverlässig Probleme ans Licht, die interne Teams nicht sehen können, weil sie bereits wissen, wie das Produkt funktioniert.
Wie viele Nutzer braucht man für einen Usability-Test?
Fünf Teilnehmende pro Nutzergruppe sind der übliche Richtwert. Er geht auf die Erkenntnis von Jakob Nielsen zurück, dass fünf Nutzer in einem Flow typischerweise rund 85 % der Usability-Probleme aufdecken. Fünf passen für qualitative Tests, die Probleme finden sollen. Brauchen Sie statistisch belastbare Zahlen, etwa eine Erfolgsquote, die Sie berichten oder über die Zeit vergleichen wollen, benötigen Sie deutlich mehr, meist 20 oder mehr pro Gruppe. Bedienen Sie wirklich unterschiedliche Segmente, testen Sie fünf pro Segment statt fünf insgesamt.
Was ist der Unterschied zwischen einem Usability-Test und einem A/B-Test?
Ein Usability-Test zeigt Ihnen, warum etwas nicht funktioniert; ein A/B-Test zeigt Ihnen, welche Version gewinnt. Der Usability-Test ist qualitativ, läuft mit einer Handvoll Teilnehmender und liefert Erklärungen und beobachtete Ursachen. Der A/B-Test ist quantitativ, braucht viel Live-Traffic und liefert ein statistisch vergleichbares Ergebnis ohne jede Erklärung. Am besten funktionieren beide nacheinander: Mit dem Usability-Test finden Sie das Problem und entwerfen eine glaubwürdige Lösung, dann testen Sie diese Lösung per A/B-Test im großen Maßstab.
Was sind die wichtigsten Usability-Metriken?
Am nützlichsten sind die Erfolgsquote (der Anteil der Teilnehmenden, die die Aufgabe ohne Hilfe abschließen), die Bearbeitungszeit, die Fehlerrate, die Anzahl nötiger Hilfestellungen, der Wert der Single Ease Question direkt nach jeder Aufgabe und die System Usability Scale am Ende der Session. In kleinen qualitativen Studien haben die Erfolgsquote und die beobachteten Reibungspunkte das größte Gewicht; die Fragebogenwerte werden vor allem dann aussagekräftig, wenn Sie sie über mehrere Runden vergleichen.
Was ist der Unterschied zwischen moderiertem und unmoderiertem Usability-Test?
Beim moderierten Test ist eine Researcherin oder ein Researcher dabei, vor Ort oder remote, und kann nachfragen, wenn jemand zögert. Das liefert tiefere Erkenntnisse und eignet sich am besten für komplexe Flows und frühe Prototypen. Beim unmoderierten Test erledigen die Teilnehmenden die Aufgaben allein, während ihr Bildschirm aufgezeichnet wird. Das ist günstiger, schneller und leichter in großer Zahl durchzuführen, aber Sie können im Moment der Verwirrung nicht nachhaken. Deshalb funktioniert es am besten bei klar definierten Aufgaben in einem funktionierenden Produkt.
Wie führt man einen Usability-Test für einen Onboarding-Flow durch?
Rekrutieren Sie Menschen, die das Produkt noch nie gesehen haben, denn wer es kennt, kann die Verwirrung beim ersten Start nicht mehr erleben. Beginnen Sie die Session am echten Einstiegspunkt, meist der Registrierungsseite statt eines bereits angemeldeten Zustands, und stellen Sie eine ergebnisorientierte Aufgabe, etwa ein erstes abgeschlossenes Ergebnis zu erreichen. Erklären Sie nichts. Halten Sie fest, wo die Teilnehmenden stoppen, was sie laut sagen und wie lange das erste sinnvolle Ergebnis dauert. Schließen Sie dann den Kreis im Produkt, indem Sie genau dort kontextbezogene Hilfe einbauen, wo die Leute hängen geblieben sind, zum Beispiel mit den No-Code-Produkttouren von Kompassify, und testen Sie erneut.
Wie oft sollte man Usability-Tests durchführen?
Klein und kontinuierlich schlägt groß und gelegentlich. Ein sinnvoller Rhythmus für die meisten SaaS-Teams ist eine kurze Runde pro Sprint oder alle zwei Sprints, mit drei bis fünf Teilnehmenden und einem engen Fokus auf das, was gerade ausgeliefert wurde oder bald ausgeliefert wird. Führen Sie zusätzlich eine eigene Session für jeden Flow durch, dessen Analysen einen unerklärten Abbruch zeigen, und testen Sie Ihre Registrierung und das erste Nutzungserlebnis mindestens zweimal im Jahr erneut; beides verschiebt sich, wenn sich Funktionen ansammeln. Unser Leitfaden zum Onboarding-Audit zeigt, wie Sie diese regelmäßige Prüfung aufbauen.