Microcopy: kleine Worte, großer Unterschied

In der Demo oben steht zweimal dasselbe Feld mit demselben Button. Die erste Version fragt nach „E-Mail*“, meldet „Ungültige Eingabe.“ und endet mit „ABSENDEN“. Die zweite fragt nach „Ihre E-Mail-Adresse“, sagt dazu, wofür („für unsere Antwort, sonst nichts“), nennt, wann Sie etwas hören, und endet mit „Angebot anfragen“. Das Feld ist dasselbe, die Technik auch. Nur die Worte unterscheiden sich.

Diese Worte heißen Microcopy. Im Folgenden lesen Sie, wo sie stehen, wie Sie sie schreiben, was WCAG 2.2 von ihnen verlangt und wie Sie sie testen. Was wir über unsere eigenen Websites sagen, steht auf ihren Fallstudien.

Was ist Microcopy?

Microcopy ist jeder kurze Text, der jemandem hilft, auf Ihrer Website oder in Ihrer App etwas zu tun. Selten sind es mehr als ein paar Worte, und sie stehen dort, wo ein Besucher eine Wahl trifft: Klicke ich, fülle ich das aus, mache ich weiter?

Der Unterschied zu gewöhnlichem Webtext liegt im Zweck. Ein Text auf einer Leistungsseite erklärt und überzeugt: warum Sie, was der Kunde bekommt, was der nächste Schritt ist. Microcopy begleitet die Handlung selbst. Sie muss nicht mehr überzeugen; sie räumt den letzten Zweifel aus. Gleiches Handwerk, andere Größe. Mehr über längere Texte lesen Sie in unserem Beitrag über Webtexte.

Weil die Texte so klein sind, werden sie leicht vergessen. Dann bleibt stehen, was das System tut, etwa Absenden oder Ungültige Eingabe. Die gute Nachricht: Ein besserer Buttontext braucht kein neues Design, nur Aufmerksamkeit.

Wo steht Microcopy?

Überall dort, wo ein Besucher etwas tun muss oder kurz zögert. Jede Stelle beantwortet eine eigene Frage:

• Buttons und Links: Was passiert, wenn ich klicke, und lege ich mich damit fest?
• Labels: Was soll ich hier eingeben?
• Hinweistexte und Beispiele: In welcher Form, und warum fragen Sie das?
• Fehlermeldungen: Was ist schiefgegangen, und was soll ich jetzt tun?
• Leere Bildschirme: Warum sehe ich nichts, und wie fange ich an?
• Bestätigungen: Hat es geklappt, und was passiert jetzt?
• Statuslabels: Was bedeutet dieses kleine Wort neben einem Produkt, einer Werkstatt oder einer Bestellung? Auf snelrepareren.nl tragen Werkstätten das Label Verifiziert oder Nicht verifiziert.

Welche drei Fragen stellen Sie bei jedem Satz?

Erstens: Was denkt der Besucher in diesem Moment? Zweitens: Was muss er wissen, um weiterzukommen? Drittens: Was ist die kürzeste ehrliche Antwort darauf? Mehr Methode brauchen Sie nicht.

Nehmen Sie die Fehlermeldung aus der Demo. „Ungültige Eingabe“ beschreibt das System: Es hat etwas abgelehnt. Wer das liest, weiß immer noch nicht, was er tun soll. „In dieser E-Mail-Adresse fehlt das @-Zeichen“ beschreibt die Lösung. Gleicher Fehler, anderer Ausgang.

Dieselben drei Fragen schreiben auch Ihre Buttons um. Absenden sagt, was das System tut; Angebot anfragen sagt, was der Besucher bekommt. Schreiben Sie für die Seite, die klicken muss.

Schreiben Sie nicht, was das System getan hat. Schreiben Sie, was der Nutzer jetzt tun muss.

Wie schreiben Sie einen Button?

Ein Button ist ein Versprechen: Wenn Sie hier drücken, passiert das. Je genauer das Versprechen, desto weniger muss jemand raten.

