Die vergessenen Screens: Empty States, Ladezustände und Fehlerseiten

Im Designprozess bekommt fast jeder Screen seinen großen Auftritt. Das Dashboard mit hübschen Diagrammen, die Liste mit zwanzig sauber formatierten Einträgen, die Detailseite mit allen Daten. Im Prototyp ist immer alles da, immer schnell und immer fehlerfrei.

Die Realität sieht anders aus. Wer ein neues Tool zum ersten Mal öffnet, hat noch keine Daten. Wer sucht, findet manchmal nichts. Das Netz im Zug bricht ab, der Server antwortet nicht, ein alter Link führt ins Leere. Genau in diesen Momenten entscheidet sich, ob Menschen weitermachen oder aufgeben. Und genau diese Screens werden oft erst kurz vor dem Launch gestaltet, oder gar nicht, und dann füllt die Entwicklung sie mit einem grauen „Keine Daten“ und einem Standard-Spinner.

Dieser Artikel nimmt sich die drei großen Gruppen dieser vergessenen Screens vor: leere Zustände (Empty States), Ladezustände und Fehlerseiten. Damit es konkret bleibt, begleitet ein Beispiel den ganzen Text: ein Rechnungstool für Selbstständige. Es gibt dort eine Rechnungsliste, eine Kundenverwaltung, eine Suche, einen CSV-Import für Kontoauszüge und ein Dashboard mit Umsätzen. In der Ausgangsversion zeigt die leere Rechnungsliste nur eine Tabellenüberschrift ohne Zeilen, beim Laden dreht sich überall derselbe Spinner, und Fehler enden mit „Etwas ist schiefgelaufen“.

Warum diese Zustände so oft vergessen werden

Designteams arbeiten meist mit dem sogenannten Happy Path, also dem Weg, auf dem alles klappt. Mockups enthalten realistische, aber volle Beispieldaten. Für den Moment, in dem eine Liste leer ist oder eine Anfrage scheitert, gibt es im Design-File selten einen eigenen Frame.

Dazu kommt ein Wahrnehmungsproblem: Leere Zustände, Ladezustände und Fehler gelten als Ausnahme. Dabei sind sie es nicht. Jede neue Person sieht zuerst leere Listen. Jede Seite lädt, mal kürzer, mal länger. Und jede Anwendung hat Fehler, die Frage ist nur, wie sie sich zeigen.

Eine einfache Gegenmaßnahme ist, für jeden wichtigen Screen von Anfang an vier Zustände zu skizzieren: voll, leer, ladend und fehlerhaft. Wer das im Wireframe schon mitdenkt, spart sich später hektische Notlösungen. Im Rechnungstool heißt das zum Beispiel: Die Rechnungsliste bekommt vier Frames statt einem.

Empty States: Leere ist eine Gelegenheit

Ein Empty State ist der Zustand eines Screens, in dem es (noch) keine Inhalte gibt. Die Nielsen Norman Group (NN/g) beschreibt drei Aufgaben, die ein guter Empty State übernehmen kann: Er kommuniziert den Status des Systems, er hilft Menschen, das Produkt zu verstehen, und er bietet einen direkten Weg zu den wichtigsten Aufgaben. Ein leerer Bildschirm mit „Keine Einträge“ erfüllt keine dieser Aufgaben.

Wichtig ist, dass „leer“ nicht gleich „leer“ ist. Je nach Ursache braucht der Screen eine andere Botschaft.

Erste Nutzung: Wenn noch nichts da ist

Der häufigste Fall: Jemand hat sich gerade registriert und öffnet zum ersten Mal die Rechnungsliste. Hier ist der Empty State ein Teil des Onboardings, also der Einführung in das Produkt. Er sollte drei Fragen beantworten: Was gehört hierhin? Warum ist es leer? Und was ist der erste Schritt?

Vorher: Eine leere Tabelle mit den Spalten „Nr.“, „Kunde“, „Betrag“, „Status“ und darunter der Text „Keine Daten vorhanden“.

Nachher: „Hier erscheinen deine Rechnungen. Du hast noch keine erstellt. Leg deine erste Rechnung an, das dauert etwa zwei Minuten.“ Darunter ein Button „Erste Rechnung erstellen“ und ein Textlink „Bestehende Rechnungen importieren“.

