UX messbar machen: Erfolgsquote, Bearbeitungszeit und SUS richtig nutzen

Stell dir ein Produktteam vor, das in einer HR-Software das Modul für Reisekosten neu gestaltet hat. Mitarbeitende fotografieren dort ihre Belege, ordnen sie einer Reise zu und reichen die Abrechnung bei der Buchhaltung ein. Drei Wochen nach dem Launch präsentiert das Team stolz die erste Zahl: Die Seitenaufrufe im Modul sind um 30 Prozent gestiegen. Kurz darauf meldet sich der Support. Die Zahl der Tickets zum Thema Reisekosten ist ebenfalls gestiegen, und die Buchhaltung schickt mehr Abrechnungen zur Korrektur zurück als vorher.

War die Neugestaltung also ein Erfolg? Niemand im Raum kann das sicher sagen. Mehr Seitenaufrufe können heißen, dass Menschen das Modul lieber nutzen. Sie können aber genauso heißen, dass Menschen sich verlaufen und hin und her klicken. Das Team hat gemessen, aber nicht das, was es eigentlich wissen wollte.

Dieser Artikel zeigt, mit welchen Kennzahlen du die Qualität einer Nutzungserfahrung tatsächlich erfasst, wie du sie richtig berechnest und wo die typischen Denkfehler liegen. Das Reisekosten-Modul dient dabei als durchgehendes Beispiel. Es ist erfunden, aber typisch.

Warum UX-Metriken?

Qualitative Usability-Tests zeigen dir, wo und warum Menschen scheitern. Sie sagen dir aber nicht, ob sich eine Änderung gelohnt hat oder ob das Produkt über die Zeit besser wird. Dafür brauchst du Zahlen.

Einen Rahmen dafür liefert die Norm ISO 9241-11. Sie beschreibt Usability als das Ausmaß, in dem bestimmte Menschen ein System in einem bestimmten Nutzungskontext nutzen können, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen. Aus diesen drei Begriffen lassen sich die klassischen Metriken direkt ableiten: Effektivität misst du mit der Erfolgsquote und den Fehlern, Effizienz mit der Bearbeitungszeit, Zufriedenheit mit Fragebögen wie SUS oder SEQ.

Metriken stehen dabei nicht für sich allein. Auch das Google-Team hinter dem HEART-Framework betont, dass sie mit Erkenntnissen aus Usability-Tests und Feldstudien abgeglichen werden sollten und keine frühe User Research ersetzen. Zahlen sagen dir, dass etwas passiert. Warum, erfährst du durch Beobachten und Nachfragen.

Verhalten und Einstellung: zwei Arten von Daten

Christian Rohrer von der Nielsen Norman Group ordnet Forschungsmethoden unter anderem danach, ob sie Verhalten oder Einstellungen erfassen. Er bringt den Unterschied auf eine griffige Formel: „what people say“ gegenüber „what people do“, also was Menschen sagen, gegenüber dem, was sie tun. Beides kann deutlich auseinanderliegen.

• Verhaltensbezogene Metriken beobachtest du: Hat jemand die Aufgabe geschafft? Wie lange hat es gedauert? Wie viele Fehler sind passiert? Wie oft kommt jemand wieder?
• Einstellungsbezogene Metriken erfragst du: Wie leicht fand jemand die Aufgabe? Wie bewertet jemand das System insgesamt? Würde jemand es weiterempfehlen?

Du brauchst in der Regel beides. Die beiden Sichtweisen hängen zusammen, sind aber nicht dasselbe. Jeff Sauro, der mit seiner Firma MeasuringU seit vielen Jahren Benchmarks zu UX-Metriken sammelt, findet etwa zwischen der Einschätzung der Schwierigkeit einer Aufgabe und Zeit oder Erfolg nur einen mittleren Zusammenhang von ungefähr r = 0,5. Wer nur fragt, übersieht Probleme, die Menschen gar nicht bemerkt haben. Wer nur beobachtet, weiß nicht, wie sich die Nutzung angefühlt hat.

Erfolgsquote: die einfachste und wichtigste Zahl