• Beginnen Sie mit einem Verb und sagen Sie, was passiert. Angebot anfragen, Jetzt anmelden, Preis ansehen. Das Designsystem der britischen Regierung sagt es so: Beschreiben Sie die Handlung, die der Button ausführt.
• Schreiben Sie normal, nicht in Großbuchstaben. Dasselbe Designsystem empfiehlt Buttontexte in normaler Schreibweise statt in Großbuchstaben. ABSENDEN in der Demo fällt also heraus.
• Verwenden Sie überall dasselbe Wort. Heißt es im Menü Anmelden, sollen auch der Button und die Überschrift der Seite von der Anmeldung sprechen.
• Sagen Sie bei einem Formular in Schritten, wo man ist. Ein Button Weiter ist zwischen den Schritten in Ordnung; der letzte Button sagt, was dann wirklich passiert, etwa Anfrage senden.
• Deaktivieren Sie keinen Button ohne Erklärung. Ein grauer Button, der nichts tut, lässt den Besucher raten, was fehlt. Die britische Regierung rät von deaktivierten Buttons ab: Sie haben schlechten Kontrast und verwirren manche Menschen. Lassen Sie den Button funktionieren und sagen Sie nach dem Klick, was fehlt.

Wie schreiben Sie ein Label?

Ein Label sagt, was in ein Feld gehört. Es steht beim Feld, bleibt stehen, während man tippt, und verwendet die Worte des Besuchers, nicht die Ihrer Datenbank. „Ihre E-Mail-Adresse“ liest sich wie die Frage eines Menschen; „E-Mail*“ wie eine Spalte in einer Tabelle.

• Jedes Feld ein eigenes Label, auch jede Wahl in einer Reihe von Optionsfeldern oder Kästchen. Wer ein Häkchen setzt, muss wissen, wofür.
• Ein Beispiel im Feld ist kein Label. Das W3C schreibt, dass ein solcher Beispieltext (ein Platzhalter) verschwindet, sobald man tippt, oft weniger Kontrast hat und von Screenreadern nicht als Label gelesen wird. Setzen Sie das Label darüber.
• Sagen Sie in Worten, was Pflicht ist, oder was nicht. Ein Sternchen allein muss man kennen. Sind fast alle Felder nötig, schreiben Sie (optional) hinter die wenigen, die es nicht sind. Unser eigenes Anfrageformular macht das, etwa bei Beschreibung (optional).
• Trennen Sie, was Sie getrennt brauchen. Vorname und Nachname in zwei Feldern bekommen jeweils ein eigenes Label.

Wie schreiben Sie einen Hinweistext?

Ein Hinweistext steht bei einem Feld und beantwortet die Frage, die das Label offenlässt. Meist ist es eine dieser drei:

• Warum fragen Sie das? Wer seine Daten angibt, will wissen, was damit passiert. In der Demo steht bei der E-Mail-Adresse: für unsere Antwort, sonst nichts.
• In welcher Form? Ein Datum, eine Telefonnummer, eine Postleitzahl oder eine Datei mit einer Höchstgröße. Das W3C nennt das ausdrücklich: Sagen Sie, welche Form Sie erwarten, besonders wenn sie von dem abweicht, was Menschen gewohnt sind.
• Was passiert danach? „Sie hören innerhalb von zwei Werktagen von uns“ nimmt die Frage weg, ob mit Ihrer Anfrage überhaupt etwas geschieht.

Ein Hinweistext kann einen Fehler auch verhindern, statt ihn zu beheben. Auf ArtsenPool, einer Plattform für Ärzte und Krankenhäuser, die noch nicht gestartet ist, warnt jedes Formular: keine medizinischen oder Patientendaten eingeben. Im Notfall: 112.

Halten Sie es aber kurz. Das W3C schreibt bei der Anforderung zu Labels und Anleitungen, dass zu viele Informationen oder Anweisungen genauso schaden können wie zu wenige. Beantworten Sie nur die Frage, die der Besucher hier wirklich hat.

Wie schreiben Sie eine Fehlermeldung?

Eine gute Fehlermeldung tut drei Dinge: Sie zeigt auf das Feld, sagt, was nicht stimmt, und sagt, wie man es behebt. In normalen Worten, ohne dem Besucher die Schuld zu geben.

Das NL Design System, eine offene Sammlung von Designsystemen der niederländischen Verwaltung, zu der unter anderem Gemeinden und die Behörden RVO und Logius beitragen, gibt genau dieses Beispiel. Nicht „Ungültige Eingabe“ oder „Dieses Feld ist ein Pflichtfeld“, sondern „Geben Sie eine gültige E-Mail-Adresse ein, zum Beispiel name@beispiel.nl.“ Oder: „Geben Sie die Hausnummer ein, damit wir Ihre Bestellung schicken können.“ Das Designsystem sagt auch: Geben Sie dem Nutzer nie die Schuld, und setzen Sie am Ende einen Punkt, damit ein Screenreader eine Pause macht.

