Die Doherty-Schwelle (Doherty threshold)

Kurz gesagt

Drückt ein Nutzer einen Button, muss auf dem Screen sofort etwas passieren. Auch wenn das Ergebnis noch nicht fertig ist, muss eine Reaktion kommen. Die Doherty-Schwelle gibt für dieses „sofort“ eine Zahl: 400 ms.

Die zweite Hälfte ist die wahrgenommene Geschwindigkeit. Können Sie die echte Zeit nicht verkürzen, können Sie das Warten kürzer wirken lassen. Der Skeleton Screen ist eines der Werkzeuge dafür.

Wählen Sie in der Demo unten Verzögerung und Indikator selbst. Den Unterschied zwischen 300 ms und 2.500 ms spüren Sie nach wenigen Versuchen.

Live-Demo: Sie wählen die Verzögerung

Stellen Sie die Verzögerung mit dem Schieberegler zwischen 0 und 3.000 ms ein. Wählen Sie dann, was beim Warten zu sehen ist, und drücken Sie Laden. Der Ergebniskasten nennt die vergangene Zeit und die Grenze, in die sie fällt.

Verzögerungsexperiment

Diese Demo braucht JavaScript. Ist es aus, sehen Sie unten nur den geladenen Inhalt; der Text erklärt dieselbe Idee.

Meine Bestellungen

• Kabellose KopfhörerUnterwegs
• SportschuheZugestellt
• BuchsetIn Vorbereitung

Die Verzögerung ist keine echte Netzwerkanfrage, sondern ein Timer, der so lange wartet wie gewählt. Die Bewertung der Zeit beruht auf Nielsens Grenzen, die Hinweise zum Indikator auf dem NN/g-Artikel zu Skeleton Screens. Diese Zuordnung stammt von mir. Weil NN/g schreibt, dass schimmernde Skeleton-Animationen ablenken können, ist das Skeleton statisch. Ist reduzierte Bewegung eingestellt, dreht sich der Spinner nicht, und der Fortschrittsbalken füllt sich in Schritten von 10 %.

Ich empfehle vor allem, bei 2.000 ms auf den Unterschied zwischen „Kein Indikator“ und „Skeleton Screen“ zu achten. Die Zeit ist gleich, aber das Warten vor einer leeren Karte wirkt länger.

Herkunft: Doherty und Thadani, 1982

Laut Laws of UX veröffentlichten Walter J. Doherty und Ahrvind J. Thadani 1982 einen Aufsatz im IBM Systems Journal. Der Aufsatz setzte für die Antwortzeit des Computers ein Ziel von 400 ms.

Laut derselben Quelle lag der bisherige Maßstab bei 2.000 ms, also 2 Sekunden. Laws of UX schreibt, dass Anwendungen, die unter 400 ms antworten, Nutzer geradezu süchtig machten.

Den Aufsatz selbst konnte ich nicht öffnen und lesen. Deshalb nenne ich die Zahl 400 ms und die Quellenangabe so, wie Laws of UX sie wiedergibt. Nutzen Sie die Zahl auch im Team als Zielwert.

Nielsens drei Grenzen: 0,1, 1 und 10 Sekunden

Ein weiterer bekannter Rahmen für Antwortzeiten stammt von Jakob Nielsen. Nielsen schrieb diese Grenzen 1993 in Kapitel 5 seines Buchs Usability Engineering. In einer Notiz von 2014 sagte er, dass dieselben Grenzen auch für Webanwendungen gelten.

1. 0,1 sSofortNielsen: Der Nutzer spürt, dass das System sofort reagiert. Es reicht, das Ergebnis zu zeigen.
2. 0,4 sDoherty-SchwelleLaws of UX: Kommt die Rückmeldung in dieser Zeit, bleibt die Aufmerksamkeit erhalten, die Produktivität steigt.
3. 1 sGrenze des GedankenflussesNielsen: Der Gedankenfluss reißt nicht ab. Darüber braucht es ein Zeichen, dass gearbeitet wird.
4. 10 sGrenze der AufmerksamkeitNielsen: Beim Warten will der Nutzer zu anderen Aufgaben wechseln. Es braucht eine Prozentanzeige und einen Weg zum Abbrechen.

Abbildung: Nielsens drei Grenzen und die Doherty-Schwelle dazwischen. Die Skala ist nicht gleichmäßig.

0,1 Sekunden: Der Nutzer spürt, dass das System sofort reagiert. Laut der Notiz von 2014 fühlt er sich in dieser Zeit, als steuere er die Objekte der Oberfläche direkt selbst.

1 Sekunde: Der Nutzer bemerkt die Verzögerung, aber sein Gedanke reißt nicht ab. Laut Nielsens Notiz von 2014 sollten Sie zeigen, dass der Computer arbeitet, wenn die Verzögerung 1 Sekunde überschreitet.

10 Sekunden: Bis zu dieser Zeit bleibt die Aufmerksamkeit des Nutzers beim Screen. Zeigen Sie bei längeren Aufgaben, wann der Computer voraussichtlich fertig ist. Geben Sie dem Nutzer außerdem einen Weg, die Aufgabe abzubrechen.