Der Unterschied liegt nicht im Design, sondern in der Haltung. Die Vorher-Version beschreibt den Zustand der Datenbank. Die Nachher-Version beschreibt, was die Person als Nächstes tun kann. Solche kurzen, handlungsleitenden Texte nennt man Microcopy.

Ein paar Gestaltungsregeln für den ersten Empty State:

• Genau eine Hauptaktion. Zwei oder drei gleichwertige Buttons nebeneinander verschieben die Entscheidung nur zurück zur Person.
• Struktur andeuten. Eine stark abgeblasste Vorschau, wie eine fertige Rechnungsliste aussehen wird, hilft beim Verständnis. Sie muss aber klar als Vorschau erkennbar sein und darf nicht wie echte Daten wirken.
• Illustrationen sparsam einsetzen. Eine freundliche Grafik darf sein, solange sie den Text und den Button nicht unter den sichtbaren Bereich drückt. Auf kleinen Bildschirmen ist die Aktion wichtiger als die Illustration.
• Beispieldaten nur mit Ausgang. Manche Tools füllen neue Konten mit Demo-Inhalten. Das kann beim Lernen helfen, braucht aber eine klare Kennzeichnung und einen einfachen Weg, die Beispiele wieder zu löschen. Sonst verschickt am Ende jemand versehentlich eine Demo-Rechnung.

Keine Ergebnisse: Wenn die Suche ins Leere läuft

Ein ganz anderer Fall ist die leere Trefferliste. Die Person hat etwas gesucht oder gefiltert, und es gibt kein passendes Ergebnis. Hier ist eine Anleitung zum ersten Schritt fehl am Platz. Gefragt ist eine Erklärung, warum nichts gefunden wurde, und ein Weg zurück zu Ergebnissen.

Vorher: „0 Treffer“

Nachher: „Keine Rechnung zu „Müller GmbH“ im Zeitraum März 2026 gefunden. Der Filter „Nur offene Rechnungen“ ist aktiv.“ Darunter die Buttons „Filter zurücksetzen“ und „In allen Zeiträumen suchen“.

Die Nachher-Version wiederholt den Suchbegriff, damit Tippfehler auffallen. Sie macht aktive Filter sichtbar, denn vergessene Filter sind einer der häufigsten Gründe für leere Ergebnisse. Und sie bietet konkrete Auswege an. Gute Suchfunktionen gehen noch einen Schritt weiter und schlagen ähnliche Schreibweisen vor („Meintest du Möller GmbH?“) oder zeigen verwandte Treffer.

Für Menschen, die einen Screenreader nutzen, ist ein Detail wichtig: Die Meldung über die Anzahl der Treffer, auch „Keine Treffer“, sollte vorgelesen werden, ohne dass der Fokus springt. Die WCAG, die internationalen Richtlinien für barrierefreie Webinhalte, verlangen das in Kriterium 4.1.3 („Status Messages“) auf Stufe AA. Die W3C-Erläuterungen nennen genau dieses Beispiel: Nach einer Suche erscheint „5 results returned“ und wird vom Screenreader angesagt. Technisch gelingt das zum Beispiel mit einem Bereich, der role="status" trägt.

Alles erledigt: Der positive leere Zustand

Manchmal ist Leere ein Erfolg. Im Rechnungstool gibt es eine Ansicht „Überfällige Rechnungen“. Wenn dort nichts steht, hat die Person alles im Griff. Ein „Keine Einträge“ verschenkt diesen Moment.

Nachher: „Keine überfälligen Rechnungen. Alle Kundschaft hat pünktlich gezahlt.“ Darunter ein dezenter Link „Zu den offenen Rechnungen“.

Solche Zustände dürfen eine kleine positive Rückmeldung enthalten, etwa ein Häkchen-Symbol. Übertriebene Konfetti-Animationen nutzen sich dagegen schnell ab, besonders in Ansichten, die täglich geöffnet werden.

Kein Zugriff oder entfernt

Der vierte Fall wird oft mit einem Fehler verwechselt: Inhalte sind vorhanden, aber nicht für diese Person sichtbar. Etwa, weil ein Teammitglied nur Leserechte hat oder ein Kunde archiviert wurde. Auch hier hilft ein klarer Satz mehr als eine leere Fläche: „Diese Kundenliste ist nur für Admins sichtbar. Bitte eine Person mit Admin-Rechten um Zugriff.“ So weiß niemand rätselnd, ob die Daten verloren sind oder nur verborgen.

