Was vorher fertig sein muss
Ein klickbarer Prototyp, ein Staging-System oder das Live-Produkt mit den Test-Pfaden ist verfügbar und stabil.
3-5 realistische Aufgaben mit klarem Erfolgskriterium sind formuliert, abgeleitet aus tatsächlichen Nutzungs-Szenarien.
Was vor Start vorliegen muss
Testbares Artefakt (Prototyp, Staging, Live); Aufgaben-Skript mit Wortlaut; Recording-Tool (Lookback, Maze, Zoom mit Screen Share); Beobachtungs-Template (Task, beobachtetes Verhalten, Probleme, Schwere 1-4); Belohnung für Teilnehmer.
Ein Moderator für die Sessions; ein bis drei stille Beobachter für Notizen aus dem Team; optional Note-Taker für Synthese; Recruiter für 5-8 Teilnehmer aus Zielgruppe.
Aufgaben in Reihenfolge mit Wortlaut; Erfolgskriterien pro Task; bekannte Hypothesen (was wir vermuten, dass schiefgeht); Demografie der Teilnehmer; Testumgebung mit Daten-Setup.
1-2 h je Session, plus 4-8 h Vorbereitung und Synthese
5-8 Sessions à 45-60 min planen (Nielsen-Schwelle: 5 Tester decken ~85% der Usability-Probleme auf). Pilot mit 1 Person, dann Hauptdurchläufe. Stille Beobachter im Raum oder remote, Moderator führt allein. Schweregrad-Skala festlegen (1=Show-Stopper, 4=kosmetisch).
Die eine Frage, die diese Methode beantwortet
Können typische Nutzer die zentralen Tasks erfolgreich, effizient und zufriedenstellend abschließen, und wo scheitern sie woran?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Briefing und Warm-up | 5-10 min | Teilnehmer begrüßen, Zweck erklären („Wir testen das Produkt, nicht Sie“). Think-Aloud-Methode einführen, Einwilligung bestätigen. Demographische Warm-up-Fragen. | Tester unter Druck zu setzen verzerrt Ergebnisse. „Es gibt kein Falsch hier“ explizit sagen. Wenn Tester schweigt, freundlich an Think-Aloud erinnern. |
2Phase 2: Tasks ausführen lassen | 30-45 min | Tasks in Reihenfolge vorlesen. Tester arbeiten selbstständig, Moderator beobachtet stumm. Nur bei festsitzen vorsichtig nachfragen („Was denken Sie gerade?“). Keine Hilfe geben, kein Lösungsweg vorgeben. | Wenn Tester nach 5 min nicht weiterkommt und das Erfolgskriterium nicht erreicht, Task abbrechen. Das ist ein Daten-Punkt, kein Versagen. |
3Phase 3: Post-Task-Fragen | 5-10 min | Nach jedem Task: Schwierigkeitsbewertung (1-7), kurzer „Was war frustrierend?“ und „Was war hilfreich?“. Am Ende SEQ oder UMUX-Lite-Fragebogen. | Quantitative Mini-Skala plus qualitative Begründung. Nur quantitativ ist dünn, nur qualitativ schwer vergleichbar. |
4Phase 4: Debriefing pro Session | 10 min nach jeder Session | Moderator und Beobachter notieren je Top-3 Probleme. Schweregrad zuweisen. Aufzeichnung sichern und ablegen. | Sofort nach Session debriefen. Sonst vermischen sich Sessions in der Erinnerung und Detail geht verloren. |
5Phase 5: Synthese und Rangliste | 3-6 h nach allen Sessions | Alle Probleme aggregieren, doppelte konsolidieren. Pro Problem Häufigkeit (wie viele Tester betroffen) und Schweregrad. Top-Probleme nach Häufigkeit × Schwere sortieren. Empfehlungen ableiten. | Häufigkeit allein irreführend. Show-Stopper bei 1/5 ist wichtiger als kosmetischer Hinweis bei 5/5. Schwere ernst nehmen. |
Was am Ende rauskommt
Usability-Report mit Sample-Beschreibung, Task-Erfolgsraten, Liste der Probleme (sortiert nach Häufigkeit × Schwere), Zitat-Belegen, Empfehlungen pro Problem und Aufzeichnungs-Links (intern).
Pro Test-Runde eigene Reports mit Datum und Artefakt-Version. Wiederholungs-Tests nach Fixes mit explizitem „getestet gegen Version Y am …“ Status. Verlauf der wichtigsten Probleme über Test-Runden hinweg visualisieren.
Kompakte Arbeitsvorlage für Usability Testing mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Usability Testing Arbeitsvorlage
## Ziel
Beobachtet Menschen beim Verwenden eines Designs, um Usability-Probleme zu finden.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Usability Issues:
- Severity List:
- Recommendations:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Usability Test — Checkout-Prototyp v2 (KW 19/2026, n=5)
**Sample**: 5 Online-Shopper aus Zielgruppe (3 mobil, 2 Desktop). Vergütung 30 EUR.
### Task-Erfolgsraten
| Task | Erfolg | Avg Zeit | Avg SEQ |
|---|---|---|---|
| Produkt in Warenkorb | 5/5 | 0:42 | 6,4 |
| Checkout starten | 5/5 | 0:18 | 6,8 |
| Lieferadresse eingeben | 3/5 | 2:24 | 4,2 |
| Zahlungsmethode wählen + bezahlen | 4/5 | 1:48 | 5,0 |
| Bestellbestätigung verstehen | 5/5 | 0:25 | 6,2 |
### Top-Probleme
**P1 (Show-Stopper, 2/5 betroffen, Severity 1)**: PLZ-Feld validiert beim Verlassen, Fehlertext erscheint UNTER dem nächsten Feld. Tester sahen Fehler nicht und scheiterten am Submit.
- Zitat (T2): „Ich habe drei Mal gedrückt und nichts passierte, dann hab ich abgebrochen.“
- Empfehlung: Inline-Fehlermeldung direkt unter PLZ-Feld, plus Focus auf das betroffene Feld bei Submit-Fehler.
**P2 (Major, 3/5 betroffen, Severity 2)**: „Lieferadresse identisch mit Rechnungsadresse“-Checkbox war aus, Tester füllten Adresse doppelt.
- Zitat (T4): „Warum muss ich das zweimal eingeben?“
- Empfehlung: Checkbox per Default an.
**P3 (Moderate, 2/5 betroffen, Severity 3)**: Apple-Pay-Button war nicht als anklickbar erkennbar (zu klein, fehlende Affordance).
- Empfehlung: Größeren Touch-Bereich, klare CTA-Beschriftung.
### Empfehlungs-Priorität
1. P1 vor Launch fixen (Show-Stopper)
2. P2 vor Launch (kostengünstig, hoher Effekt)
3. P3 in nächster Iteration (Apple-Pay-Adoption-Hebel)Symptome erkennen, gegensteuern
Bei Schwierigkeiten gibt Moderator Hinweise oder verteidigt das Design.
Standardphrasen üben: „Was denken Sie?“, „Was würden Sie als nächstes tun?“. Schweigen aushalten. Hilfe verfälscht das Ergebnis komplett.
Tester sitzen in einem Raum vor unbekanntem Gerät mit Beobachtern, Verhalten weicht von echter Nutzung ab.
Möglichst auf Tester-Gerät testen (Remote-Test, eigenes Handy). Beobachter unsichtbar oder minimal. Realistische Aufgaben-Szenarien.
10+ Tasks in einer Session, Tester ermüden, letzte Tasks liefern Müll-Daten.
Maximal 5 Hauptaufgaben in 60 min. Wenn mehr nötig, mehrere Sessions oder kürzere Aufgaben. Müdigkeit produziert Pseudo-Daten.
Probleme, die dem Team nicht passen, werden als „Nutzer-Fehler“ kategorisiert und ignoriert.
Regel: was zwei oder mehr Tester treffen, ist immer ein Design-Problem. Severity diskutieren, nicht Existenz.
Probleme werden gefixt, aber nicht erneut getestet. Es ist unbekannt, ob der Fix wirkt oder neue Probleme erzeugt.
Wiederholungs-Test nach Major-Fixes mit 3-5 neuen Testern. Fix-Verifikation ist Teil der Definition of Done.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.