Die britische Regierung geht in ihrem Designsystem noch einen Schritt weiter. Sie rät davon ab, valid oder invalid zu schreiben, weil diese Wörter nichts hinzufügen, und auch von sorry, please und lockeren Wörtern wie oops. Verwenden Sie die Worte des Labels in der Meldung, und lesen Sie sie laut vor: Klingt sie wie etwas, das Sie selbst sagen würden?

Wann zeigen Sie den Fehler?

Nicht, während jemand noch tippt. Davon raten das britische und das niederländische Designsystem beide ab. Das NL Design System nennt eine Meldung, die nach dem ersten Buchstaben erscheint, ärgerlich und verwirrend; die britische Richtlinie verweist auf Menschen, die langsamer tippen. Danach unterscheiden sie sich: Das britische prüft erst, wenn man weitergeht oder absendet, das niederländische auch, wenn man ein geändertes Feld verlässt. Wählen Sie eines und testen Sie es mit echten Menschen.

Lassen Sie nach einem Fehler die Eingabe stehen, schreibt die britische Richtlinie: Wer ein leeres Formular zurückbekommt, muss alles neu machen. Und stehen mehrere Fehler auf einer Seite, setzen Sie oben eine Zusammenfassung, neben die Meldung am Feld selbst. Das empfehlen beide Designsysteme.

Rot allein ist keine Fehlermeldung. Wer Farben schlecht unterscheidet, sieht einen roten Rahmen nicht. Schreiben Sie die Meldung in Worten, mit Farbe als Zusatz.

Was steht auf einem leeren Bildschirm und in einer Bestätigung?

Ein leerer Bildschirm ist eine Suche ohne Ergebnis oder eine Übersicht ohne Einträge. „Keine Ergebnisse“ stimmt, lässt den Besucher aber stehen. Sagen Sie, warum es leer ist und was er jetzt tun kann. Zum Beispiel: „Keine Ergebnisse für ‚Krone‘. Versuchen Sie ein anderes Wort oder sehen Sie alle Behandlungen an.“

Eine Bestätigung sagt drei Dinge: Es hat geklappt, was jetzt passiert und wann. Unser eigenes Anfrageformular sagt nach dem Absenden: Anfrage gesendet. Ihre Anfrage ist bei uns angekommen. Sie hören in der Regel innerhalb von zwei Werktagen von uns.

Bei einem Formular in Schritten: Fragen Sie nicht erneut, was der Besucher schon eingegeben hat. Wer in Schritt eins seine Adresse angegeben hat, will sie in Schritt drei nicht noch einmal tippen. Seit WCAG 2.2 ist das auch eine Anforderung.

Wie sieht der Unterschied aus, je nach Art des Textes?

Alles oben an einem Ort. Links, was man oft sieht, rechts eine Version, die die Frage des Besuchers beantwortet. Es sind Beispiele, keine festen Texte: Schreiben Sie sie in Ihren eigenen Worten und für Ihr eigenes Formular.

Was verlangt WCAG 2.2 von Ihrer Microcopy?

WCAG ist die internationale Richtlinie für barrierefreie Websites, vom W3C. Version 2.2 ist eine W3C-Empfehlung; der aktuelle Text stammt vom 12. Dezember 2024. Ein Teil der Anforderungen handelt wörtlich von Worten auf Buttons und in Formularen. Das sind die wichtigsten, mit der Stufe (A ist die erste Stufe, AA die zweite):

Zwei Dinge fallen auf, wenn Sie die Erläuterungen des W3C lesen. Erstens liegt die Latte für eine Fehlermeldung niedriger, als Sie denken: Laut der Erläuterung zu 3.3.1 genügt „Email is not valid“ schon, um den Fehler zu benennen. Wie man ihn behebt, fällt unter 3.3.3. Eine gute Meldung tut beides. Zweitens rät das W3C bei 2.5.3, den Namen im Code mit dem Text auf dem Button beginnen zu lassen, damit jemand mit Sprachsteuerung ihn mit genau diesen Worten auslösen kann.

Ob Ihre Organisation diese Anforderungen gesetzlich erfüllen muss, lesen Sie in unserem Beitrag zum Barrierefreiheitsgesetz. Wie Sie eine Website barrierefrei machen, steht unter barrierefreie Website.

Welcher Ton passt zur Microcopy?

Derselbe Ton wie auf dem Rest Ihrer Website, aber ruhiger. Ein paar Faustregeln:

• Wählen Sie eine Anrede, Siezen oder Duzen, und bleiben Sie dabei. Eine Website, die auf der Startseite duzt und in der Fehlermeldung siezt, klingt wie zwei verschiedene Schalter.
• Seien Sie direkt, und scherzen Sie nicht bei einem Fehler. Ein Augenzwinkern auf einer Seite, die es nicht gibt, kann passen. Wenn eine Zahlung scheitert oder eine Anmeldung nicht durchgeht, will jemand nur wissen, was er tun soll.
• Ein Wort für eine Sache. Legen Sie fest, welche Wörter Sie verwenden: Anfrage oder Angebotsanfrage, anmelden oder registrieren. Ein Designsystem legt fest, wie ein Button aussieht; halten Sie darin auch fest, wie er heißt.

Gute Microcopy kann einen vollen Bildschirm nicht retten. Weniger Felder, eine Frage pro Schritt und keine doppelten Meldungen geben den Worten Raum. Und sagen Sie ehrlich, warum Sie etwas fragen: Ehrlichkeit liest sich wie Ruhe.

Der Schlusstest ist einfach: Lesen Sie Ihr Formular laut vor. Klingt es wie ein Mensch am Empfang oder wie eine Systemmeldung von 2009? Sie hören es sofort.

Wie testen Sie, ob Ihre Microcopy funktioniert?

Ein Labor brauchen Sie dafür nicht:

1. Lesen Sie alles laut vor, vom ersten Button bis zur Bestätigung.
2. Füllen Sie das Formular falsch aus. Lassen Sie ein Pflichtfeld leer, tippen Sie eine E-Mail-Adresse ohne @, wählen Sie ein Datum in der Vergangenheit. Steht jeder Fehler in Worten beim richtigen Feld, und bleibt Ihre Eingabe stehen?
3. Machen Sie es auf einem Smartphone, mit einer Hand. Sehen Sie die Fehlermeldung, ohne zu scrollen?
4. Machen Sie es nur mit der Tastatur und einem Screenreader, etwa VoiceOver auf einem iPhone oder Mac oder NVDA unter Windows. Hören Sie das Label bei jedem Feld, die Fehlermeldung und die Bestätigung?
5. Geben Sie es jemandem, der Ihre Website nicht kennt, mit einer echten Aufgabe: anmelden, ein Angebot anfragen. Schauen Sie zu und sagen Sie nichts.
6. Sehen Sie in Ihre Statistik pro Schritt, falls Sie eine haben: Wo springen Menschen ab? Ändern Sie eine Sache auf einmal.

Bei einem UX-Audit gehen wir die Wege von der Landung bis zur Anfrage durch, mit Formularen und Texten. Beim UI/UX-Design bekommt jeder Button und jedes Feld seine Zustände, auch das, was erscheint, wenn etwas schiefgeht.

Wann das nicht gilt

Microcopy repariert kein Formular, das zu viel fragt. Fragen Sie zwölf Felder ab, wo vier genügen, streichen Sie zuerst Felder; bessere Labels machen ein langes Formular nicht kurz. Und ist Ihr Angebot oder Ihr Preis unklar, behebt das kein Buttontext. Beginnen Sie dann bei der Conversion-Optimierung.

Bei rechtlichen Texten, etwa der Einwilligung für Newsletter, Geschäftsbedingungen oder einer Datenschutzerklärung, zählt Genauigkeit mehr als Kürze. Ein kürzerer Satz kann dort etwas anderes bedeuten. Lassen Sie solche Texte von jemandem prüfen, der die Regeln kennt.

Was wir nicht wissen: Wir haben nicht gemessen, wie viele zusätzliche Anfragen bessere Microcopy auf unseren eigenen Websites oder denen von Kunden gebracht hat, und nennen deshalb keine Zahl. Die britischen Richtlinien sind für englischsprachige Behördendienste geschrieben, und die Richtlinien des NL Design System sind laut der Website selbst noch in der Beta. Und WCAG ist eine Untergrenze: Wer alle Anforderungen erfüllt, weiß damit noch nicht, ob Menschen den Text verstehen. Das wissen Sie erst, wenn Sie es sie ausprobieren lassen.

Möchten Sie wissen, wo Ihr Formular hakt? Schicken Sie uns den Link zu Ihrem Formular oder Ihrer Anfrageseite, dann schauen wir es uns an. Mehr dazu, wie wir Bildschirme und Formulare gestalten, lesen Sie unter UI/UX-Design, und was eine gründliche Prüfung bringt, unter UX-Audit. Sie arbeiten direkt mit Nawid zusammen; für jedes Projekt stellt er ein festes Team von Spezialisten zusammen.