Ladezustände: Warten, ohne zu zweifeln

Warten an sich ist selten das Problem. Schwierig wird es, wenn unklar ist, ob überhaupt etwas passiert. Die NN/g bezieht sich bei Antwortzeiten seit Jahrzehnten auf drei Grenzwerte, die Jakob Nielsen 1993 in seinem Buch „Usability Engineering“ beschrieben hat:

• Etwa 0,1 Sekunden fühlen sich wie eine sofortige Reaktion an.
• Etwa 1 Sekunde bleibt der Gedankenfluss erhalten, auch wenn die Verzögerung spürbar ist.
• Etwa 10 Sekunden ist die Grenze, bis zu der die Aufmerksamkeit bei der Aufgabe bleibt. Danach wandern Menschen gedanklich ab oder wechseln zu etwas anderem.

Aus diesen Grenzen lässt sich ableiten, welche Art von Ladeanzeige wann passt.

Die richtige Anzeige für die richtige Wartezeit

Die NN/g empfiehlt in ihrem Artikel zu Fortschrittsanzeigen eine klare Staffelung. Jede Aktion braucht sofort eine sichtbare Rückmeldung, damit klar ist, dass der Klick angekommen ist. Eine eigene Ladeanzeige lohnt sich ab etwa einer Sekunde. Für Wartezeiten von ungefähr 2 bis 10 Sekunden passt eine Schleifenanimation wie ein Spinner. Ab etwa 10 Sekunden sollte eine Anzeige zeigen, wie weit der Vorgang ist, idealerweise mit einer Prozentangabe oder einer Zeitschätzung. Bei sehr langen Vorgängen gehört außerdem eine Möglichkeit zum Abbrechen dazu.

Wie viel das ausmacht, zeigt eine Studie der University of Nebraska-Lincoln, auf die sich die NN/g bezieht: Wer eine fortlaufend animierte Ladeanzeige sah, war im Schnitt bereit, etwa dreimal so lange zu warten wie Menschen ohne jede Anzeige.

Unter einer Sekunde ist eine Ladeanzeige dagegen eher störend. Ein Spinner, der nur kurz aufblitzt, wirkt unruhig. In der Praxis hilft eine kleine Verzögerung: Die Anzeige erscheint erst, wenn das Laden länger als einen Moment dauert.

Skeleton Screens, Spinner und Fortschrittsbalken

Ein Skeleton Screen ist ein Platzhalter, der die Struktur einer Seite vorwegnimmt: graue Blöcke dort, wo später Überschriften, Bilder und Textzeilen stehen. Die NN/g ordnet die drei gängigen Muster so ein:

• Skeleton Screens eignen sich für das Laden ganzer Seiten, das unter etwa 10 Sekunden bleibt.
• Spinner passen für einzelne Module, etwa eine Kachel im Dashboard oder ein Video.
• Fortschrittsbalken sind die richtige Wahl für alles, was länger dauert, und für Vorgänge, die kein Seitenaufbau sind, etwa Uploads, Downloads oder Konvertierungen.

Die NN/g weist auch auf Grenzen hin. Skeletons, die nur Kopfzeile, Fußzeile und leere Fläche zeigen, vermitteln keine Struktur und wirken eher, als sei die Seite kaputt. Pulsierende oder schimmernde Animationen können ablenken und für manche Menschen zum Problem werden. Und ein Skeleton Screen ist kein Ersatz für eine schnellere Ladezeit.

Im Rechnungstool sieht die Aufteilung so aus:

• Dashboard beim Öffnen: ein Skeleton mit vier Kacheln und einem Diagrammbereich in der echten Anordnung. Jede Kachel ersetzt ihren Platzhalter, sobald ihre Daten da sind, statt dass die ganze Seite auf die langsamste Abfrage wartet.
• Rechnung als PDF erzeugen: Der Button zeigt einen kleinen Spinner und den Text „PDF wird erstellt“. Er ist in dieser Zeit gesperrt, damit kein zweiter Klick eine zweite Datei erzeugt.
• CSV-Import von Kontoauszügen: ein Fortschrittsbalken mit konkretem Text: „Buchung 340 von 1.200 wird zugeordnet“. Die Person kann das Fenster verlassen und bekommt eine Benachrichtigung, wenn der Import fertig ist.

