Bevor ein neues digitales Produkt, sei es eine Website, App oder Software, live geht, stellen sich immer dieselben Fragen: Verstehen Menschen, was dort angeboten wird? Finden sie, wonach sie suchen? Und fühlt sich alles so an, wie es geplant war? Diese Fragen sind nicht nebensächlich: Studien zufolge verlassen bis zu 80% der Nutzer:innen eine Anwendung wieder, wenn die Benutzerfreundlichkeit nicht stimmt. Genau dafür gibt es Usability-Tests, mit echten Nutzer:innen, die oft im Rahmen eines Design Sprints stattfinden.
Denn intern wird man schnell betriebsblind. Ein Team kennt die Struktur, die Begriffe und die Entscheidungen hinter ihrem Produkt. Nutzer:innen sehen dagegen nur Texte, Buttons und Bilder, womit sie sich einen ersten Eindruck verschaffen. Also genau das, was tatsächlich vor ihnen liegt.
Für mich sind es die ersten Usability-Tests, die ich als Praktikantin selbst begleite. Dabei merke ich schon jetzt, was entscheidend ist. Und zwar nicht, dass sich ein Produkt intern gut erklären lässt, sondern vielmehr, ob Menschen es ohne Erklärung verstehen können.
Was ich vor meinen ersten Tests erwartet habe
Vor meinen ersten Usability-Tests dachte ich vor allem an klare Ergebnisse. Wurde die Aufgabe geschafft? Das Gesuchte gefunden? Die Navigation verstanden? All das spielt natürlich eine Rolle. Schon in der Vorbereitung wurde aber klar, dass ein Usability-Test mehr zeigt als nur "geschafft" oder "nicht geschafft".
Was Usability-Tests tatsächlich testen
Ein Usability-Test prüft, wie gut Menschen mit einem Produkt oder einem Prototypen zurechtkommen. Dabei geht es nicht um Geschmack oder persönliche Vorlieben, sondern darum, ob Nutzer:innen in einem bestimmten Kontext ihre Ziele effektiv, effizient und möglichst zufriedenstellend erreichen können. Die Usability ist damit ein zentraler Bestandteil der gesamten User-Experience, also des Gesamteindrucks, den ein Produkt bei der Nutzung hinterlässt.
In der Praxis bekommen Testpersonen dafür realistische Aufgaben. Sie suchen zum Beispiel bestimmte Informationen, orientieren sich durch die Navigation oder versuchen herauszufinden, ob ein Angebot zu ihrem Anliegen passt. Beobachtet wird, wo sie sicher weiterkommen, wo sie hängen bleiben und welche Elemente ihnen helfen oder im Weg stehen.
Oft sind gerade die kleinen Momente spannend: ein kurzes Zögern, ein Scrollen ohne Orientierung oder ein Begriff, der laut vorgelesen wird. Solche Reaktionen zeigen, wo eine Anwendung noch Reibung erzeugt, obwohl sie auf den ersten Blick fertig wirkt.
Für ein neues Produkt bedeutet das, dass man nicht nur sieht, ob etwas schön aussieht oder intern logisch aufgebaut ist, sondern auch, ob es im tatsächlichen Gebrauch Orientierung gibt.
Die Methode beim Usability-Test im Design Sprint
Sobald der Prototyp steht, folgt im Design Sprint das Usability-Testing. Je nach Kontext kommen unterschiedliche Usability-Test-Methoden zum Einsatz: moderierte Sessions vor Ort im Usability-Labor oder Remote Usability-Testing ohne physische Anwesenheit. Wenn du mehr über Design Sprints wissen möchtest, lies unseren passenden Blog-Artikel.
Die Suche nach passenden Testpersonen beginnt idealerweise schon früher im Sprint, damit am Testtag wirklich Menschen teilnehmen, die zur späteren Zielgruppe passen. Im klassischen Design-Sprint-Ablauf wird ein Prototyp schnell gebaut und anschließend mit Nutzer:innen getestet, um früh echtes Feedback zu bekommen (Google Design Sprint Kit, o. D.).
Typischerweise läuft der Test in mehreren Schritten ab:
- Ziele und Aufgaben festlegen: Was soll herausgefunden werden? Welches Ziel wird konkret verfolgt, und welche Use Cases oder alltagsnahen Szenarien sollen geprüft werden? Welche Bereiche des Produkts sollen getestet werden und welche realistischen Aufgaben bekommen die Testpersonen?
- Testpersonen auswählen: Die Teilnehmenden sollten möglichst nah an der späteren Zielgruppe sein. Die Rekrutierung sollte repräsentativ sein und erfolgt oft aus Panels oder bestehenden Kundenstämmen.
- Test durchführen: Eine Person begleitet die Testperson durch den Ablauf, stellt die Aufgaben und bleibt dabei möglichst neutral. Solche Sessions dauern meist 30 bis 60 Minuten. Lautes Denken macht Denkprozesse und Missverständnisse sichtbar. Ethik und Datenschutz sollten vor dem Testing geklärt sein.
- Beobachten und dokumentieren: Die übrigen Gruppenmitglieder schauen zu und notieren Reaktionen, Fehler, Umwege, Unsicherheiten und Feedback. Diese systematische Beobachtung macht das Team zu einem aktiven Teil des Prozesses.
- Beobachtungen übersetzen: "Wie können wir"-Fragen helfen dabei, aus Beobachtungen konkrete Verbesserungsansätze zu machen, wie zum Beispiel: „Wie können wir klarer machen, dass genau dieser Button angeklickt werden soll?“
- Ergebnisse auswerten: Die Notizen werden gesammelt, geordnet und nach Mustern durchsucht. Auch KI kann hier unterstützen, indem sie Beobachtungen strukturiert, ähnliche Rückmeldungen bündelt und Learnings klarer formuliert.
- Verbesserungen ableiten: Nach dem Usability-Test endet zwar der Design Sprint, aber die eigentliche Weiterarbeit beginnt erst: Die Erkenntnisse zeigen, was am Prototyp verbessert werden sollte.
Warum fünf Tests reichen können, um Muster zu erkennen
Fünf Usability-Tests ersetzen keine große Studie. Aber sie können reichen, um erste Muster sichtbar zu machen. Bei qualitativen Tests geht es nicht darum, repräsentative Zahlen zu liefern, sondern wiederkehrende Probleme früh zu erkennen.
Die Nielsen Norman Group empfiehlt für qualitative Usability-Tests häufig rund fünf Testpersonen, weil nach einigen Tests viele zentrale Probleme bereits mehrfach auftauchen und zusätzliche Tests oft weniger neue Erkenntnisse bringen (Nielsen, 2000; Moran, 2019). Schon 5 bis 8 Testpersonen können dabei bis zu 85 % kritischer Usability-Probleme aufdecken. Die Zahl fünf ist also kein magischer Wert, sondern ein pragmatischer Ansatz. Klein genug, um im Sprint schnell zu lernen, und groß genug, um erste Muster nicht nur aus einem einzelnen Eindruck abzuleiten.
Für einen Design-Sprint passt das gut. Es geht nicht darum, statistisch zu beweisen, dass ein Produkt fertig ist. Frühe Erkenntnisse im Sprint können Entwicklungszeit und -kosten um bis zu 50 % senken, weil Probleme noch vor der Umsetzung oder vor dem Launch erkannt werden. Wenn mehrere Testpersonen an ähnlichen Stellen hängen bleiben, ist das ein starkes Signal, dass hier noch Arbeit ansteht.
Was ich beim Usability-Testing selbst gelernt habe
Für mich als Praktikantin war besonders ungewohnt, nicht sofort einzugreifen. Wenn eine Testperson zögert, einen Begriff anders versteht oder einen Button übersieht, ist der erste Impuls oft, zu helfen und zu erklären. Genau das darf im Usability-Test aber nicht zu früh passieren. Stattdessen geht es darum, ruhig zu bleiben, zu beobachten und neutral nachzufragen, wie zum Beispiel: „Was würdest du als Nächstes tun?“
Dabei habe ich gelernt, wie viel kleine Reaktionen erzählen können: eine Pause, ein Stirnrunzeln, ein Zurückscrollen oder ein unsicheres „Ich glaube, ich würde hier klicken“. Neben solchen qualitativen Eindrücken lassen sich auch Erfolgsquote und Fehleranzahl als Metriken erfassen. Die Zufriedenheit wird oft zusätzlich mit standardisierten Fragebögen erhoben. Für mich war das ein Perspektivwechsel: Ich musste lernen, Unsicherheit nicht sofort aufzulösen, sondern sie als wichtigen Hinweis ernst zu nehmen.
Wichtig ist außerdem, unterschiedliche Bedürfnisse mitzudenken: Inklusive Tests beziehen auch Menschen mit Behinderungen ein und machen sichtbar, wo eine Anwendung für sie funktioniert und wo nicht. Ergänzend kann die Messung von Blickbewegungen (Eye-Tracking) helfen, solche Muster genauer einzuordnen.
Fazit: Usability-Tests sind ein Realitätscheck
Meine ersten Usability-Tests zeigen mir vor allem, dass ein Produkt nicht automatisch verständlich ist, nur weil es intern logisch aufgebaut ist. Erst im tatsächlichen Gebrauch wird sichtbar, ob Struktur, Sprache und Orientierung wirklich funktionieren.
Für ein neues Produkt sind Usability-Tests deshalb ein wichtiger Realitätscheck vor dem Launch. Sie zeigen, ob Menschen verstehen, was angeboten wird, ob sie sich orientieren können und wo Inhalte noch nachgeschärft werden sollten. Als Praktikantin habe ich so nicht nur etwas über ein konkretes Projekt gelernt, sondern vor allem, wie wichtig es ist, digitale Projekte immer wieder aus der Perspektive der Nutzer:innen zu betrachten.