Der teuerste Satz in eurem Produkt – und warum schlechte Fehlermeldungen keine Schlamperei sind, sondern ein Zins, der jedes Jahr steigt.
Für Eilige: Fehlerzustände treffen ausgerechnet die Leute, die gerade zahlen, buchen oder abschicken wollten. Trotzdem werden sie nirgends gestaltet: Sie stehen in keinem Konzept und in keinem Akzeptanzkriterium, also tippt sie am Ende ein Entwickler nebenbei ins Codefenster, während er eigentlich das Feature baut. Das Ergebnis ist kein Designproblem, sondern ein Kostenproblem mit Zinseszins: Jede unverständliche Meldung erzeugt Support-Kontakte, und ein Kontakt im Live-Kanal kostet laut Gartner im Median 13,50 Dollar. Die Meldung umzuschreiben kostet einmalig zwanzig Minuten. Der Anruf kostet euch jedes Mal.
Nehmt euch diesen Satz mal vor:
Es ist ein technischer Fehler aufgetreten. Bitte versuchen Sie es später erneut.
Der Nutzer stellt sich in diesem Moment vier Fragen:
- Was ist passiert?
- Lag es an mir?
- Sind meine Daten weg?
- Wann ist „später"?
Beantwortet werden null davon. Der Satz enthält exakt eine Information – dass etwas kaputt ist –, und die hatte der Nutzer bereits, bevor er ihn gelesen hat.
Genau deshalb ist das die Standardmeldung: Sie ist die einzige Aussage, die immer stimmt, wenn man nichts über die Situation wissen will. Sie ist keine Kommunikation. Sie ist ein Achselzucken mit Corporate-Font.
Und sie erscheint nie zu einem harmlosen Zeitpunkt. Fehlermeldungen kommen nicht, während jemand gelangweilt scrollt. Sie kommen, wenn jemand etwas tun wollte: abschicken, bezahlen, buchen, beantragen. Fehlerzustände treffen zielsicher die Nutzer mit der höchsten Absicht. Also die wertvollsten, die ihr an dem Tag habt.
1. Der Teil, den alle überspringen: was das kostet
Ich fange bewusst nicht mit Textbeispielen an, sondern mit Geld. Denn genau hier wird in Projekten weggeschaut, und zwar systematisch.
Schlechte Fehlerkommunikation ist keine Unschönheit. Sie ist eine Dauerlast. Und zwar eine, die ihr nie loswerdet, weil sie nicht getilgt wird: Jede Meldung, die niemand versteht, kostet euch nicht einmal Geld, sondern bei jedem einzelnen Nutzer, der sie zu sehen bekommt – in einer anderen Kostenstelle, wo niemand die Verbindung zum Ursprung herstellt.
Das ist der Unterschied zu einem Kredit. Ein Kredit ist irgendwann abbezahlt. Das hier läuft weiter, und der Betrag steigt, je besser euer Produkt läuft.
Die Raten heißen: Anruf, Ticket, Chatverlauf, Mail an den Support, Rückfrage beim Kollegen, Abbruch.
Ein paar belastbare Zahlen dazu.
Gartner beziffert den Median für einen Kontakt im assistierten Kanal – Telefon, Chat, E-Mail – auf 13,50 Dollar, während ein erfolgreich abgeschlossener Self-Service-Vorgang bei etwa 1,84 Dollar liegt. In einer früheren Erhebung derselben Reihe lag der Live-Kontakt bei 8,01 Dollar gegenüber rund 10 Cent im Self-Service. Gartner zum Kostenunterschied. Die genaue Zahl variiert nach Branche und Land. Die Größenordnung nicht: Ein Mensch am Telefon kostet ein Vielfaches dessen, was ein selbsterklärender Bildschirm kostet.
Jetzt die Rechnung, die ihr selbst aufmachen könnt.
Sagen wir, eure Anwendung hat 100.000 relevante Vorgänge im Monat. Zwei Prozent laufen in einen Fehlerzustand – das ist nicht viel. Das sind 2.000 Fälle. Ein Fünftel davon meldet sich beim Support, weil die Meldung nicht weiterhilft: 400 Kontakte. Bei 12 Euro pro Kontakt – konservativ gerechnet, gemessen an den Zahlen oben – sind das 4.800 Euro im Monat. 57.600 Euro im Jahr.
Für eine Handvoll Sätze, die jemand nie geschrieben hat.
Und jetzt der Teil, der in keiner Präsentation steht:
Diese Kosten wachsen mit eurem Erfolg. Mehr Nutzer heißt mehr Fehlerfälle heißt mehr Kontakte. Die Designarbeit dagegen fällt genau einmal an. Ihr habt also eine wiederkehrende, wachsende Ausgabe gegen eine einmalige Investition getauscht – in die falsche Richtung. Wer skaliert, skaliert das Problem mit.
Und ihr zahlt an mehreren Stellen gleichzeitig:
- Support. Jeder Kontakt, der nur existiert, weil ein Bildschirm nichts erklärt hat.
- Second-Level und Entwicklung. Wenn der Fehlercode dem Nutzer nichts sagt und dem Support auch nicht, landet der Fall bei Leuten, deren Stunde am teuersten ist.
- Abbruch. Der Teil, der sich nie meldet und einfach geht. Der taucht in keinem Ticketsystem auf – die teuersten Fälle sind die, die ihr nie zu Gesicht bekommt.
- Wiederholte Fehleingaben. Jeder gescheiterte Versuch erzeugt Last, Logs, teilweise Datenmüll in euren Systemen.
- Vertrauen. Weich, aber real: Ein Nutzer, der einmal seine Daten verloren hat, füllt kein zweites Mal ein langes Formular aus.
- Onboarding intern. Bei Fachanwendungen kommt dazu: Jede kryptische Meldung wird Teil des Erfahrungswissens, das neue Mitarbeiter sich mühsam aneignen müssen. Das ist Schulungsaufwand, den ihr euch selbst gebaut habt.
Der bittere Teil: Fehlermeldungen sind die billigste Reparatur im gesamten Produktzyklus. Kein Refactoring, keine Migration, keine neue Architektur. Meistens: Text ändern, Meldung ans richtige Feld hängen, einen Button dazu. Tage, nicht Monate.
Fragt in eurem Support nach den zehn häufigsten Kontaktgründen. Wenn davon nicht mindestens drei auf einen Bildschirm zurückgehen, der nichts erklärt hat, esse ich meinen Notizblock.
2. Was in dem Standardsatz alles fehlt
Zurück zum Klassiker. Eine brauchbare Fehlermeldung beantwortet vier Dinge:
Was ist passiert – in der Sprache des Nutzers. Nicht „Transaktion abgelehnt", sondern „Deine Bank hat die Zahlung abgelehnt". Das ist derselbe Sachverhalt und eine völlig andere Information.
Was ist mit meinen Daten? Die wichtigste und am seltensten beantwortete Frage. „Deine Eingaben sind gespeichert" nimmt neunzig Prozent der Panik raus. Ein Satz.
Was kann ich jetzt tun? Jede Meldung braucht einen nächsten Schritt. Erneut versuchen, anderen Weg wählen, Support kontaktieren, später wiederkommen – aber irgendwas. Eine Sackgasse mit „OK"-Button ist keine Kommunikation, das ist Rausschmiss.
Wann, wenn nicht jetzt? „Später erneut versuchen" ist keine Zeitangabe. „In etwa zehn Minuten" oder „Wir arbeiten dran, der Status steht hier" schon.
Das ist keine Erfindung von mir. Es ist im Kern die neunte von Jakob Nielsens Usability-Heuristiken – Nutzer sollen Fehler erkennen, verstehen und beheben können –, und die Nielsen Norman Group hat daraus zwölf sehr konkrete Regeln abgeleitet. Error-Message Guidelines bei NN/g.
3. Fehlercodes: nicht das Problem, aber selten die Lösung
ERR_5031 ist eine Nachricht ans Entwicklungsteam, die versehentlich an den Kunden zugestellt wurde.
Trotzdem bin ich kein Gegner von Fehlercodes. Sie sind nützlich – im Support. Ein Code, den der Nutzer vorlesen kann, verkürzt jedes Gespräch. Die Frage ist nur, ob der Code die Meldung ist oder ob er sie ergänzt.
Falsch: Der Code ist die Meldung.
Richtig: Klartext oben, Handlungsoption in der Mitte, Code klein darunter, kopierbar.
Zwei Bedingungen dafür, dass ein Code seinen Zweck erfüllt:
- Der Support kann ihn nachschlagen – ohne bei der Entwicklung anzurufen.
- Er ist eindeutig. Ein Code, den fünf verschiedene Ursachen auslösen, ist Dekoration.
Und HTTP-Statuscodes gehören generell nicht in die Oberfläche. „500 Internal Server Error" ist für Menschen ohne IT-Hintergrund ungefähr so hilfreich wie eine Fehlermeldung auf Latein. Es ist nicht mal falsch übersetzt – es ist einfach nicht für sie geschrieben.
4. Wer hat eigentlich Schuld?
Drei Zustände werden ständig durcheinandergeworfen:
Systemfehler. Server weg, Schnittstelle tot, Timeout. Der Nutzer kann nichts dafür und meistens nichts dagegen. Hier gehört sich eine Entschuldigung und eine Ansage, wie es weitergeht.
Nutzerfehler. Falsches Format, fehlendes Pflichtfeld, ungültige Kombination. Hier gehört sich eine Anleitung, keine Belehrung.
Erwartbare Zustände. Konto gesperrt, Ware nicht lieferbar, Termin belegt. Das sind gar keine Fehler, sondern Ergebnisse. Sie werden trotzdem meistens rot ausgegeben, weil es im Code derselbe Zweig war.
Und dann gibt es die Kategorie, die mich am meisten ärgert: Fehler, die ihr selbst verursacht und dem Nutzer anlastet. „Ungültige Eingabe" für ein Format, das ihr nirgends erklärt habt. Die abgelehnte IBAN mit Leerzeichen, obwohl jeder Kontoauszug sie mit Leerzeichen druckt. Das Datumsfeld, das nur TT.MM.JJJJ akzeptiert und 1.3.2026 verwirft.
Das ist kein Nutzerfehler. Das ist ein Systemfehler mit Schuldzuweisung.
5. Der Ton
Fehlermeldungen sind der einzige Moment, in dem eure Marke mit jemandem spricht, der gerade genervt ist. Entsprechend sollte man den Ton behandeln.
Was nicht funktioniert:
- Passivkonstruktionen. „Es ist ein Fehler aufgetreten" – von selbst, offenbar.
- Schuldzuweisung. „Sie haben eine ungültige Nummer eingegeben." Kein Mensch redet so, außer im Amt.
- Juristendeutsch. „Die Verarbeitung Ihres Anliegens konnte nicht abgeschlossen werden."
- Witze an der falschen Stelle. „Ups! Da ist wohl was schiefgelaufen 🙈" – bei einer gescheiterten Überweisung ist das keine Sympathie, das ist Verhöhnung. Humor darf in eine 404-Seite. Nicht in einen Zahlungsvorgang.
Was funktioniert: sachlich, konkret, ohne Zeigefinger. Nicht „Ungültiges Format", sondern „Die IBAN hat 22 Stellen, deine hat 20". Der Nutzer weiß sofort, was zu tun ist, und fühlt sich dabei nicht wie ein Idiot.
Eine Regel, die fast immer trägt: Nimm das Wort aus dem Label und pack es in die Meldung. Steht am Feld „Geburtsdatum", dann heißt die Meldung „Gib dein Geburtsdatum ein" – nicht „Pflichtfeld".
6. Der teuerste Fehler von allen: gelöschte Eingaben
Wenn ein Formular nach einem Fehler die Eingaben verwirft, ist alles andere egal.
Ich habe das in Projekten immer wieder gesehen, meistens ungewollt, meistens durch einen Reload nach serverseitiger Validierung. Der Nutzer hat acht Minuten investiert, bekommt eine rote Meldung und ein leeres Formular. Ab da geht es nicht mehr um Usability, sondern darum, ob er überhaupt zurückkommt.
Dasselbe gilt für Sessions, die nach fünfzehn Minuten ohne Vorwarnung ablaufen, und für Uploads, die bei einem einzigen ungültigen Feld komplett verworfen werden.
Merksatz: Ein Fehler darf nie Arbeit vernichten. Wenn ihr aus diesem ganzen Text einen Satz mitnehmt, dann diesen.
7. Wo die Meldung steht und wann sie kommt
Wo: Am Feld. Nicht in einem roten Kasten oben, auf den der Nutzer scrollen muss, um dann wieder runterzuscrollen und zu raten, welches Feld gemeint war. Bei langen Strecken zusätzlich eine Fehlerübersicht am Seitenanfang, deren Einträge als Sprungmarken auf das jeweilige Feld verlinken. Das Pattern ist im GOV.UK Design System und im NHS Service Manual fertig dokumentiert, inklusive Fokusverhalten für Screenreader – man muss es nur abschreiben. Error Summary im NHS Service Manual.
Wann: Nach dem Verlassen des Feldes. Nicht während des Tippens – wer nach zwei Buchstaben „ungültige E-Mail-Adresse" sieht, wird von der eigenen Software gemaßregelt, bevor er fertig gedacht hat. Und nicht erst beim Absenden, weil dann alles auf einmal kommt.
Zur Wirkung gibt es eine viel zitierte Untersuchung von Luke Wroblewski und Etre aus dem Jahr 2009: Inline-Validierung brachte dort 22 Prozent mehr erfolgreiche Abschlüsse, 22 Prozent weniger Fehler und deutlich kürzere Bearbeitungszeiten. Ergebnisse bei LukeW. Ehrlicherweise dazu: kleine Stichprobe, ein Formulartyp, über fünfzehn Jahre alt. Ich führe die Zahlen als Indiz an, nicht als Naturgesetz – und würde bei einer langen Strecke ohnehin selbst messen.
8. Die Bildschirme, die in keinem Konzept auftauchen
Legt mal eure Designdateien nebeneinander und sucht nach: 404. 500. Timeout. Offline. Wartungsfenster. Session abgelaufen. Leerer Zustand nach einer Suche ohne Treffer.
In neun von zehn Projekten sind diese Screens nicht da. Nicht, weil jemand entschieden hat, sie wegzulassen – sondern weil niemand sie bestellt hat. Sie stehen in keinem Flowchart, weil Flowcharts den Erfolgsfall abbilden. Sie stehen in keinem Akzeptanzkriterium. Sie werden zur Laufzeit erzeugt, von der Standardausgabe des Frameworks.
Das ist der eigentliche Befund dieses Artikels: Schlechte Fehlerzustände sind kein Qualitätsproblem einzelner Leute. Sie sind ein Prozessproblem. Niemand ist zuständig, also passiert es nebenbei, um zwei Uhr nachts, von jemandem, der gerade ein anderes Problem lösen wollte.
Wer das ändern will, braucht keine Designphilosophie, sondern eine Zeile in der Definition of Done: Kein Feature gilt als fertig, solange der Fehlerfall nicht mitgestaltet ist.
9. Und seit dem BFSG ist es zusätzlich Pflicht
Die Web Content Accessibility Guidelines regeln Fehler ziemlich explizit:
- 3.3.1 Fehlererkennung: Ein erkannter Fehler muss in Textform beschrieben werden – Farbe allein reicht nicht.
- 3.3.2 Beschriftungen oder Anweisungen: Wenn Eingaben ein bestimmtes Format brauchen, muss das vorher dastehen.
- 3.3.3 Fehlerempfehlung: Wenn das System einen Korrekturvorschlag kennt, muss es ihn nennen.
- 3.3.4 Fehlervermeidung: Bei rechtlichen und finanziellen Vorgängen muss man Eingaben prüfen oder rückgängig machen können.
Das sind die Konformitätsstufen A und AA, also genau das, worauf die EN 301 549 und damit das Barrierefreiheitsstärkungsgesetz verweisen – in Kraft seit Juni 2025. WCAG-Übersicht des W3C.
Für den generischen Serverfehler greift das nicht unbedingt – da ist oft schlicht keine Empfehlung bekannt. Bei allem, was mit Eingaben zu tun hat, schon: Ein rot umrandetes Feld ohne Text verstößt gegen 3.3.1. Ein „Ungültige Eingabe", obwohl das System das erwartete Format kennt, verstößt gegen 3.3.3. Beides steht in jedem zweiten Produkt, das ich mir ansehe. Das ist dann nicht mehr nur schlechte Kommunikation, sondern ein Prüfpunkt, an dem ihr durchfallt.
10. Was ihr konkret machen könnt
1. Sammelt eure Fehlermeldungen ein. Alle. In eine Tabelle. Bei den meisten Produkten kommen zwischen 40 und 300 zusammen, und niemand im Haus hat sie je gemeinsam gesehen. Allein diese Liste ist ein halber Tag Arbeit und stellt regelmäßig die erste unangenehme Frage.
2. Sortiert nach Häufigkeit, nicht nach Alphabet. Die zehn häufigsten machen fast immer den Großteil des Volumens aus. Dort fangt ihr an.
3. Legt einen Gegenschein an. Was ist passiert, was ist mit meinen Daten, was kann ich tun, wie lange dauert es. Vier Spalten. Jede Meldung, die nicht alle vier beantwortet, wird umgeschrieben.
4. Verbindet die Liste mit den Support-Kontaktgründen. Das ist der Schritt, der aus einer Designaufgabe einen Business Case macht. Häufigster Kontaktgrund mal Kosten pro Kontakt – fertig ist der Antrag.
5. Nehmt die Fehlerzustände in die Definition of Done auf. Sonst passiert das Ganze in einem Jahr wieder.
6. Messt danach. Anzahl der Kontakte zu diesem Thema, vorher und nachher. Genau eine Folie. Diese Folie entscheidet, ob es beim nächsten Mal wieder Budget gibt.
11. Warum ihr mir das glauben könnt
Ich bin Tobias Adam, freier UX-Designer in Hamburg, seit über zehn Jahren in digitaler Produktentwicklung.
Gelernt habe ich das Handwerk in Agenturen, unter anderem bei Jung von Matt und deepblue networks. Gearbeitet habe ich unter anderem für BMW, Audi, FIFA, Union Investment, Vodafone, OBI und die Deutsche Messe. Über 20 Auszeichnungen, darunter Webby, ADC und Cannes.
Die Awards gab es für die sichtbaren Sachen. Interessant wurde es immer bei den unsichtbaren. Bei der Depoteröffnung von VisualVest im Union-Investment-Umfeld zum Beispiel: Wenn in einer regulierten Strecke etwas schiefgeht, ist die Fehlermeldung keine Textzeile, sondern die Frage, ob jemand einem Finanzprodukt noch sein Geld anvertraut. Oder bei einem digitalen Zukunftsplaner, bislang unveröffentlicht, wo derselbe Punkt anders lag: Wie viel darf ein System korrigieren, bevor es bevormundet?
Und danach zieht es sich durch alles: Registrierungen, Anträge, Onboardings, Fachanwendungen. Fehlerzustände sind der Teil, den ich in Projekten am häufigsten zum ersten Mal überhaupt aufschreibe.
Heute arbeite ich freiberuflich und gemeinsam mit HC Merkle unter intro.team – zwei Freelancer für die Phase, in der aus einer Idee ein testbares Produkt wird: Konzept, UX, UI, Prototyp, Nutzertests. Kurze Zyklen, seniore Besetzung, kein Agenturapparat.
12. Die Kurzfassung
- Fehler treffen die Nutzer mit der höchsten Absicht. Also die wertvollsten.
- Jede unklare Meldung ist eine Dauerlast. Sie wird nie getilgt, und der Betrag steigt mit jedem neuen Nutzer.
- „Technischer Fehler, bitte später erneut versuchen" beantwortet keine einzige Frage. Streicht den Satz aus eurem Produkt.
- Vier Fragen gehören beantwortet: Was ist passiert, was ist mit meinen Daten, was kann ich tun, wie lange dauert es.
- Fehlercodes ergänzen die Meldung, sie ersetzen sie nicht. Und Statuscodes gehören nicht in die Oberfläche.
- Verwechselt Nutzerfehler nicht mit euren eigenen. Eine abgelehnte IBAN mit Leerzeichen ist euer Problem.
- Ein Fehler darf niemals Arbeit vernichten. Keine gelöschten Formulare, keine stillen Session-Timeouts.
- Meldung ans Feld, Übersicht mit Sprungmarken oben, Validierung nach dem Verlassen des Feldes.
- 404, 500, Timeout, Offline gehören ins Konzept, nicht in die Standardausgabe des Frameworks.
- Kein Feature ist fertig, solange der Fehlerfall nicht gestaltet ist. Schreibt es in die Definition of Done.
Ein Produkt zeigt nicht im Erfolgsfall, was es taugt. Es zeigt es in dem Moment, in dem es nicht funktioniert.
Quellen und Weiterlesen
- Nielsen Norman Group: Error-Message Guidelines – nngroup.com
- Nielsen Norman Group: 10 Design Guidelines for Reporting Errors in Forms – nngroup.com
- Jakob Nielsen: 10 Usability Heuristics for User Interface Design – nngroup.com
- Gartner: Kosten pro Kontakt in Live- und Self-Service-Kanälen – gartner.com
- Luke Wroblewski / Etre: Testing Real Time Feedback in Web Forms (2009) – lukew.com
- NHS Digital Service Manual: Error summary – service-manual.nhs.uk
- GOV.UK Design System: Error summary – design-system.service.gov.uk
- W3C: WCAG 2.1 Quick Reference, Abschnitt 3.3 – w3.org
- Barrierefreiheitsstärkungsgesetz (BFSG), in Kraft seit 28.06.2025 – bfsg-gesetz.de