Time-on-Task

Definition: Time-on-Task (auch: Task-Time; Task-Duration; Zeit pro Aufgabe) ist eine UX-Effizienz-Metrik die misst wie lange ein Nutzer benötigt um eine definierte Aufgabe erfolgreich abzuschließen – gemessen von der Aufgaben-Präsentation bis zum korrekten Aufgabenabschluss. Time-on-Task ist die primäre Operationalisierung von Effizienz in der ISO-9241-11-Usability-Definition (Effizienz = Ressourcenaufwand für Zielerreichung). Messung: Startpunkt = Moment der Aufgaben-Präsentation (Proband liest Aufgabe); Endpunkt = korrekter Aufgabenabschluss (klar definiertes Erfolgs-Kriterium); Einheit: Sekunden (für kurze Tasks) oder Minuten; nur erfolgreiche Aufgaben-Trials werden gemessen (gescheiterte Trials werden exkludiert um Verzerrung durch Frustrations-Searches zu vermeiden); Ausnahme: gesonderte Analyse von «Zeit bis Abbruch» bei Misserfolgen als separate Metrik. Statistische Eigenschaften: Time-on-Task-Daten sind typischerweise rechtsschief (long-tail) und log-normalverteilt (viele schnelle Nutzer; wenige sehr langsame); deshalb: geometrischer Mittelwert bevorzugt gegenüber arithmetischem Mittelwert; oder: Log-Transformation vor statistischer Analyse; Median als robuste Alternative bei kleinen Stichproben; Ausreißer-Behandlung: Werte > 3× Median als potenzielle Ausreißer identifizieren; Ursachen prüfen (technische Probleme; Aufgaben-Missverständnis; Ablenkung); mit Begründung exkludieren; Praxisgrenze oft: Aufgaben-Zeit-Limit von 2–3× erwartete Zeit als Abbruch-Kriterium.

Erläuterung

Tom Tullis (Fidelity Investments; Boston; MA; Fidelity Center for Applied Technology) und Bill Albert (Bentley University; Waltham; MA) systematisierten Time-on-Task als Kern-UX-Metrik in «Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics» (Morgan Kaufmann; 2008; dritte Auflage 2023): Tullis und Albert behandelten die statistische Komplexität von Time-on-Task ausführlich – sie zeigten dass arithmetischer Mittelwert durch Ausreißer stark verzerrt wird und empfahlen entweder geometrischen Mittelwert oder Median; darüber hinaus diskutierten sie die Entscheidung ob gescheiterte Trials in die Analyse einbezogen werden sollen (Tullis/Albert-Empfehlung: exkludieren für reine Effizienz-Messung; für vollständiges Bild gesonderte Analyse). Nigel Bevan (National Physical Laboratory; Teddington; UK; ISO/IEC-Standards-Beiträge) und die ISO 9241-11 Arbeitsgruppe definierten Effizienz als zweite Usability-Dimension neben Effektivität und Zufriedenheit: die normative Definition von Effizienz ist «Ressourcenaufwand für die Zielerreichung» – Zeit ist die wichtigste Ressource; Errors (Fehler) und Cognitive Load sind weitere Effizienz-Indikatoren; das vollständige Effizienz-Bild entsteht erst aus Kombination von Task-Time und Fehlerrate. Jeff Sauro (MeasuringU; Denver; CO; statistischer UX-Metriken-Experte; measuringu.com) analysierte Time-on-Task-Benchmark-Daten in mehreren veröffentlichten Analysen: Log-Transformation vor parametrischen Tests (t-Test, ANOVA) auf Time-on-Task-Daten erhöht statistische Power erheblich; für Vorher/Nachher-Vergleich (gleiche Nutzer): gepaarter t-Test auf log-transformierten Daten; für Zwischen-Gruppen-Vergleich: ungepaarter t-Test oder Mann-Whitney-U auf log-transformierten Daten; Konfidenzintervall um geometrischen Mittelwert: exponenzieren der Konfidenzintervall-Grenzen der log-transformierten Daten; Sauro dokumentierte auch den Effekt von Think-Aloud-Verbalisierung auf Task-Time: CTA-Probanden brauchen konsistent 5–15% länger als stille Nutzer; Time-on-Task-Werte aus Think-Aloud-Tests nicht direkt mit Silent-Performance-Benchmarks vergleichen. Paul Fitts (Ohio State University; Columbus; OH; «The Information Capacity of the Human Motor System in Controlling the Amplitude of Movement», Journal of Experimental Psychology, 1954) und der Keystroke-Level-Model (KLM; Card/Moran/Newell; «The Psychology of Human-Computer Interaction», Lawrence Erlbaum Associates, 1983) lieferten die theoretischen Grundlagen für kognitive Effizienz-Modellierung: KLM sagt Task-Time durch Summe von Keystroke- und Pointing-Zeit voraus; nützlich für Vergleich von Design-Alternativen ohne Nutzertest; als Design-Tool ergänzend zu empirischer Time-on-Task-Messung. Card/Moran/Newell (Xerox PARC; Palo Alto; CA) entwickelten das GOMS-Modell (Goals, Operators, Methods, Selection Rules; «The Psychology of Human-Computer Interaction») als weiteres Task-Time-Vorhersage-Framework: GOMS zerlegt eine Aufgabe in Ziele, mentale Operatoren, Methoden und Auswahlregeln; prädiktive Effizienz-Analyse; häufig für Enterprise-Software-Optimierung genutzt wo direkte Usability-Tests mit großen Nutzerzahlen nicht praktikabel sind.