Die Erfolgsquote gibt an, wie viele Testpersonen eine Aufgabe erfolgreich abgeschlossen haben. Die Berechnung ist simpel: Erfolg zählt als 1, Misserfolg als 0, der Durchschnitt ist die Quote. Wenn Menschen eine Aufgabe nicht schaffen, ist fast jede andere Kennzahl zweitrangig.

Die eigentliche Arbeit steckt in der Vorbereitung. Lege vor dem Test fest, was als Erfolg zählt, und zwar so konkret, dass zwei Personen unabhängig voneinander zum selben Urteil kommen. Im Reisekosten-Modul lautet die Aufgabe: „Reiche die Hotelrechnung deiner Dienstreise nach Hamburg ein.“ Erfolg heißt: Der Beleg ist der richtigen Reise zugeordnet, der Betrag stimmt, und die Abrechnung ist abgeschickt. Ein Beleg, der im Entwurf hängen bleibt, ist kein Erfolg, auch wenn die Person glaubt, fertig zu sein.

Als grobe Orientierung hat Jeff Sauro 2011 die Daten von 1.189 Aufgaben aus Usability-Tests ausgewertet. Im Schnitt lag die Erfolgsquote bei 78 Prozent. Sauro ordnet diesen Wert zugleich als 50. Perzentil ein: Etwa die Hälfte der Aufgaben lag darüber, die Hälfte darunter. Ob 78 Prozent für deine Aufgabe gut sind, hängt aber stark vom Kontext ab. Bei einer Überweisung im Onlinebanking ist das viel zu wenig.

Konfidenzintervalle für kleine Stichproben

Das Team testet die gestartete Fassung mit zwölf Mitarbeitenden. 7 von 12 schaffen die Aufgabe, also 58 Prozent. Nach einer gezielten Überarbeitung sind es in einem zweiten Test 11 von 12, also 92 Prozent. Das klingt nach einem klaren Fortschritt. Bei so kleinen Stichproben ist der beobachtete Wert aber nur eine Schätzung. Wie genau sie ist, zeigt das Konfidenzintervall.

Für Erfolgsquoten aus kleinen Stichproben empfehlen Sauro und James R. Lewis das sogenannte angepasste Wald-Intervall (adjusted Wald). Es korrigiert die Schwäche der einfachen Formel, die bei kleinen Stichproben unzuverlässig wird und zum Beispiel bei 10 von 10 Erfolgen ein Intervall ohne jede Breite liefert. Rechner dafür gibt es kostenlos im Netz. Für das Beispiel ergibt sich mit 95 Prozent Konfidenz:

• Vorher: 7 von 12, Intervall von etwa 32 bis 81 Prozent.
• Nachher: 11 von 12, Intervall von etwa 62 bis 100 Prozent.

Die Intervalle überlappen sich. Das heißt nicht automatisch, dass es keinen Unterschied gibt, aber es zeigt, wie unsicher die genaue Größe des Effekts ist. Ehrlicher als „Die Erfolgsquote ist von 58 auf 92 Prozent gestiegen“ ist deshalb: „Die neue Version schneidet deutlich besser ab, die tatsächliche Erfolgsquote liegt wahrscheinlich irgendwo über 60 Prozent.“

Bearbeitungszeit: warum der Durchschnitt täuscht

Die Bearbeitungszeit (englisch „time on task“) misst, wie lange jemand für eine Aufgabe braucht. Bei der Auswertung lauert allerdings eine Falle. Bearbeitungszeiten sind fast immer rechtsschief verteilt: Die meisten Menschen sind ähnlich schnell, einige wenige brauchen sehr viel länger, oft weil sie auf mehr Probleme gestoßen sind. Diese Ausreißer ziehen das arithmetische Mittel nach oben, sodass es nicht mehr die typische Zeit widerspiegelt.

Viele greifen deshalb zum Median. Sauro und Lewis haben 2010 auf der Konferenz CHI untersucht, ob das bei kleinen Stichproben die beste Wahl ist. Sie zogen per Simulation wiederholt Stichproben aus 61 Aufgaben mit großen Datensätzen und verglichen verschiedene Mittelwerte. Ergebnis: Der Median kleiner Stichproben überschätzt den tatsächlichen Median systematisch. Das geometrische Mittel hatte im Schnitt 13 Prozent weniger Fehler und 22 Prozent weniger Verzerrung als der Median. Ihre Empfehlung: Bei Stichproben unter 25 Personen das geometrische Mittel berichten. Bei größeren Stichproben schätzt auch der Median die Mitte gut.