Optimistische Oberflächen

Manche Aktionen müssen gar nicht sichtbar laden. Wenn jemand eine Rechnung als „bezahlt“ markiert, kann die Oberfläche den neuen Status sofort anzeigen und die Änderung im Hintergrund speichern. Dieses Muster heißt optimistisches UI. Es fühlt sich schnell an, funktioniert aber nur, wenn ein Fehlschlag sauber aufgefangen wird: Der Status springt zurück, und eine Meldung erklärt, dass die Änderung nicht gespeichert wurde. Für Aktionen mit großer Tragweite, etwa das Versenden einer Rechnung an Kundschaft, ist das Muster ungeeignet. Dort sollte erst bestätigt werden, was wirklich passiert ist.

Kleine Rückmeldungen wie ein kurz aufleuchtendes Häkchen nach dem Speichern gehören zu den Microinteractions. Sie machen den Status einer Aktion sichtbar, ohne eine eigene Ladeanzeige zu brauchen.

Laden barrierefrei gestalten

Ein Spinner ist für viele Menschen ein klares Signal. Für Menschen mit Screenreader ist er unsichtbar, wenn er nicht technisch angekündigt wird. Auch hier greift WCAG-Kriterium 4.1.3: Statusmeldungen wie „Wird geladen“ oder der Fortschritt eines Uploads müssen von assistiven Technologien ausgegeben werden können, ohne den Fokus zu verschieben. Die W3C-Erläuterungen nennen dafür unter anderem einen Fortschrittsbalken, dessen Stand regelmäßig angesagt wird.

Für die Animationen selbst gibt es eine gute Nachricht: WCAG-Kriterium 2.2.2 („Pause, Stop, Hide“) verlangt für bewegte Inhalte, die länger als fünf Sekunden laufen, normalerweise eine Möglichkeit zum Anhalten. Eine Ladeanimation gilt laut den W3C-Erläuterungen aber als notwendig, wenn während des Ladens keine Interaktion möglich ist und ohne Anzeige der Eindruck entstünde, die Seite sei eingefroren. Trotzdem lohnt es sich, Bewegung zu reduzieren, wenn das Betriebssystem auf „Bewegung reduzieren“ steht. Per CSS lässt sich das mit der Media Query prefers-reduced-motion abfragen und etwa ein schimmernder Skeleton durch eine ruhige Fläche ersetzen.

Fehlerseiten: Wenn etwas schiefgeht

Fehlerseiten sind die dritte Gruppe der vergessenen Screens. Gemeint sind hier nicht die Meldungen an einzelnen Formularfeldern, sondern Zustände, in denen ein ganzer Screen oder ein ganzer Bereich nicht funktioniert. Wie sich eine einzelne Fehlermeldung gut formulieren lässt, ist ein eigenes Thema. Hier geht es um die Frage, was auf dem Bildschirm passiert, wenn der Inhalt selbst fehlt.

Für alle Fehlerseiten gilt ein gemeinsames Grundgerüst. Sie sagen in normaler Sprache, was passiert ist. Sie geben nicht der Person die Schuld. Sie bieten mindestens einen konkreten Weg weiter. Und sie behalten die Navigation der Website, damit niemand in einer Sackgasse landet.

404: Die Seite gibt es nicht

Ein Klassiker: Jemand klickt in einer alten E-Mail auf den Link zu einer Rechnung, die inzwischen gelöscht wurde. Der Server meldet den Statuscode 404 („Not Found“). Viele Fehlerseiten belassen es bei einer großen „404“ und einem Witz.

Vorher: „404. Hier ist nichts. Vielleicht haben Aliens die Seite entführt.“

Nachher: „Diese Rechnung gibt es nicht mehr. Vielleicht wurde sie gelöscht, oder der Link ist nicht vollständig.“ Darunter ein Suchfeld für Rechnungen und die Links „Zur Rechnungsliste“ und „Zum Dashboard“.

Humor ist nicht verboten, er darf aber nie die Orientierung ersetzen. Wer gerade eine wichtige Rechnung sucht, findet eine Alien-Pointe eher nervig als charmant.

