Du füllst ein Formular aus, klickst auf Senden und erhältst nur den Hinweis „Eingabe ungültig“. Jetzt beginnt die Sucherei. Wer Formular Fehlermeldungen formulieren möchte, sollte diesen Moment umdrehen: Die Meldung nennt das betroffene Feld, beschreibt das Problem in klaren Worten und sagt, wie der Nutzer es beheben kann.
Eine Fehlermeldung ist keine technische Protokollzeile. Sie ist eine kurze Arbeitsanweisung in einer Situation, in der etwas nicht funktioniert hat. Gute Hinweise vermeiden Schuldzuweisungen, bleiben konkret und stehen dort, wo der Fehler entstanden ist.
Das Problem aus Sicht des Nutzers beschreiben
Beginne nicht mit dem internen Prüfmechanismus. Ein Besucher muss nicht wissen, welche Datenbankregel oder welches Skript seine Eingabe abgelehnt hat. Er muss wissen, welches Feld betroffen ist und welche Eingabe akzeptiert wird.
Vergleiche zwei Varianten. „Validierungsfehler 17“ beschreibt nur das System. „Gib eine E Mail Adresse im Format name@beispiel.de ein“ beschreibt die erwartete Korrektur. Der zweite Hinweis ist länger, verkürzt aber den Weg zur Lösung.
Vermeide Wörter wie falsch, verboten oder offensichtlich, wenn sie der Nutzer nicht zur Korrektur braucht. Menschen vertippen sich, verstehen eine Beschriftung anders oder nutzen Hilfsmittel. Die Meldung soll den Vorgang fortsetzen, nicht den Nutzer bewerten.
Formular Fehlermeldungen formulieren: drei Bestandteile
Eine brauchbare Meldung enthält möglichst den Feldbezug, das konkrete Problem und die nächste Handlung. Nicht jede Meldung muss einen vollständigen Absatz bilden. Der Inhalt sollte aber diese drei Aufgaben erfüllen.
Beim Pflichtfeld kann „Gib deine E Mail Adresse ein“ genügen. Bei einem Formatfehler ist eine Ergänzung sinnvoll: „Gib eine E Mail Adresse im Format name@beispiel.de ein.“ Bei einer zu kurzen Eingabe sagst du, welche Mindestanforderung gilt, sofern sie tatsächlich erforderlich ist.
Die Anleitung zu Fehlermeldungen im GOV.UK Design System empfiehlt klare, knappe Aussagen, die erklären, was passiert ist und wie es behoben werden kann. Sie warnt außerdem vor vagen Formulierungen und unnötigen Entschuldigungen.
Schreibe Meldungen in derselben Sprache und Tonlage wie das übrige Formular. Ein sachliches Anmeldeformular braucht keine scherzhafte Fehlermeldung. Humor wirkt in einem gescheiterten Bezahlvorgang oder bei einem verlorenen Entwurf schnell respektlos.
Meldung direkt mit dem Feld verbinden
Platziere den Hinweis möglichst am betroffenen Feld. Eine rote Sammelmeldung am Seitenanfang zeigt zwar, dass etwas fehlt, zwingt den Nutzer aber zur Suche. Bei langen Formularen kann zusätzlich eine Fehlerübersicht am Anfang sinnvoll sein, sofern sie zu den betroffenen Feldern führt.
Farbe allein reicht nicht. Ein roter Rand ist für manche Nutzer nicht erkennbar und erklärt zudem keine Lösung. Ergänze immer Text. Symbole können unterstützen, dürfen den verständlichen Hinweis aber nicht ersetzen.
Das W3C Tutorial zu Benachrichtigungen in Formularen zeigt, wie Fehler im Seitentitel, in einer Zusammenfassung und direkt an Feldern kenntlich gemacht werden können. Es erklärt auch die programmatische Verbindung zwischen Meldung und Eingabefeld, damit assistive Technik den Hinweis zuordnen kann.
Beispiele nach Fehlertyp unterscheiden
Ein leeres Pflichtfeld braucht eine andere Meldung als ein Serverausfall. Ordne deine Hinweise daher nach Ursache. So vermeidest du, dass derselbe Satz für völlig verschiedene Probleme verwendet wird.
| Situation | Unklar | Hilfreicher |
|---|---|---|
| Pflichtfeld leer | Fehler | Gib deinen Namen ein |
| E Mail Format | Ungültige Eingabe | Gib eine E Mail Adresse im Format name@beispiel.de ein |
| Passwörter verschieden | Keine Übereinstimmung | Gib in beiden Feldern dasselbe Passwort ein |
| Server nicht erreichbar | Versand fehlgeschlagen | Das Formular konnte nicht gesendet werden. Deine Eingaben bleiben erhalten. Versuche es später erneut |
Bei einem technischen Ausfall darfst du keine Lösung versprechen, die das System nicht leisten kann. Bleiben Eingaben nicht erhalten, behaupte es nicht. Erkläre stattdessen ehrlich, ob der Nutzer den Inhalt kopieren oder später neu eingeben muss.
Validierung zum richtigen Zeitpunkt auslösen
Eine Fehlermeldung während des Tippens kann stören. Das Feld ist vielleicht noch gar nicht vollständig. Prüfe einfache Anforderungen nach dem Verlassen des Feldes oder beim Absenden, abhängig von Aufgabe und Technik. Vermeide, dass der Hinweis bei jedem Zeichen aufspringt und wieder verschwindet.
Bestätige die Korrektur nachvollziehbar. Sobald die Eingabe gültig ist, sollte die alte Meldung verschwinden. Der Fokus darf nicht unerwartet an eine andere Stelle springen. Bei einer Fehlerübersicht muss die Tastaturbedienung weiterhin logisch bleiben.
Wenn mehrere Felder fehlerhaft sind, zeige alle erkannten Probleme. Der Nutzer sollte nicht nach jeder Korrektur erneut absenden müssen, nur um den nächsten Hinweis zu erhalten. Eine verständliche Übersicht und Meldungen an den Feldern ergänzen sich.
Eingaben nicht unnötig löschen
Ein Formular, das nach einem Fehler alle Felder leert, erzeugt mehr Frust als die Meldung selbst. Bewahre korrekte Angaben nach Möglichkeit auf. Besonders lange Freitexte dürfen nicht verloren gehen, nur weil ein anderes Pflichtfeld fehlt.
Behandle Passwörter und besonders schutzwürdige Daten nach den Sicherheitsregeln deines Systems. Die Forderung, Eingaben zu erhalten, bedeutet nicht, sensible Werte unverschlüsselt oder unbegrenzt zu speichern. Nutzerfreundlichkeit und Datenschutz müssen gemeinsam geplant werden.
Wenn du das gesamte Formular überarbeitest, hilft dir die Anleitung zum Optimieren eines Landingpage Formulars. Dort geht es um Feldumfang, Beschriftung, mobile Bedienung und Prüfung. Fehlermeldungen sind ein Teil dieses größeren Ablaufs.
Erfolgsmeldung und Fehlermeldung trennen
Nach erfolgreichem Versand braucht der Nutzer eine eindeutige Bestätigung. „Danke“ allein kann offenlassen, ob Daten wirklich angekommen sind. Nenne die erfolgte Handlung und den nächsten Schritt, etwa wann eine E Mail kommt oder ob eine Anmeldung bestätigt werden muss.
Zeige keine Erfolgsmeldung, bevor der Server den Vorgang tatsächlich angenommen hat. Eine grüne Anzeige nach rein lokaler Prüfung kann täuschen, wenn die Übertragung anschließend scheitert. Technischer Status und sichtbarer Text müssen denselben Zustand beschreiben.
Für den Aufbau nach dem Versand kannst du den Beitrag zum Erstellen einer Danke Seite nutzen. Dort werden Bestätigung, Erwartungsmanagement und sinnvolle nächste Schritte getrennt betrachtet.
Mobile Darstellung und Tastatur prüfen
Teste Fehlermeldungen auf einem kleinen Bildschirm. Lange Texte können Eingabefelder weit nach unten verschieben. Trotzdem darf die Meldung nicht so stark gekürzt werden, dass die Lösung fehlt. Formuliere zuerst verständlich und optimiere anschließend die Darstellung.
Bediene das Formular einmal nur mit der Tastatur. Du solltest jedes Feld erreichen, den Fehler erkennen und korrigieren können. Prüfe außerdem, ob der Fokus nach dem Absenden sinnvoll gesetzt wird und ob Links in einer Fehlerübersicht funktionieren.
Zoome die Seite und kontrolliere, ob Meldungen abgeschnitten werden oder sich über andere Elemente legen. Teste typische Browser und mindestens ein Mobilgerät. Ein fehlerfreier Entwurf im Baukasteneditor belegt nicht, dass die veröffentlichte Seite ebenso funktioniert.
Mit realistischen Testfällen arbeiten
Erstelle für jedes Feld mindestens drei Fälle: leer, gültig und typisch ungültig. Bei Datumsfeldern kommen unmögliche Daten hinzu, bei Uploads falsche Dateitypen oder zu große Dateien. Notiere erwartete Meldung, tatsächliche Meldung und ob die Eingabe erhalten bleibt.
Teste auch technische Ausfälle. Was sieht der Nutzer bei unterbrochener Verbindung, abgelaufener Sitzung oder einer unerwarteten Serverantwort? Zeige keine internen Pfade, Programmcodes oder Datenbankdetails. Solche Angaben gehören in ein geschütztes Protokoll, nicht in die öffentliche Meldung.
Bitte eine zweite Person, das Formular ohne Erklärung auszufüllen. Beobachte nur, wo sie stockt. Eine Meldung, die für den Ersteller klar wirkt, kann einen unbekannten Begriff enthalten oder auf ein Feld verweisen, das anders beschriftet ist.
KI für Varianten nutzen, nicht für die technische Wahrheit
KI kann aus technischen Rohmeldungen verständliche Entwürfe machen und Ton sowie Länge vereinheitlichen. Gib ihr Feldname, Fehlerursache, erlaubte Eingabe und tatsächliche nächste Handlung. Ein Prompt kann lauten: Formuliere drei sachliche Fehlermeldungen. Nenne das Feld, das Problem und die mögliche Korrektur. Ergänze keine Funktion, die technisch nicht bestätigt ist.
Prüfe jeden Vorschlag am realen Formular. Eine KI weiß nicht, ob Eingaben erhalten bleiben, wann eine E Mail versendet wird oder welche Zeichen dein System akzeptiert. Diese Bedingungen müssen aus der Implementierung oder einer belastbaren technischen Dokumentation stammen.
Übermittle keine echten Formulardaten zur Textoptimierung. Verwende erfundene Beispiele ohne Namen, E Mail Adressen oder Nachrichten. Fehlerprotokolle können personenbezogene Daten enthalten und gehören nur in freigegebene Systeme.
Eine kurze Freigabeprüfung
- Jede Meldung nennt das betroffene Feld oder steht direkt daran.
- Problem und mögliche Korrektur sind verständlich.
- Farbe und Symbol werden durch Text ergänzt.
- Korrekte Eingaben bleiben nach Möglichkeit erhalten.
- Mehrere Fehler werden gemeinsam angezeigt.
- Erfolg erscheint erst nach bestätigtem Versand.
- Tastatur, Zoom und Mobilansicht wurden geprüft.
- Technische Details und personenbezogene Daten bleiben verborgen.
Formular Fehlermeldungen formulieren ist damit keine kosmetische Textaufgabe. Die Meldung muss zum technischen Zustand passen, erreichbar sein und den nächsten Schritt erklären. Wenn Nutzer einen Fehler ohne Rätsel korrigieren können, wird das Formular verständlicher und der Abbruch wegen vermeidbarer Unsicherheit weniger wahrscheinlich.