Das geometrische Mittel klingt komplizierter, als es ist. Du logarithmierst alle Zeiten, bildest davon den Mittelwert und rechnest das Ergebnis mit der Exponentialfunktion zurück. In Excel oder Google Sheets geht das mit den Funktionen LN und EXP, oder direkt mit GEOMITTEL. Auch das Konfidenzintervall berechnest du auf den logarithmierten Werten und rechnest die Grenzen anschließend zurück.

Im Reisekosten-Beispiel haben die sieben erfolgreichen Personen in der ersten Fassung zwischen 225 und 560 Sekunden gebraucht. Das arithmetische Mittel liegt bei 327 Sekunden, der Median bei 290, das geometrische Mittel bei 313 Sekunden mit einem Konfidenzintervall von etwa 235 bis 416 Sekunden. Nach der Überarbeitung liegt das geometrische Mittel der elf erfolgreichen Personen bei 162 Sekunden, das Intervall bei etwa 123 bis 214 Sekunden. Hier überlappen sich die Intervalle nicht. Die Einreichung geht also sehr wahrscheinlich tatsächlich schneller.

Zwei praktische Hinweise noch. Erstens: Lege fest, welche Zeiten du einbeziehst. Am verbreitetsten ist, nur die Zeiten erfolgreicher Durchläufe zu berichten, so wie im Beispiel. Zweitens: Wenn du Zeiten misst, unterbrich Testpersonen nicht mitten in der Aufgabe mit Fragen. Laut Sauro verzerren Nachfragen während der Aufgabe die Zeit, Nachfragen im Anschluss liefern stabilere Werte.

Fehlerrate: wo genau es hakt

Fehler sind die dritte klassische Verhaltensmetrik und die diagnostisch wertvollste. Eine niedrige Erfolgsquote sagt dir, dass eine Aufgabe schwer ist. Die Fehler sagen dir, an welcher Stelle.

Sauro unterscheidet zwei Arten: Ausrutscher (englisch „slips“), bei denen das Ziel stimmt, aber die Ausführung nicht, etwa ein Tippfehler im Betrag. Und Irrtümer („mistakes“), bei denen schon das Ziel falsch ist, etwa wenn jemand die Hotelrechnung unter „Bewirtung“ statt unter „Übernachtung“ einträgt. Wie bei der Erfolgsquote gilt: Definiere vorher, was als Fehler zählt.

Am einfachsten zählst du binär, ob eine Person mindestens einen Fehler gemacht hat. Genauer ist die durchschnittliche Zahl der Fehler pro Aufgabe. Beziehst du Fehler auf die Zahl der Gelegenheiten, etwa der Eingabefelder, erhältst du eine Fehlerrate in Prozent.

Fehlerfreie Aufgaben sind übrigens die Ausnahme. In einer Auswertung von 719 Aufgaben, überwiegend aus Consumer- und Business-Software, fand Sauro im Schnitt 0,7 Fehler pro Aufgabe. Etwa zwei von drei Testpersonen machten mindestens einen Fehler, und nur 10 Prozent der Aufgaben waren komplett fehlerfrei. Wenn dein Test also Fehler zeigt, ist das normal. Interessant ist, wo sie sich häufen. Wie Formulare dazu beitragen, Fehler zu vermeiden, zeigt der Artikel Formulare, die niemand abbricht.

System Usability Scale: der Klassiker unter den Fragebögen

Die System Usability Scale (SUS) ist der wohl bekannteste Fragebogen zur wahrgenommenen Usability. John Brooke hat sie 1986 bei der Digital Equipment Corporation in Großbritannien entwickelt und 1996 als Kapitel mit dem Titel „SUS: A ‚quick and dirty‘ usability scale“ veröffentlicht. Der Name ist Programm: Die SUS sollte schnell auszufüllen und einfach auszuwerten sein.