Messung, Auswertung und Benchmarks

Time-on-Task-Messung in Usability-Tests: Technische Messung: Moderierter Test: Stoppuhr (manuell; einfach; ausreichend für kleine Tests); Morae (TechSmith; Okemos; MI; Usability-Test-Software; automatische Clip-Tagging und Zeitstempel); Lookback.io; UserZoom (automatisches Task-Timing bei Online-Plattformen); Unmoderierter Remote-Test: Maze, UserTesting.com, Optimal Workshop – automatisches Task-Timing ab Aufgaben-Präsentation bis korrekter Antwort oder Submit; Startpunkt-Konsistenz: Zeitnahme startet konsistent entweder nach dem Lesen der Aufgabe (Proband sagt «Bereit»; Moderator drückt Stopuhr) oder nach dem ersten Klick (einfacher automatisch messbar); innerhalb einer Studie einheitliche Definition verwenden; Endpunkt-Konsistenz: klar definiertes Erfolgs-Kriterium; ohne vorab definiertes Kriterium subjektiv und zwischen Moderatoren inkonsistent; Ausreißer-Analyse: bei n=10 Test-Teilnehmern: Median als robuste Schätzung; bei n=5: Einzelwerte beschriften und erklären; Ausreißer-Schwelle: Tullis/Albert empfehlen 3× Median als Ausreißer-Grenze; Jeff Sauro: alle Daten darstellen und Ausreißer separat dokumentieren (selten echte Ausreißer; oft technische Probleme)
Geometrischer Mittelwert vs. arithmetischer Mittelwert: Problem mit arithmetischem Mittelwert: Beispiel 5 Probanden: 45s, 60s, 55s, 70s, 340s → Arithmetisches Mittel = 114s (stark durch Ausreißer verzerrt); Median = 60s; geometrisches Mittel = exp((ln45+ln60+ln55+ln70+ln340)/5) = exp(4,40) = 81s; Geometrischer Mittelwert ist Standardempfehlung für Time-on-Task (Sauro/Lewis; Quantifying the User Experience 2012): spiegelt «typical» Nutzer besser als arithmetisches Mittel; stellt die log-normalen Eigenschaften korrekt dar; Berechnung: (1) Log-Transformation aller Werte: ln(Zeit); (2) Arithmetisches Mittel der log-transformierten Werte; (3) exp() der Mittelwerts; oder: n-te Wurzel des Produkts aller Werte; Excel: =EXP(MITTELWERT(LN(A1:A10))); statistischer Vergleich: für Vorher/Nachher: gepaarten t-Test auf log-transformierten Werten; Ergebnis: Ratio (z.B. 0,78 = 22% schneller); für Gruppen-Vergleich: Welch's t-Test auf log-Werten; statistisch signifikant wenn t-Test p < 0,05 mit n ≥ 20
Branchenbenchmarks und Interpretation: Benchmark-Problem: Task-Time ist stark aufgaben-spezifisch; absolute Werte kaum vergleichbar; sinnvoll: Vergleich eigene Version A vs. B; oder gleiche Aufgabe vor/nach Redesign; relative Verbesserung: Redesign führte zu 28% kürzerer Task-Time → klarer Effizienz-Gewinn; Jeff Sauro (measuringu.com; 2014): mediane Task-Zeit aus 100+ Usability-Tests: einfache Navigationstask: ~60–90 Sekunden; Checkout-Prozess: ~3–5 Minuten; Informations-Suche: ~45–120 Sekunden; stark aufgaben-abhängig; Kontext-Interpretation: kurze Task-Time = nicht immer gut; wenn Nutzer Aufgabe abkürzt aber wichtige Inhalte übersieht (schlecht); wenn Aufgabe effizient abgeschlossen (gut); hohe Task-Time = nicht immer schlecht; wenn aufgabe komplex und Nutzer gründlich (ok); wenn Nutzer desorientiert (schlecht); immer kombinieren mit Task-Completion-Rate: hohe TCR + kurze Zeit = exzellent; hohe TCR + lange Zeit = effektiv aber ineffizient; niedrige TCR + kurze Zeit = Nutzer brechen früh ab; Effizienz-Ratio: Task-Completion-Rate / Durchschnittliche-Task-Time = normierte Effizienz-Metrik für Vergleiche

