Zum Inhalt springen

Time on Task

Männliche Person, frontal, schaut in die Kamera; trägt kariertes Hemd über dunkelfarbigem T‑Shirt; heller Innenraum mit unscharfem Monitor oder Poster links und Fenster rechts.

von Richard Albrecht am 24.09.2026

Time on Task ist die Zeit, die eine Testperson von der Aufgabenstellung bis zur letzten Handlung für eine Aufgabe benötigt, notiert in Sekunden. Die Zahl allein ist zweideutig. Beim Ausfüllen eines Formulars spricht eine kurze Zeit für das Interface, beim Lesen eines Fachartikels oder beim Stöbern in einem Shop gegen ihn. Ohne die Absicht hinter der Aufgabe lässt sich der Wert nicht deuten.

Time on Task

Zeit, die eine Testperson von der Aufgabenstellung bis zur letzten Handlung für eine Aufgabe benötigt.
Beispiel: „Die Time on Task für die Bestellung sank von 4:10 auf 2:35 Minuten.“

Auch: Bearbeitungszeit, Task Time. Sie gilt als Maß für Effizienz und wird fast immer zusammen mit der Task Success Rate berichtet, weil eine Zeit ohne Ergebnis nichts wert ist.

Häufige Verwechslung: Die Verweildauer aus der Webanalyse misst die Zeit auf einer Seite, ohne zu wissen, welche Aufgabe jemand dort verfolgt. Sie ist keine Time on Task.

Wie gestoppt wird

Die Messung beginnt, wenn die Testperson das Aufgabenszenario fertig gelesen hat, und endet, wenn alle Handlungen abgeschlossen sind, das Prüfen des Ergebnisses eingeschlossen. Diese Konvention beschreibt Jeff Sauro von MeasuringU. Wer sie mitten in einer Testreihe ändert, kann zwei Messungen nicht mehr vergleichen.

Für die Auswertung eignet sich der Median besser als der Mittelwert: Einzelne Teilnehmer brauchen ein Vielfaches der übrigen Zeit und ziehen jeden Durchschnitt nach oben. Abgebrochene Aufgaben werden getrennt ausgewiesen, weil ein schnelles Aufgeben sonst wie Tempo aussieht.

Kurz ist nur manchmal gut

Ob eine kurze Zeit für das Interface spricht, hängt an der Absicht. Aufgaben mit Erledigungscharakter, etwa ein Kontaktformular oder ein Bezahlvorgang, sollen schnell vorbei sein. Bei Aufgaben mit Erkundungscharakter, etwa der Auswahl aus einem Sortiment, steht eine längere Zeit für Interesse, und ein plötzlicher Rückgang ist ein Warnsignal.

Ein zweiter Fall ist die Erlernbarkeit. Die Bearbeitungszeit sinkt mit jeder Wiederholung derselben Aufgabe, was als Learnability untersucht wird. Die Zeit aus einem Erstkontakt taugt deshalb nicht als Vergleich zu der eines geübten Nutzers.

Woran du die Zahl im Projekt festmachst

Vor der Messung wird je Aufgabe notiert, in welche Richtung die Zeit gedeutet werden soll. Fehlt diese Festlegung, wird jede Veränderung hinterher passend erklärt. Wir formulieren die Aufgaben außerdem so, dass sie ein Ziel nennen und keinen Weg vorgeben: „Finde heraus, wann der Laden am Samstag öffnet“ statt „Klicke auf Kontakt“.

Verglichen wird gegen einen eigenen Ausgangswert von derselben Website. Fremde Vergleichszahlen helfen kaum, weil Aufgabenzuschnitt und Formulierung das Ergebnis stark beeinflussen.

Siehe auch:

UX-KPIs

Messgrößen, mit denen sich die Qualität einer Benutzererfahrung über die Zeit vergleichbar beobachten lässt.

#Benutzererfahrung (UX)

Task Success Rate

Anteil der Testpersonen, die eine vorgegebene Aufgabe zu Ende bringen, gemessen an allen, die es versucht haben.

#Benutzererfahrung (UX)

Doherty Threshold

Antwortzeit von 400 Millisekunden, unterhalb der Nutzer und System ohne merkliche Wartezeit zusammenarbeiten.

#Benutzererfahrung (UX)

Cognitive Load

Geistige Anstrengung, die eine Oberfläche einem Besucher in dem Moment abverlangt, in dem er eine Aufgabe erledigt.

#Benutzererfahrung (UX)