Sie besteht aus zehn Aussagen, die abwechselnd positiv und negativ formuliert sind, etwa zur Frage, ob man das System gern häufiger nutzen würde oder ob man es unnötig komplex fand. Testpersonen bewerten jede Aussage auf einer Skala von 1 („stimme überhaupt nicht zu“) bis 5 („stimme voll zu“). Eingesetzt wird die SUS typischerweise am Ende einer Testsitzung, nicht nach jeder einzelnen Aufgabe.

So berechnest du den SUS-Wert

1. Bei den ungeraden Aussagen (1, 3, 5, 7, 9) ziehst du von der Antwort 1 ab.
2. Bei den geraden Aussagen (2, 4, 6, 8, 10) ziehst du die Antwort von 5 ab.
3. Du addierst die zehn Werte und multiplizierst die Summe mit 2,5.

Das Ergebnis liegt zwischen 0 und 100. Ein Beispiel: Jemand antwortet auf die zehn Aussagen der Reihe nach mit 4, 2, 4, 1, 4, 2, 5, 2, 4 und 2. Die ungeraden Aussagen ergeben 3, 3, 3, 4 und 3, also 16. Die geraden ergeben 3, 4, 3, 3 und 3, also ebenfalls 16. Die Summe von 32 mal 2,5 ergibt einen SUS-Wert von 80.

So liest du den SUS-Wert

Der häufigste Fehler bei der SUS: den Wert als Prozentzahl zu lesen. Ein SUS-Wert von 70 bedeutet nicht „70 Prozent gut“ und auch nicht, dass ein Produkt besser ist als 70 Prozent aller anderen. Sauro hat rund 500 Studien ausgewertet. Der Durchschnitt lag bei 68, was dem 50. Perzentil entspricht. Ein Wert von 74 liegt ungefähr beim 70. Perzentil, und für ein „A“ in Sauros Notenskala braucht es mehr als 80,3 Punkte. Für Stakeholder lohnt es sich deshalb, SUS-Werte in Perzentile zu übersetzen.

Im Reisekosten-Beispiel kommt die erste Fassung auf durchschnittlich 58 Punkte, mit einem Konfidenzintervall von etwa 53 bis 63. Die überarbeitete Fassung erreicht 74 Punkte, das Intervall liegt bei etwa 70 bis 78. Die erste Fassung lag also klar unter dem Durchschnitt, die überarbeitete liegt darüber. Laut Sauro ist die SUS auch bei kleinen Stichproben zuverlässig. Die Schätzung des wahren Werts wird dann aber ungenau, weshalb auch hier ein Konfidenzintervall dazugehört.

Single Ease Question: eine Frage nach jeder Aufgabe

Während die SUS das Gesamturteil erfasst, misst die Single Ease Question (SEQ) die Schwierigkeit einzelner Aufgaben. Nach jeder Aufgabe beantworten Testpersonen genau eine Frage, in der aktuellen Fassung von Sauro und Lewis sinngemäß: „Wie leicht oder schwer war es, diese Aufgabe zu erledigen?“ Die Skala hat sieben Stufen, von 1 („sehr schwer“) bis 7 („sehr leicht“).

Dass eine einzige Frage reicht, ist gut untersucht. Sauro und Joseph Dumas verglichen 2009 auf der CHI eine siebenstufige Fassung mit zwei aufwendigeren Verfahren. Die einfache Frage hielt mit der komplexeren Skala SMEQ mit und schnitt besser ab als die sogenannte Usability Magnitude Estimation.

Über mehr als 400 Aufgaben und 10.000 Testpersonen hinweg liegt der Durchschnitt laut Sauro zwischen etwa 5,3 und 5,6, also deutlich über der Skalenmitte von 4. Ein SEQ-Wert von 4,5 ist demnach eher schwach, auch wenn er auf den ersten Blick ordentlich klingt.

Sauros wichtigster Praxistipp: Frag kurz nach, wenn jemand einen Wert unter 5 vergibt. Die Begründung liefert sofort Hinweise auf das Problem. Im Reisekosten-Modul steigt der SEQ-Wert für die Belegaufgabe von 4,2 auf 5,9. Die Begründungen zur ersten Fassung drehen sich fast alle um dieselbe Stelle: Niemand findet, wie man einen Beleg einer bestehenden Reise zuordnet.