Die Doherty-Schwelle liegt in diesem Rahmen zwischen 0,1 und 1 Sekunde. Ich verbinde beides so: eine Reaktion innerhalb von 400 ms und ein Indikator, sobald 1 Sekunde überschritten ist.

Wahrgenommene Geschwindigkeit und Skeleton Screen

Wahrgenommene Geschwindigkeit ist, wie lang der Nutzer das Warten empfindet, und sie deckt sich nicht immer mit der Uhr. Der erste Weg, diese Lücke zu schließen, ist, den Systemstatus zu zeigen. Das ist Nielsens erste Heuristik, die Sichtbarkeit des Systemstatus.

Laut dem NN/g-Artikel von 2023 ist ein Skeleton Screen ein Entwurf der Seite, ähnlich einem Wireframe. Er wird nur beim Laden ganzer Seiten genutzt und ahmt mit hellgrauen Kästen das Layout der Seite nach. Der Artikel schreibt, dass er die wahrgenommene Ladezeit verkürzt.

Derselbe Artikel ordnet auch, welcher Indikator wann passt:

Wartezeit	Was gezeigt wird
Unter 1 Sekunde	Nichts. Ein schnell aufblitzender Screen kann das Gefühl geben, nicht mitzukommen.
2 bis 10 Sekunden, ein Element	Spinner, etwa für ein einzelnes Video oder eine Dashboard-Karte.
Unter 10 Sekunden, ganze Seite	Skeleton Screen.
Über 10 Sekunden	Fortschrittsbalken und eine klare Zeitschätzung.
Hochladen, Herunterladen, Umwandeln von Dateien	Fortschrittsbalken. Ein Skeleton Screen passt hier nicht.

NN/g fügt zwei Warnungen hinzu. Schimmernde oder pulsierende Skeleton-Animationen können ablenken und Barrierefreiheitsprobleme verursachen. Ein leerer Rahmen, der nur Kopf, Fuß und Hintergrund zeigt, unterscheidet sich nicht von einem Spinner.

Die wichtigste Warnung des Artikels ist für mich diese: Ein Skeleton Screen ersetzt keine Verbesserung der Performance. Die Seite lädt genauso schnell, das Skeleton macht nur das Warten leichter.

400 ms in der Oberfläche erreichen

Auch wenn die Antwort des Servers über 400 ms liegt, muss die Reaktion der Oberfläche das nicht. Reaktion und Ergebnis sind zwei Dinge. Beim Prüfen von Screens messe ich beides getrennt.

Der gedrückte Button ändert sich sofort. Drückt man in einer Banking-App auf „Senden“, sollte der Button in den gedrückten Zustand wechseln und „Wird gesendet“ zeigen. Auch wenn das Ergebnis ein paar Sekunden dauert, weiß der Nutzer, dass die Anfrage angekommen ist.

Zeigen Sie bei Aufgaben mit geringem Risiko das Ergebnis vorab. In einem Onlineshop kann sich das Herz eines gemerkten Produkts sofort füllen. Scheitert die Anfrage, leert sich das Herz wieder, und eine kurze Meldung erscheint. Bei einer Überweisung mache ich das nicht, dort warte ich auf das echte Ergebnis.

Leeren Sie den Screen auch nicht, während eine Liste aktualisiert wird. Lassen Sie die alten Zeilen stehen und zeigen Sie oben ein kleines Zeichen für die Aktualisierung, dann liest der Nutzer weiter.

Meine Notiz

Der häufigste Fehler in meinen Audits: Beim Drücken eines Buttons ändert sich nichts. Der Nutzer drückt erneut, und dieselbe Zahlung oder dasselbe Formular geht zweimal raus. Dass der Button sofort in den gedrückten Zustand wechselt und sich nicht erneut drücken lässt, löst das meist.

Auf Platz zwei steht die Gewohnheit, jede Ladung mit einem Spinner zu versehen. Ein Ring, der bei einem Filter von 300 ms kurz aufblitzt, lässt die Arbeit langsamer wirken, als sie ist. Bei Aufgaben unter 1 Sekunde entferne ich den Indikator.

Dazu kommt ein Skeleton Screen, der nicht zum echten Inhalt passt. Ein Skeleton mit drei Zeilen erscheint, dann lädt eine einzige Zeile, und die Seite springt. Das Skeleton mit den Maßen der echten Komponenten zu zeichnen, verhindert das. Ich lege es als Komponente im Designsystem an.

Wenn Sie Wartemomente und Rückmeldungen Ihres Produkts zusammen verbessern wollen: Der Design & Ship Sprint liefert Design und Code zusammen. Wollen Sie zuerst die Probleme sehen, beginnen Sie mit dem UX Audit.

Verwandte Seiten

Der leere Screen hat auch einen dauerhaften Zustand. Den Screen ohne Daten beschreibe ich im Muster leerer Zustand. Zur Ladereihenfolge auf Screens voller Karten siehe das Muster Dashboard.

Die übrigen Gesetze stehen in der Liste der UX-Gesetze. Für Größe und Position von Zielen ist das Fittssche Gesetz ein guter nächster Schritt. Wie man Antwortzeiten im Web misst, steht im Ratgeber zu Core Web Vitals.