Fehlermeldungen auf Websites gehören zu einer Aufgabe, die der Kunde weiterhin erledigen möchte. „Etwas ist schiefgelaufen“ erklärt nicht, ob eine Adresse korrigiert, ein anderer Termin gewählt oder das Ergebnis des letzten Versuchs geprüft werden muss. Bestimme zuerst den Fehlertyp, formuliere anschließend die Meldung und prüfe danach den Rückweg. Bei einem Kontaktformular und anderen Handlungen zählt außerdem, ob eingegebene Informationen verfügbar bleiben und der Kunde den aktuellen Zustand seiner Anfrage versteht.
Trenne Feldfehler, Zustandsänderung und fehlende Bestätigung
Ein Feldfehler erfordert die Korrektur eines bestimmten Werts, etwa des Adressformats. Eine Zustandsänderung bedeutet, dass vorher gültige Angaben nicht mehr zur Aufgabe passen, weil ein anderer Kunde den Termin gebucht hat oder ein Objekt entfernt wurde. Eine fehlende Serverbestätigung erzeugt eine andere Unsicherheit: Die Handlung könnte bereits gespeichert sein, obwohl der Bildschirm das Ergebnis nicht zeigte. Diese Situationen benötigen unterschiedliche nächste Schritte und sollten nicht dieselbe Meldung mit identischer Wiederholungsschaltfläche erhalten.
Wähle einen häufig genutzten Bildschirm und ordne gemeinsam mit dem Funktionsverantwortlichen die tatsächlichen Antworten diesen Kategorien zu. Leite die Ursache nicht nur aus Benachrichtigungsfarben oder der Beschreibung des Nutzers ab. Betrifft das Problem eine Gruppe, prüfe technische Bedingungen auch nach dem Vorgehen für Fehler bei einzelnen Nutzergruppen. Eine Aufzeichnung des Weges zeigt das Verhalten der Oberfläche, ersetzt aber keine Bestätigung des Ergebnisses auf dem Server.
Kläre den Datenstand vor einem Wiederholungsversprechen
Die Meldung sollte anhand geprüften Verhaltens erklären, was von der bisherigen Arbeit erhalten geblieben ist. Bleiben Felder tatsächlich ausgefüllt, kannst du schreiben: „Deine übrigen Angaben stehen weiterhin in diesem Formular“. Speichert die Anwendung sie nicht, füge diese Zusicherung nicht nur zur Beruhigung hinzu. Prüfe Feldablehnung, Ablehnung der ganzen Aufgabe und Verbindungsunterbrechung getrennt, weil danach unterschiedliche Formularzustände möglich sind und eine pauschale Formulierung falsche Erwartungen erzeugt.
Kläre vor einer Wiederholung auch, ob die Handlung bereits ausgeführt worden sein könnte. Bei einer Buchung kann die Prüfung des aktuellen Status sicherer sein als ein zweites Auswählen derselben Schaltfläche. Beschreibe diesen Weg in Kundensprache, statt interne Fehlercodes interpretieren zu lassen. Der Schutz vor Duplikaten ist Aufgabe des Funktionsverantwortlichen; weder Meldungstext noch Analysewerkzeug garantieren, dass ein weiterer Versuch keinen zusätzlichen Eintrag erzeugt.
Formuliere die Meldung passend zur nächsten Handlung
Eine brauchbare Meldung benennt das Problem, erklärt die nötige Änderung und bietet eine zum tatsächlichen Zustand passende Handlung. Bei einem Adressfehler genügt möglicherweise das erwartete Format direkt am Feld. Bei einem vergebenen Termin braucht der Kunde verfügbare Alternativen und keine Aufforderung, dieselben Angaben nochmals zu senden. Die Tabelle enthält Beispiele für eine fiktive Buchung, die du nur nach Prüfung deiner eigenen Anwendung übernehmen solltest.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Problemtyp | Beispielmeldung | Passender Rückweg |
|---|---|---|
| Feld | Gib eine E-Mail-Adresse im Format name@example.com ein. | Korrigiere das Feld ohne Verlust anderer Angaben |
| Aufgabenstand | Dieser Termin wurde gerade vergeben. Wähle einen anderen. | Kehre zur aktuellen Terminauswahl zurück |
| Unbestätigtes Serverergebnis | Wir können die Buchung gerade nicht bestätigen. Prüfe ihren Status vor einem neuen Versuch. | Prüfe den tatsächlichen Eintrag und vermeide ein Duplikat |
Vermeide „Fehler 500, versuche es erneut“, wenn Kunden die Folgen der vorherigen Handlung nicht beurteilen können. Ein klarerer Text lautet: „Wir können die Buchung gerade nicht bestätigen. Öffne deine Buchungsliste und prüfe, ob der Termin gespeichert wurde, bevor du neu beginnst“. Das passt nur, wenn die Liste den Status zuverlässig zeigt. Ohne diesen Weg muss ein anderes Verfahren zur Ergebnisklärung entstehen, statt eine Schaltfläche ohne brauchbares Ziel zu erfinden.
Prüfe die Meldung am Feld und in der Übersicht
Eine Meldung direkt am Feld erleichtert die Korrektur ohne Suche auf der ganzen Seite. Bei mehreren Fehlern kann eine Übersicht die notwendigen Änderungen nennen, sofern sie zu den betreffenden Stellen führt. Prüfe eindeutige Feldnamen und die Sichtbarkeit des Textes während der Korrektur. Kennzeichne Fehler nicht ausschließlich über die Rahmenfarbe, denn manche Menschen können daraus weder Bedeutung noch erforderliche Handlung erkennen und benötigen die Information als verständlichen Text.
Gehe das Formular per Tastatur durch und prüfe den Weg zur Korrektur sowie die Sichtbarkeit des fokussierten Elements. Teste die Benachrichtigung auch mit assistiver Technik, wenn sie im Prüfprozess verfügbar ist. Eine Aufzeichnung von Zeigerbewegungen allein beweist keine richtige Ankündigung durch einen Screenreader. Verbinde diese Prüfung mit der Arbeit an zugänglichen Kontaktwegen, während der Artikel bei der konkreten Wiederaufnahme einer Aufgabe nach einem Fehler bleibt.
Das W3C empfiehlt im Leitfaden für Formularbenachrichtigungen klare Meldungen zu Fehlern, deren Korrektur und zum erfolgreichen Abschluss. Die folgenden Texte sind redaktionelle Vorschläge für die jeweils beschriebenen Situationen.
Rekonstruiere die Schritte nach der Benachrichtigung
Die Analyse umfasst den Moment vor dem Fehler und die Handlungen nach dem Auftauchen der Meldung. Markiere in verfügbaren Aufzeichnungen Aktion, Benachrichtigung, Korrekturversuch und letzten Bildschirmzustand. Nimm nicht an, dass das Schließen einer Meldung ihr Lesen beweist oder ein fehlender weiterer Klick die Ablehnung des Angebots bedeutet. Vergleiche mehrere Abläufe auf wiederkehrende Probleme, etwa erneutes Absenden ohne Korrektur des ausdrücklich genannten Feldes.
Nutze die Grundsätze der Analyse von Sitzungsaufzeichnungen und notiere Grenzen von Stichprobe und Erfassung. Feldinhalte können maskiert sein; errate deshalb keinen eingegebenen Wert anhand von Bewegungen. Bestätige einen konkreten Fehler durch einen kontrollierten Test oder geeignete technische Daten ohne Offenlegung persönlicher Angaben. Die Aufzeichnung weist auf eine prüfenswerte Stelle hin, ist jedoch kein Protokoll jeder Serverantwort und erklärt nicht sämtliche Ursachen eines Fehlschlags.
Verbinde die Korrektur mit der Abschlussbestätigung
Nach erfolgreicher Korrektur sollte der Kunde erkennen, dass die Aufgabe abgeschlossen ist und was danach passiert. Bestätigt die Anwendung eine Anfrage, benenne den erreichten Zustand, statt leere Felder als einziges Signal stehen zu lassen. Setze das Auswählen einer Schaltfläche nicht mit der Annahme des Vorgangs gleich. Verwende für die Messung ein definiertes Ziel, das bei entsprechender Integration durch die richtige Anwendungsbestätigung ausgelöst wird; das Werkzeug erkennt nicht eigenständig die Bedeutung beliebiger Klicks.
Kläre bei mehreren Adressvarianten zunächst, ob sie denselben Bildschirm beschreiben. Der Artikel zu URL-Parametern in Berichten hilft, Fehlerfälle nicht auf scheinbar unterschiedliche Seiten zu verteilen. Prüfe in der Meetlead-Analyse verfügbare Aufzeichnungen und Wege und bestätige die Ergebnisbedeutung in der ausführenden Anwendung. Beginne mit einem Fehlertyp und einer Korrektur, deren anschließenden Verlauf du tatsächlich beobachten kannst.
Fragen zu Fehlermeldungen
Reicht ein anderer Text für „Etwas ist schiefgelaufen“? Nein, wenn der vorgeschlagene Weg unzugänglich bleibt oder Arbeit verloren geht. Kläre zuerst Zustand von Vorgang und Daten und passe danach Text und Handlung an.
Prüfe den ganzen Weg von der Meldung bis zur Abschlussbestätigung. Guter Text hilft beim Nutzen eines funktionierenden Verfahrens, ersetzt aber keine Prozessreparatur.
Zeigen Aufzeichnungen jeden Formularfehler? Nein, ihr Umfang hängt von Sitzungserfassung, Datenabdeckung und Seitenverhalten ab. Sie können Meldung und Reaktion zeigen, bestätigen allein jedoch weder Ursache noch gespeicherten Vorgang.
Ergänze die Prüfung durch einen kontrollierten Versuch und geeignete Anwendungsdaten. Ein fehlender Fehler in der Stichprobe beweist nicht, dass er nie auftritt.
