Fehler- und Statussystem

Was macht Fehler- und Statussystem?

Zweck

Das Fehler- und Statussystem bietet eine Methodik zur Gestaltung der „Unhappy Paths“ einer Website – den Momenten, in denen etwas auf Systemebene schiefgeht. Im Gegensatz zur Formularvalidierung oder kontextuellen Bannern behandelt dieses System vollständige Seiten- oder siteweite Zustände. Es stellt sicher, dass Fehler mit Klarheit, Empathie und einem klaren „Ausweg“ kommuniziert werden, um Nutzerfrustration und -abbrüche bei technischen Problemen zu vermeiden.

Anwendungsfälle

• 404 Nicht gefunden: Wenn ein Nutzer eine URL aufruft, die nicht existiert.
• 500 Serverfehler: Wenn ein kritischer Backend-Fehler das Laden einer Seite verhindert.
• Wartungsmodus: Wenn eine Site absichtlich für Updates offline genommen wird.
• Offline-Zustände: Wenn ein Nutzer in einer Webanwendung die Verbindung verliert.
• Zugriff verweigert (403): Wenn einem Nutzer die Berechtigung zum Anzeigen einer bestimmten Ressource fehlt.

Wann NICHT zu verwenden

• Formularvalidierung: Verwende form-design-system für feldbezogene Fehler.
• Kontextuelle Benachrichtigungen: Verwende banner-and-alert-system für nicht-blockierende Updates oder kleinere Fehler.
• Leere Listen: Verwende empty-state-system, wenn eine Seite korrekt geladen wird, aber keine Daten enthält.
• Ladezustände: Verwende skeleton-state-system für das Standardladen von Inhalten.

Eingaben

1. Fehlertyp: Handelt es sich um einen Client-Fehler (4xx), Server-Fehler (5xx) oder Systemzustand (Wartung)?
2. Technischer Kontext: Kann das System erklären, warum es fehlgeschlagen ist, ohne sensible Daten preiszugeben?
3. Wiederherstellungspfade: Was sind die wahrscheinlichsten nächsten Schritte für den Nutzer?
4. Markenton: Ist die Markenstimme humorvoll, professionell oder streng technisch?
5. Systemeinschränkungen: Muss der Offline-Zustand bestimmte lokale Aktionen unterstützen?

Ausgaben

1. Statusseiten-Anatomie: Ein definiertes Layout für die Fehlermeldung, den visuellen Anker und die Wiederherstellungsaktionen.
2. Nachrichten-Hierarchie: Standards für die Überschrift (was passiert ist) und Beschreibung (was als nächstes zu tun ist).
3. Wiederherstellungs-Blueprint: Eine Karte mit Links, Suchfeldern oder Hilferessourcen, die auf den spezifischen Fehler zugeschnitten ist.
4. Offline-UI-Spezifikation: Regeln dafür, wie sich die Benutzeroberfläche bei Verbindungsverlust ändert.

Arbeitsablauf

1. Kategorisiere die Fehlerschwere

Bestimme die Auswirkungen des Fehlers:

• Niedrig (404/403): Auf eine URL beschränkt. Die Site ist gesund. Fokus auf Weiterleitung.
• Hoch (500): Systemweit oder seitenbrechend. Die Site kämpft. Fokus auf Beruhigung und Support.
• Systemisch (Wartung): Geplante Ausfallzeit. Fokus auf Erwartungsmanagement (z. B. „Zurück um 14:00 Uhr“).
• Konnektivität (Offline): Umgebungsbedingter Fehler. Fokus auf Zustandserhaltung (z. B. „Änderungen lokal gespeichert“).

2. Lege den Wiederherstellungspfad fest

Jede Fehlerseite muss einen „Ausweg“ haben:

• Der „Startseite“-Button: Die absolute Mindestanforderung.
• Intelligente Vorschläge: Bei 404ern Links zu beliebten Seiten oder eine Suchleiste bereitstellen.
• Der „Aktualisieren“-Auslöser: Bei 5xx-Fehlern eine prominente Möglichkeit zum Wiederholen der Anfrage bieten.
• Support-Links: Bei anhaltenden Problemen einen direkten Weg zum Hilfezentrum oder zur Statusseite bereitstellen.

3. Gestalte die visuelle Anatomie

Wende visual-hierarchy-system auf die Fehleransicht an:

• Visueller Anker: Verwende eine markenkonforme Illustration oder ein Symbol, um die Auswirkungen des Fehlers abzumildern.
• Klare Überschrift: Verwende eine „menschliche“ Überschrift (z. B. „Wir können diese Seite nicht finden“) anstelle des reinen Statuscodes („404-Fehler“).
• Subtile Metadaten: Halte technische Codes (z. B. Fehler-ID: 12345) klein und kontrastarm, gedacht für Support-Teams und nicht für den Nutzer.

4. Wende die „Mensch zuerst“-Nachrichtenregel an

Vermeide technisches Fachjargon, der Nutzer abschreckt:

• Schlecht: „500 Internal Server Error: Connection reset by peer.“
• Gut: „Bei uns ist etwas schiefgegangen. Wir arbeiten bereits daran, es zu beheben.“
• Schlecht: „404 Resource not located.“
• Gut: „Sieht aus, als hätte diese Seite eine falsche Abzweigung genommen.“

5. Plane für responsive Anpassung

• Vollseite vs. Modal: Entscheide, ob der Fehler den gesamten Viewport einnehmen soll (Standard bei 404/500) oder als fixierter Banner erscheint (üblich bei Offline-Zuständen).
• Zentriertes Layout: Das Zentrieren von Inhalten ist bei Fehlerseiten oft am besten, da es den Scan-Aufwand minimiert und den „Pausen“-Moment in der Nutzerreise betont.

Entscheidungsregeln

• Die „Direkter Weg“-Regel: Lasse eine Fehlerseite niemals eine Sackgasse sein. Wenn es keine spezifischen Vorschläge gibt, füge immer eine „Zurück zur Startseite“- und eine „Suche“-Option hinzu.
• Suche-bei-404: Wenn eine Site mehr als 100 Seiten hat, MUSS die 404-Seite eine Suchleiste enthalten.
• Wartungstransparenz: Gib im Wartungsmodus immer eine voraussichtliche Rückkehrzeit oder einen Link zu einer Statusseite an.
• Offline-Persistenz: Blende bei Offline-Betrieb nicht funktionsfähige Aktionen (z. B. „Absenden“-Schaltflächen) visuell aus oder deaktiviere sie, um Datenverlust zu vermeiden.

Einschränkungen

• Barrierefreiheit: Fehlerseiten müssen die globale Navigation und Fußzeile der Site (wo möglich) beibehalten, um vertraute Orientierung zu bieten. Verwende bei dynamischen Statusänderungen (wie dem Übergang zu Offline) eine aria-live="assertive"-Region, um die Änderung sofort anzukündigen.
• Responsivität: Fehlerseiten müssen so robust wie möglich sein. Vermeide schwere Assets, die möglicherweise nicht laden, wenn das System bereits kämpft.
• Branding: Fehlerseiten sollten wie ein Teil der Site aussehen, nicht wie eine generische Browser- oder Server-Standardseite.

Häufige Fehlermuster

• Die „Sackgasse“: Eine 404-Seite ohne Links, die den Nutzer zwingt, den Zurück-Button des Browsers zu verwenden oder die Seite zu verlassen.
• Die „Fachjargon-Wand“: Anzeigen von rohen Stacktraces oder Datenbankfehlern, die Nutzer verwirren und möglicherweise Sicherheitsinformationen preisgeben.
• Das „Schuldspiel“: Nachrichten, die implizieren, dass der Nutzer etwas falsch gemacht hat (z. B. „Sie haben eine ungültige URL eingegeben“), anstatt die Verantwortung für den Fehler zu übernehmen.
• Stilinkonsistenz: Eine Fehlerseite, die andere Schriftarten/Farben als der Rest der Site verwendet und dadurch defekt oder bösartig wirkt.

Validierungskriterien

• Jeder Fehlerzustand (404, 500, etc.) hat eine klare, menschenlesbare Überschrift.
• Mindestens eine primäre Wiederherstellungsaktion (z. B. „Zurück zur Startseite“) ist vorhanden.
• Bei 404-Seiten wird eine Suchleiste oder beliebte Links zur Navigation bereitgestellt.
• Technische Metadaten (Fehler-IDs) sind vorhanden, aber in der Hierarchie untergeordnet.
• Konnektivitätsänderungen (Offline) werden über ARIA-Live-Regionen angekündigt.
• Das visuelle Styling bleibt konsistent mit dem Kernmarken-/Designsystem.
• Wartungsseiten bieten einen Link „Voraussichtliche Rückkehr“ oder „Statusseite“.