Analytics-basierte Time-on-Task und Kombinations-Metriken

Indirekte Time-on-Task aus Analytics: Seitenaufenthaltszeit vs. Time-on-Task: Google Analytics «Time on Page» misst Zeit zwischen Seitenaufruf und nächstem Seitenaufruf (keine Aktivität auf letzter Seite wird nicht gemessen); nicht direkt vergleichbar mit Test-Time-on-Task; aber: Funnel-Zeit (Checkout: Zeit von Step 1 bis Bestellung abgeschlossen) als Proxy-Metrik für Task-Completion-Zeit; Session-Recording-Tools (FullStory; Hotjar): Replay-Analyse von Sessions um typische Aufgabenzeiten zu verstehen; Muster: wo passieren lange Pausen (Orientierungsverlust)? wo Scrolling ohne Klick (Content nicht hilfreich)? Checkout-Abandon-Zeitpunkte: wann im Zeitverlauf brechen Nutzer den Checkout ab? frühzeitiger Abbruch = Verwirrung; später Abbruch = unerwartete Kosten oder Vertrauen; Core Web Vitals als System-Performance-Proxy: Largest Contentful Paint (LCP < 2,5s); First Input Delay (FID < 100ms); Cumulative Layout Shift (CLS < 0,1); langsame Ladezeiten erhöhen effective Time-on-Task durch unverschuldete Wartezeit; Task-Time ohne Ladezeiten bereinigen in Tests wenn Server-Performance nicht Untersuchungsgegenstand ist

Praxistipp: Nutzen Sie Time-on-Task primär für Vorher/Nachher-Vergleiche – nicht für absolute Benchmarks. Ein Redesign das Task-Completion-Rate um 10% erhöht und Task-Time um 20% reduziert ist ein klarer Erfolg. Merken Sie sich die Faustregel für die Auswertung: Berechnen Sie immer den geometrischen Mittelwert (=EXP(MITTELWERT(LN(A1:A10))) in Excel), nicht den arithmetischen Mittelwert – ein einziger Ausreißer von 5 Minuten unter 9 schnellen Probanden verdreifacht sonst den arithmetischen Mittelwert und verzerrt Ihre Analyse. Und exkludieren Sie gescheiterte Trials aus der Zeit-Analyse: ein Nutzer der 10 Minuten braucht weil er die Aufgabe nicht findet und aufgibt misst etwas anderes als Effizienz – das ist ein Task-Completion-Problem.