Ein Buchungsprozess endet auf der Bestätigungsseite, doch die Testperson hat das falsche Datum ausgewählt. Ob diese Session nun als Erfolg zählt, hängt davon ab, was mit der Studie eigentlich gemessen werden sollte. Die Task Success Rate (oder Task Completion Rate) ist genau dann nützlich, wenn sich das Team einig ist, was ein erfolgreicher Abschluss überhaupt bedeutet.
Die Basisrechnung ist simpel: Anzahl der erfolgreichen Versuche geteilt durch die Anzahl der gültigen Versuche, mal 100. Schließen in einer Beispielstudie 16 von 20 Personen dieselbe Aufgabe erfolgreich ab, liegt die beobachtete Erfolgsquote bei 80 %. Das beschreibt genau diese Stichprobe unter diesen Testbedingungen – es ist keine allgemeingültige Aussage über künftige Nutzer*innen.
Definiert Erfolg, bevor ihr euch die Sessions anseht
Formuliert ein beobachtbares Kriterium, das zum Ziel der Testperson passt. Den Checkout zu erreichen, irgendein Ticket zu kaufen oder das passende Ticket zu kaufen, sind völlig unterschiedliche Ergebnisse. Ein Aufgabenszenario sollte das Ziel vorgeben, ohne den Weg dorthin zu verraten. Im Research-Plan wird wiederum festgehalten, was die beobachtende Person als Erfolg wertet.
Die Einführung zur Success Rate der Nielsen Norman Group erklärt den Wert dieser einfachen Kennzahl. Ihr Nutzen steht und fällt jedoch mit einer konsistenten Bewertung – besonders dann, wenn jemand Hilfe bekommt, vorzeitig abbricht oder fälschlicherweise glaubt, die Aufgabe gelöst zu haben.
Legt vorher fest, wie ihr mit Unterstützung durch die Moderation oder technischen Problemen umgeht. Bricht der Test ab, weil das Equipment streikt, kann das nach einer dokumentierten Regel ausgeschlossen werden. Bricht jemand ab, weil es im Produkt einfach nicht weitergeht, ist das eine wichtige Erkenntnis über die User Experience. Nicht erfolgreiche Versuche stillschweigend unter den Tisch fallen zu lassen, würde die Quote verfälschen.
Macht Teilerfolge sichtbar
Manche Aufgaben haben mehrere relevante Teilschritte. Vielleicht findet jemand das richtige Konto, versteht aber die Auszahlungsbedingungen falsch. Oder ein Formular wird erst ausgefüllt, nachdem die Moderation auf ein Pflichtfeld hinweist. Haltet solche Fälle fest, damit die finale Zahl diese wichtigen Hürden nicht einfach verschluckt.
Wenn der Report auf ein binäres Schema setzt (Erfolg/Misserfolg), macht transparent, welche Fälle sich qualifizieren. Nutzt ihr eine eigene Kategorie für Teilerfolge oder einen gewichteten Score, erklärt diesen Ansatz und stellt das Ergebnis nicht wie eine normale Completion Rate dar. Die Bewertungsregeln sollten über alle verglichenen Versionen hinweg stabil bleiben.
Eine kurze Notiz zu den beobachteten Problemen bringt dem Design-Team oft mehr als die reine Einstufung. „Fehlgeschlagen“ beschreibt nur den Ausgang; „hat das richtige Lieferdatum gewählt, konnte sich nach einem Adressfehler aber nicht mehr orientieren“ zeigt konkret, wo das Team ansetzen kann.
Zeigt die Unschärfe neben der Prozentzahl
Kleine Stichproben liefern unsichere Schätzwerte. Wenn man 80 % ohne Gesamtzahl nennt, wirken vier Erfolge bei fünf Versuchen wie 80 von 100 – auch wenn sich die Genauigkeit enorm unterscheidet. Nennt immer die Anzahl der gültigen Versuche und gebt ein passendes Konfidenzintervall an, wenn die Studie darauf ausgelegt ist, eine Quote zu schätzen.
Die Forschung von Sauro und Lewis zu Intervallen bei Completion Rates beleuchtet Methoden, die genau zu diesem Problem passen. Vermeidet es, rein mechanisch ein simples symmetrisches Intervall anzusetzen – besonders nahe 0 % oder 100 % – und deutet kleine Unterschiede zwischen beobachteten Quoten nicht vorschnell als bestätigte Verbesserung.
Kombiniert den Abschluss mit dem Weg dorthin
Der reine Erfolg sagt noch nichts darüber aus, ob eine Aufgabe zäh, unsicher oder anstrengend war. Beobachtungen, Fehler und die Single Ease Question helfen dabei, das Nutzungserlebnis hinter dem Ergebnis zu verstehen. Eine Person kommt vielleicht durch langes Ausprobieren ans Ziel, während eine andere völlig überzeugt den falschen Weg einschlägt.
Trennt beim Testen von Prototypen immer Schwächen des Prototyps von Problemen, die auch im fertigen Design bestehen würden. Vergleicht Quoten nur dann, wenn Aufgaben, Teilnehmende, Bewertung und Testbedingungen diesen Vergleich wirklich hergeben. Das Ergebnis sollte dem Team helfen zu entscheiden, was verbessert werden muss – mit genug Kontext, um zu verstehen, was die Zahl allein nicht erzählt.