Technisch gibt es eine Falle, die auch für die Auffindbarkeit wichtig ist. Eine schön gestaltete Fehlerseite muss trotzdem den echten Statuscode 404 (oder 410 für dauerhaft entfernte Inhalte) zurückgeben. Liefert der Server stattdessen den Code 200, also „alles in Ordnung“, und zeigt dabei nur einen Fehlertext, spricht Google von einem Soft 404. Laut Google Search Central meldet die Search Console solche Seiten dann als Fehler.

500 und 503: Der Fehler liegt beim System

Bei Serverfehlern (Statuscodes ab 500) hat die Person nichts falsch gemacht. Das sollte die Seite auch so sagen. Wichtig ist außerdem, was mit der Arbeit passiert, die gerade erledigt werden sollte.

Vorher: „Error 500: Internal Server Error. Request failed.“

Nachher: „Das hat bei uns gerade nicht geklappt. Deine Rechnung ist als Entwurf gespeichert. Versuch es in ein paar Minuten noch einmal.“ Darunter ein Button „Erneut versuchen“ und ein Link zur Statusseite des Dienstes.

Für geplante Wartungen gibt es den Statuscode 503 („Service Unavailable“). Laut MDN Web Docs sollte er mit einer verständlichen Seite ausgeliefert werden, die das Problem erklärt. Der HTTP-Header Retry-After kann angeben, wann der Dienst voraussichtlich wieder da ist. Für Menschen gehört dieselbe Information in den Text: „Wir führen gerade Wartungsarbeiten durch. Ab etwa 6 Uhr ist das Rechnungstool wieder erreichbar.“ MDN weist außerdem darauf hin, dass solche Antworten in der Regel nicht zwischengespeichert werden sollten, damit niemand nach der Wartung noch die alte Fehlerseite sieht.

Offline und Teilausfälle

Nicht jeder Fehler betrifft die ganze Seite. Im Rechnungstool kann das Dashboard laden, während nur die Kachel mit den Bankumsätzen keine Verbindung zur Bank bekommt. Dann ist es besser, den Fehler genau dort zu zeigen, wo er auftritt: „Die Bankdaten konnten nicht geladen werden. Erneut versuchen.“ Die restlichen Kacheln bleiben nutzbar. Eine bildschirmfüllende Fehlerseite für ein einzelnes Modul würde funktionierende Inhalte unnötig verdecken.

Ähnlich ist es, wenn die Internetverbindung wegfällt. Statt eines leeren Bildschirms zeigt die Anwendung die zuletzt geladenen Daten mit einem klaren Hinweis: „Du bist offline. Du siehst den Stand von 14:32 Uhr. Änderungen werden gespeichert, sobald die Verbindung zurück ist.“ So bleibt die Person handlungsfähig und weiß gleichzeitig, worauf sie sich verlassen kann.

Eingaben nie verlieren

Der schlimmste Fehlerfall ist nicht der Fehler selbst, sondern verlorene Arbeit. Wer zehn Minuten an einer Rechnung mit zwölf Positionen gearbeitet hat und nach einem Serverfehler vor einem leeren Formular steht, verliert schnell das Vertrauen in das Produkt. Deshalb sollten Fehlerseiten und Fehlerzustände nach Möglichkeit nie Eingaben verwerfen. Lokale Zwischenspeicherung, automatische Entwürfe und ein „Erneut versuchen“, das die bereits eingegebenen Daten noch einmal sendet, sind hier wirksamer als jede noch so freundliche Formulierung.

Gemeinsame Prinzipien für alle Zustände

So unterschiedlich leere Listen, Ladeanzeigen und Fehlerseiten sind, sie folgen denselben Grundsätzen.

Status zeigen. Jeder dieser Screens beantwortet die Frage „Was ist hier gerade los?“. Leer, weil neu? Leer, weil gefiltert? Ladend? Kaputt? Wer das nicht unterscheiden kann, rät, und rät oft falsch.

Einen Weg weiter anbieten. Ein Zustand ohne Aktion ist eine Sackgasse. Ob „Erste Rechnung erstellen“, „Filter zurücksetzen“ oder „Erneut versuchen“: Jeder dieser Screens bekommt mindestens eine konkrete nächste Handlung.