Wenn dich gezielt die geistige Beanspruchung interessiert, gibt es mit dem NASA Task Load Index (NASA-TLX) einen ausführlicheren Fragebogen. Wie er funktioniert und wann er sich lohnt, steht im Artikel Kognitive Last: Warum weniger im Interface oft mehr ist.

Vom Test ins Produkt: das HEART-Framework

Erfolgsquote, Zeit, SUS und SEQ stammen aus dem Usability-Test. Viele Teams wollen aber auch wissen, wie sich ein Produkt im laufenden Betrieb schlägt. Dafür haben Kerry Rodden, Hilary Hutchinson und Xin Fu von Google 2010 auf der CHI das HEART-Framework vorgestellt.

Ausgangspunkt war Kritik an verbreiteten Produktkennzahlen, die das Team PULSE nannte: Page views (Seitenaufrufe), Uptime (Verfügbarkeit), Latency (Ladezeit), Seven-day active users (aktive Nutzende der letzten sieben Tage) und Earnings (Umsatz). Diese Zahlen sind wichtig, messen Nutzungserfahrung aber nur indirekt. Das Team gibt ein Beispiel, das direkt auf das Reisekosten-Modul passt: Steigen die Seitenaufrufe einer Funktion, kann das heißen, dass sie beliebt ist. Es kann aber auch heißen, dass ein verwirrendes Interface Menschen herumirren lässt.

HEART steht für fünf Kategorien:

• Happiness: einstellungsbezogene Metriken wie Zufriedenheit, wahrgenommene Einfachheit oder Weiterempfehlung, meist per Umfrage erhoben.
• Engagement: wie intensiv Menschen ein Produkt nutzen, etwa Besuche pro Person und Woche. Das Team empfiehlt, solche Werte pro Person anzugeben statt als Gesamtzahl.
• Adoption: wie viele Menschen in einem Zeitraum neu mit einem Produkt oder einer Funktion beginnen.
• Retention: wie viele Menschen aus einem Zeitraum später noch dabei sind.
• Task success: die klassischen Verhaltensmetriken, also Effektivität, Effizienz und Fehlerrate, auch im großen Maßstab.

Nicht jede Kategorie passt zu jedem Produkt. Das Google-Team nennt ausdrücklich Software für den Arbeitsalltag als Beispiel, bei der Engagement wenig aussagt, weil Menschen sie ohnehin nutzen müssen. Genau das trifft auf das Reisekosten-Modul zu. Niemand soll dort möglichst viel Zeit verbringen.

Ziele, Signale, Metriken

Der vielleicht wertvollere Teil des Papers ist ein einfacher Prozess in drei Schritten. Zuerst legst du die Ziele fest: Was soll die Neugestaltung erreichen? Dann die Signale: Woran würdest du im Verhalten oder in den Einstellungen erkennen, dass das Ziel erreicht ist? Erst zum Schluss formulierst du konkrete Metriken. Zwei Hinweise des Teams sind besonders nützlich: Misserfolg ist oft leichter zu erkennen als Erfolg, etwa an abgebrochenen Aufgaben. Und absolute Zahlen steigen mit der Zahl der Nutzenden, deshalb sind Quoten und Werte pro Person meist aussagekräftiger.

Für das Reisekosten-Modul sieht das so aus:

• Task success: Ziel ist, dass Abrechnungen beim ersten Versuch korrekt sind. Signal: Die Buchhaltung muss weniger zurückschicken. Metrik: Anteil der Abrechnungen ohne Rückfrage pro Monat.
• Adoption: Ziel ist, dass Mitarbeitende Belege direkt mit dem Smartphone erfassen. Signal: Die Kamerafunktion wird genutzt. Metrik: Anteil der aktiven Mitarbeitenden, die im Monat mindestens einen Beleg per Foto hochladen.
• Retention: Ziel ist, dass das Fotografieren zur Gewohnheit wird. Metrik: Anteil derjenigen, die drei Monate später weiterhin Belege per Foto erfassen.
• Happiness: Ziel ist, dass die Abrechnung als einfach empfunden wird. Metrik: durchschnittlicher SEQ-Wert aus einer kurzen Frage direkt nach dem Einreichen.

