Eine Fehlermeldung erscheint, wenn jemand eine Aufgabe erledigen möchte und dabei auf ein Hindernis stößt. Kündigt sie lediglich ein Problem an, weiß die Person nicht, ob sie eine Angabe korrigieren, warten, es erneut versuchen oder Hilfe anfordern soll. Für Produkt- und Technikteams geht es nicht darum, den Fehler auszuschmücken. Die Meldung soll dabei helfen, den nächsten Schritt zu wählen und zu verhindern, dass Arbeit verloren geht oder eine Handlung mit möglichen Folgen wiederholt wird.
Nützliche Fehlermeldungen setzen voraus, dass die Ursache des Fehlers, die noch verfügbaren Informationen und die Möglichkeiten zur Behebung bekannt sind. Außerdem muss der Text zum tatsächlichen Verhalten der Anwendung passen. Eine Aufforderung wie „Versuchen Sie es erneut“ ist schädlich, wenn der Vorgang bereits abgeschlossen wurde oder durch eine Wiederholung ein Duplikat entstehen könnte.
Fehler vor dem Formulieren einordnen
Finden Sie zunächst heraus, was den Abschluss der Aufgabe verhindert und wer das Problem beheben kann. Diese Einordnung hilft dabei, sowohl den Inhalt als auch die verfügbare Handlung auszuwählen:
- Von der Person behebbarer Fehler: Ein Pflichtfeld fehlt, das Format einer Angabe ist ungültig oder eine Auswahl erfüllt eine Bedingung nicht. Erklären Sie, was geprüft werden muss, und nennen Sie das konkrete Feld.
- Vorübergehendes Systemproblem: Die Anwendung kann einen Vorgang wegen einer Störung oder eines vorübergehenden Zustands nicht abschließen. Geben Sie an, ob Warten oder ein erneuter Versuch sinnvoll ist und was mit den Daten geschieht.
- Abhängigkeit von einem externen Dienst: Ein angebundener Dienst antwortet nicht oder lehnt die Anfrage ab. Schieben Sie die Ursache nicht der Person zu und versprechen Sie nicht, wann das Problem behoben sein wird. Teilen Sie mit, was die Anwendung weiß, und bieten Sie eine praktikable Alternative an.
- Situation, die Unterstützung erfordert: Die Person kann die Blockade nicht über die Benutzeroberfläche beheben oder der Fall muss geprüft werden. Erklären Sie, wie der Support kontaktiert werden kann und welche hilfreichen Informationen dabei angegeben werden sollten.
Um diese Fälle zu unterscheiden, müssen Sie die technische Architektur nicht offenlegen. Mit dem Entwicklungsteam müssen Sie jedoch klären, welchen Status der Vorgang erreicht hat, ob Änderungen gespeichert wurden und ob eine Wiederholung sicher ist. Ohne diese Informationen kann das Content-Team keine verlässlichen Anweisungen geben.
Verständliche Ursache, Auswirkungen und nächsten Schritt nennen
Eine hilfreiche Meldung beantwortet in alltäglicher Sprache drei Fragen: Was ist passiert, was bedeutet das und was kann ich jetzt tun? Wenn es wichtig ist, ergänzen Sie, ob die Daten erhalten geblieben sind. Sie müssen nicht alle internen Details erklären. Es genügt, genug Kontext zu geben, damit die Person handeln kann.
Zum Beispiel benennt „Das Formular konnte nicht gespeichert werden, weil die Telefonnummer fehlt. Tragen Sie im Feld ‚Telefon‘ eine Nummer ein und speichern Sie erneut“ das Ergebnis, den Grund und die nötige Korrektur. „Fehler bei der Verarbeitung der Anfrage“ sagt dagegen nicht, was zu tun ist. Bei einem vorübergehenden Problem kann eine Formulierung wie „Ihre Ergebnisse konnten nicht geladen werden. Ihre Filter sind noch verfügbar; versuchen Sie es erneut“ nur dann helfen, wenn die Oberfläche diese Filter tatsächlich beibehält.
Prüfen Sie jeden Text anhand des tatsächlichen Produktstatus. Wenn Sie nicht bestätigen können, dass die Daten gespeichert wurden, behaupten Sie nicht, sie seien sicher. Wenn die Ursache unbekannt ist, erfinden Sie keine Erklärung: Teilen Sie das Ergebnis mit und nennen Sie eine sichere Handlung. Eine begrenzte, präzise Erklärung ist besser als ein beruhigendes Versprechen, das die Anwendung nicht halten kann.
Eine Wiederherstellung ermöglichen, die das Problem nicht verschlimmert
Die vorgeschlagene Handlung muss zur Fehlerart und zu den Folgen einer Wiederholung passen. Bevor Sie eine Schaltfläche oder Anweisung anzeigen, beantworten Sie folgende Fragen:
- Kann die Person den Fehler selbst beheben? Wenn ja, lenken Sie die Aufmerksamkeit auf das Feld oder die Auswahl, die geändert werden muss, und behalten Sie andere Angaben nach Möglichkeit bei.
- Ist ein erneuter Versuch sicher? Wenn der Vorgang möglicherweise abgeschlossen wurde, obwohl die Oberfläche dies nicht bestätigt, bieten Sie keinen unüberlegten Wiederholungsversuch an. Prüfen Sie den Status oder erklären Sie, wie er sich feststellen lässt.
- Kann die Aufgabe auf anderem Weg fortgesetzt werden? Gibt es eine praktikable Alternative, etwa einen Entwurf zu speichern oder den Vorgang später abzuschließen, machen Sie diese sichtbar, ohne die Hauptoption zu verbergen.
- Ist Support erforderlich? Nennen Sie einen verfügbaren Kontaktweg und gegebenenfalls eine Referenznummer. Machen Sie den Kontakt nicht zum einzigen Ausweg, wenn die Person das Problem selbst beheben kann.
Bei sensiblen Vorgängen – etwa beim Absenden einer Bestellung, bei einer Zahlung oder beim Veröffentlichen von Inhalten – müssen Sie mit der Entwicklung abstimmen, wie das Ergebnis bestätigt und eine Wiederholung verhindert wird. Die sichtbare Meldung muss dieses Verhalten widerspiegeln. Der Text allein kann nicht garantieren, dass ein Vorgang sicher ist.
Klar und ohne Schuldzuweisung formulieren
Schreiben Sie für die Person, die eine Aufgabe erledigen möchte, nicht für jemanden, der das System debuggt. Vermeiden Sie interne Codes, Komponentennamen und Formulierungen wie „Ungültige Anfrage“, wenn sie nicht erklären, was korrigiert werden muss. Ein Code kann für den Support hilfreich sein, sollte aber eine verständliche Erklärung ergänzen und sie nicht ersetzen.
Verwenden Sie eine direkte, neutrale Sprache. „Die Adresse konnte nicht überprüft werden“ beschreibt das Ergebnis, ohne jemandem die Schuld zu geben. „Sie haben die Adresse falsch eingegeben“ macht die Person verantwortlich und kann falsch sein: Vielleicht ist das erwartete Format nicht klar. Vermeiden Sie auch vage Anweisungen wie „Überprüfen Sie Ihre Angaben“, wenn Sie benennen können, welche Angabe geprüft werden muss.
Kürze ist hilfreich, darf aber keine wichtige Folge verschweigen. Sagen Sie, wenn eine Eingabe gelöscht wurde, der Vorgang noch aussteht oder ein erneuter Versuch ohne Duplikat möglich ist. Wenn Sie nicht wissen, welcher Fall zutrifft, halten Sie die Formulierung an und bitten Sie das Technikteam um eine eindeutige Statusdefinition.
Die Meldung sichtbar und nutzbar machen
Der Text sollte nahe am betroffenen Element oder an einem Ort erscheinen, der zum Umfang des Problems passt. Ein Feldfehler ist meist direkt neben dem Feld hilfreicher als in einer weit entfernten Benachrichtigung. Ist die gesamte Aufgabe blockiert, kann eine allgemeine Meldung die Situation erklären und eine vorrangige Handlung anbieten. Verlassen Sie sich nicht allein auf Farbe, um einen Fehler kenntlich zu machen, sondern ergänzen Sie einen verständlichen Text.
Prüfen Sie, ob die Meldung per Tastatur und mit assistiven Technologien verständlich ist und ob die Person das zugehörige Feld ohne Rätselraten finden kann. Kontrollieren Sie bei Formularen, ob der Fehler nach der Korrektur weiterhin sichtbar ist und ob Fokus und Navigation das Fortfahren ermöglichen. Barrierefreiheit ist nicht gewährleistet, nur weil der Satz korrekt formuliert ist – die Meldung muss auch die Menschen erreichen, die sie benötigen.
Auch der Zeitpunkt ist wichtig: Eine Meldung, die verschwindet, bevor sie gelesen werden kann, oder erscheint, bevor die Person ihre Eingabe beendet hat, kann die Verwirrung verstärken. Prüfen Sie das Verhalten in der tatsächlichen Benutzeroberfläche und in den relevanten Zuständen, nicht nur den Text in einem Dokument.
Eine Fehlermatrix dokumentieren und prüfen
Damit bei demselben Fehler nicht unterschiedliche Antworten gegeben werden, erstellen Sie eine gemeinsame Matrix für Produkt, Design, Entwicklung und Kundenservice. Sie sollte mindestens Folgendes enthalten:
- Name des Status und bekannte Ursache des Problems.
- Aufgabe, an der die Person gearbeitet hat, und Umfang der Auswirkungen.
- Erhaltene, verworfene oder noch zu bestätigende Daten.
- Sichtbarer Text, Platzierung und verfügbare Handlung.
- Verantwortliche Person für die Bestätigung des Verhaltens und Kriterien für die Weiterleitung an den Support.
Priorisieren Sie Fehler, die wichtige Aufgaben blockieren, Datenverlust verursachen können oder wiederholt zu Anfragen führen. Testen Sie die Meldungen anhand echter Aufgaben: Beobachten Sie, ob die Person versteht, was passiert ist, den nächsten Schritt findet und ohne externe Anleitung fortfahren kann. Halten Sie fest, an welcher Stelle Personen abbrechen oder es erneut versuchen, und berücksichtigen Sie auch die beim Support eingehenden Anfragen. Vergleichen Sie diese Hinweise vor und nach Änderungen. Weniger Supportanfragen allein beweisen nicht, dass das Problem gelöst ist: Es kann auch bedeuten, dass Personen gar nicht mehr versuchen, die Aufgabe abzuschließen.
Überarbeiten Sie die Matrix, wenn sich Abläufe, Abhängigkeiten oder die Speicherlogik ändern. Die Qualität einer Meldung bemisst sich nicht daran, wie freundlich sie klingt, sondern daran, ob sie den Status präzise beschreibt und Handeln ermöglicht. Wenn das Produkt das Ergebnis noch nicht kennt, ist es womöglich am besten, keinen automatischen Wiederholungsversuch anzubieten, die Unsicherheit zu erklären und einen sicheren Weg zur Überprüfung oder Unterstützung bereitzustellen.