Eine gemeinsame Sprache. Wenn jeder Bereich eigene Formulierungen und eigene Grafiken für leere Zustände nutzt, wirkt das Produkt zusammengewürfelt. Ein Design System kann dafür feste Komponenten bereitstellen: einen Empty State mit Platz für Überschrift, Text, Hauptaktion und optionaler Grafik, einen Skeleton-Baukasten und eine Vorlage für Fehlerseiten. Die Texte selbst bleiben aber an den jeweiligen Kontext angepasst.

Im Design-File sichtbar machen. Lege für jede wichtige Ansicht die vier Zustände voll, leer, ladend und fehlerhaft als eigene Frames an. Bei der Übergabe an die Entwicklung hilft eine kurze Tabelle, welche Fehlerfälle welche Ansicht auslösen.

Gezielt testen. In Usability-Tests werden diese Zustände leicht übersehen, weil die Testumgebung voller Daten ist und schnell lädt. Plane deshalb Aufgaben ein, die bewusst in einen leeren oder fehlerhaften Zustand führen, etwa eine Suche ohne Treffer oder die Arbeit mit einem frischen Konto. Viele Browser-Entwicklerwerkzeuge können außerdem langsame Verbindungen oder den Offline-Zustand simulieren. So lässt sich schnell prüfen, wie sich Ladezustände bei schlechtem Netz anfühlen.

Fazit

Am Ende sieht das Rechnungstool an seinen Rändern ganz anders aus. Die leere Rechnungsliste erklärt, was hierhin gehört, und führt mit einem Button zur ersten Rechnung. Eine Suche ohne Treffer zeigt den Suchbegriff, die aktiven Filter und zwei Auswege. Das Dashboard lädt mit einem Skeleton in der richtigen Struktur, der CSV-Import mit einem ehrlichen Fortschrittsbalken. Ein toter Link führt zu einer Seite mit Suche und Navigation, ein Serverfehler sagt, dass der Entwurf sicher ist, und der Offline-Hinweis nennt den Stand der Daten.

Keiner dieser Screens wird in einer Präsentation viel Aufmerksamkeit bekommen. Gerade deshalb lohnt sich der Aufwand: In diesen Momenten ist die Unsicherheit am größten, und ein klarer Satz mit einem passenden Button macht den Unterschied zwischen Weitermachen und Abbrechen.

Checkliste

• Jede wichtige Ansicht hat Entwürfe für die Zustände voll, leer, ladend und fehlerhaft.
• Empty States unterscheiden zwischen erster Nutzung, keinen Treffern, „alles erledigt“ und fehlendem Zugriff.
• Jeder Empty State erklärt, was hierhin gehört, und bietet genau eine Hauptaktion an.
• Leere Suchergebnisse zeigen den Suchbegriff, aktive Filter und einen Weg zurück zu Ergebnissen.
• Jede Aktion gibt sofort Rückmeldung, Ladeanzeigen erscheinen erst ab etwa einer Sekunde.
• Spinner für einzelne Module, Skeleton Screens für ganze Seiten, Fortschrittsbalken ab etwa 10 Sekunden und für Uploads oder Importe.
• Statusmeldungen wie „Wird geladen“ oder „Keine Treffer“ werden für Screenreader angekündigt.
• Animationen respektieren die Einstellung „Bewegung reduzieren“.
• Fehlerseiten sagen in normaler Sprache, was passiert ist, und behalten die Navigation.
• 404-Seiten liefern den echten Statuscode, Wartungsseiten den Code 503 mit Zeitangabe.
• Teilausfälle werden im betroffenen Modul gezeigt, nicht bildschirmfüllend.
• Kein Fehlerzustand verwirft Eingaben.

Quellen

• Nielsen Norman Group: Designing Empty States in Complex Applications: 3 Guidelines
• Nielsen Norman Group: Response Times: The 3 Important Limits
• Nielsen Norman Group: Progress Indicators Make a Slow System Less Insufferable
• Nielsen Norman Group: Skeleton Screens 101
• W3C: Understanding Success Criterion 4.1.3: Status Messages
• W3C: Understanding Success Criterion 2.2.2: Pause, Stop, Hide
• Google Search Central: How HTTP status codes, and network and DNS errors affect Google Search
• MDN Web Docs: 503 Service Unavailable