Die Seitenaufrufe tauchen in dieser Liste nicht mehr auf. Die Support-Tickets dagegen werden zu einem nützlichen Signal für Task success.

Kleine Stichproben, ehrliche Zahlen

Wie viele Testpersonen brauchst du für belastbare Zahlen? Die Nielsen Norman Group empfiehlt in den meisten Fällen 40 Personen für quantitative Studien. Damit liegt die Fehlermarge einer Erfolgsquote bei einem Konfidenzniveau von 95 Prozent bei etwa 15 Prozentpunkten. Wer mit 90 Prozent Konfidenz leben kann, kommt laut NN/g mit weniger Personen aus. Für Zeitmessungen schätzt die NN/g bei gleicher Genauigkeit eher 47 Personen.

Messungen mit zwölf Personen sind trotzdem nicht wertlos. Sie zeigen große Unterschiede, wie bei der Bearbeitungszeit im Beispiel, aber keine kleinen. Entscheidend ist, die Unsicherheit offen zu berichten. Wer Konfidenzintervalle angibt, verhindert, dass ein Sprung von 68 auf 71 SUS-Punkte bei zehn Personen als Durchbruch gefeiert wird. Passende Tests für den Vergleich zweier Varianten beschreiben Sauro und Lewis in ihrem Buch „Quantifying the User Experience“. Wie du aus Tests auch ohne Statistik verwertbare Erkenntnisse ziehst, zeigt der Artikel Wie man wertvolles Feedback aus Usability-Tests extrahiert.

Typische Fallstricke

Eitelkeitsmetriken. Der Gründer Eric Ries beschrieb 2009 in einem viel zitierten Gastbeitrag sogenannte „vanity metrics“: Zahlen, bei denen man sich gut fühlt, die aber keine klare Richtung für das nächste Handeln geben. Sein Beispiel waren die Gesamtzugriffe auf eine Website. Auch Gesamtzahlen von Registrierungen oder Downloads sind typische Kandidaten. Sie steigen oft schon deshalb, weil ein Produkt wächst. Eine gute Metrik dagegen verändert eine Entscheidung, wenn sie sich ändert.

Äpfel mit Birnen vergleichen. Metriken sind nur innerhalb derselben Aufgabe vergleichbar. Wenn die Belegaufgabe einen SEQ-Wert von 5,9 erreicht und die Aufgabe „Kilometerpauschale für eine Fahrt mit dem Privatauto abrechnen“ nur 4,8, heißt das nicht, dass die zweite schlechter gestaltet ist. Sie kann einfach schwieriger sein, weil sie mehr Angaben verlangt. Dasselbe gilt für Zeiten aus verschiedenen Testformaten: Sauro weist darauf hin, dass Laborzeiten idealisiert sind und Remote-Zeiten durch Ablenkungen beeinflusst werden. Am aussagekräftigsten ist der Vergleich mit derselben Methode.

Die Messung zwischendurch ändern. Wer zwischen zwei Testrunden die Aufgabenformulierung, das Erfolgskriterium oder die Fragebogenversion ändert, vergleicht am Ende nicht mehr die Designs, sondern die Messungen. Halte Aufgaben, Kriterien und Fragebögen über Runden hinweg stabil und dokumentiere sie.

Messen ohne Ziel. Ein Dashboard mit 40 Kennzahlen hilft niemandem. Der HEART-Prozess beginnt nicht zufällig mit den Zielen. Wenn du nicht sagen kannst, welche Entscheidung von einer Zahl abhängt, brauchst du sie wahrscheinlich nicht.

Fazit

UX lässt sich messen, und zwar mit überschaubarem Aufwand. Die Erfolgsquote sagt dir, ob Menschen ihr Ziel erreichen. Die Bearbeitungszeit, berichtet als geometrisches Mittel bei kleinen Stichproben, zeigt, wie effizient das geht. Fehler zeigen, wo es hakt. SUS und SEQ ergänzen das Bild um die Sicht der Menschen selbst. Und HEART hilft dir, aus diesen Ideen Kennzahlen für das laufende Produkt abzuleiten, ausgehend von Zielen statt von verfügbaren Daten.

Das Team mit dem Reisekosten-Modul kann seine Frage inzwischen beantworten. Die gestiegenen Seitenaufrufe waren kein Erfolg, sondern ein Warnsignal: Viele Menschen suchten in der ersten Fassung nach der Zuordnung zur Reise. Nach der Überarbeitung ist die Erfolgsquote deutlich gestiegen, die Einreichung dauert im Mittel knapp drei statt gut fünf Minuten, und der SUS-Wert liegt über dem Durchschnitt. Ob auch die Buchhaltung weniger Abrechnungen zurückschickt, zeigt jetzt eine Kennzahl auf dem Dashboard. Ohne die richtigen Metriken hätte das Team die falsche Zahl gefeiert.

Checkliste

• Für jede Messung ist klar, welche Entscheidung davon abhängt.
• Verhaltens- und Einstellungsmetriken werden kombiniert.
• Aufgaben und Erfolgskriterien sind vor dem Test schriftlich festgelegt.
• Erfolgsquoten werden mit Konfidenzintervall berichtet, bei kleinen Stichproben mit dem angepassten Wald-Intervall.
• Bearbeitungszeiten werden bei weniger als 25 Personen als geometrisches Mittel berichtet, nicht als arithmetisches Mittel.
• Es ist festgelegt, ob Zeiten nur für erfolgreiche Durchläufe zählen.
• Was als Fehler zählt, ist definiert, und Fehler werden ihrer Stelle im Ablauf zugeordnet.
• Die SUS wird am Ende der Sitzung erhoben, korrekt berechnet und als Perzentil statt als Prozent erklärt.
• Die SEQ folgt direkt auf jede Aufgabe, und bei Werten unter 5 wird nach dem Grund gefragt.
• Vergleiche finden nur innerhalb derselben Aufgabe und mit derselben Methode statt.
• Produktmetriken sind über Ziele, Signale und Metriken abgeleitet, nicht aus vorhandenen Dashboards übernommen.
• Gesamtzahlen werden durch Quoten oder Werte pro Person ersetzt.

Quellen

• Christian Rohrer, Nielsen Norman Group (2022): When to Use Which User-Experience Research Methods
• Jeff Sauro, MeasuringU (2011): What Is A Good Task-Completion Rate?
• Jeff Sauro, MeasuringU: Confidence Interval Calculator for a Completion Rate
• Jeff Sauro und James R. Lewis (2010): Average Task Times in Usability Tests: What to Report? Proceedings of CHI 2010, 2347 bis 2350
• Jeff Sauro, MeasuringU (2011): 10 Things To Know About Task Times
• Jeff Sauro, MeasuringU (2012): Measuring Errors in the User Experience
• Jeff Sauro, MeasuringU (2012): 10 Benchmarks for User Experience Metrics
• John Brooke (1996): SUS: A „quick and dirty“ usability scale. In: P. W. Jordan u. a. (Hrsg.): Usability Evaluation in Industry. Taylor & Francis
• Jeff Sauro, MeasuringU (2011): Measuring Usability with the System Usability Scale (SUS)
• Jeff Sauro, MeasuringU (2012): 10 Things To Know About The Single Ease Question (SEQ)
• Jeff Sauro und Jim Lewis, MeasuringU (2024): The Evolution of the Single Ease Question (SEQ)
• Jeff Sauro und Joseph S. Dumas (2009): Comparison of Three One-Question, Post-Task Usability Questionnaires. Proceedings of CHI 2009, 1599 bis 1608
• Kerry Rodden, Hilary Hutchinson und Xin Fu (2010): Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications. Proceedings of CHI 2010, 2395 bis 2398
• Raluca Budiu und Kate Moran, Nielsen Norman Group (2021): How Many Participants for Quantitative Usability Studies: A Summary of Sample-Size Recommendations
• Eric Ries (2009): Vanity Metrics vs. Actionable Metrics. Gastbeitrag im Blog von Tim Ferriss
• Jeff Sauro und James R. Lewis (2016): Standardized Usability Questionnaires. In: Quantifying the User Experience, 2. Auflage. Morgan Kaufmann (Elsevier), 185 bis 248