UX Writing: Wie schreibt man gute Mikrotexte?

Kurz gesagt

UX Writing behandelt jedes Wort auf dem Bildschirm als Teil des Designs. Eine Button-Beschriftung wirkt wie Farbe und Abstand: Sie sagt Nutzern, was passieren wird.

• Mikrotexte sind die kurzen Texte der Oberfläche. Dazu gehören Buttons, Fehler, leere Zustände, Bestätigungsdialoge und Platzhalter.
• Ein guter Mikrotext ist beim ersten Lesen klar und führt zum nächsten Schritt.
• Im Deutschen kommen zwei Aufgaben dazu: die Anrede auf jedem Screen gleich halten und Namen in Variablen richtig beugen.

Was ist UX Writing, was macht ein UX Writer?

Die Nielsen Norman Group (NN/g) beschreibt UX Writing als durchdachtes Schreiben, das Kontext, Bedürfnisse und Verhalten der Menschen berücksichtigt. Laut NN/g teilt diese Arbeit viele Fähigkeiten mit visuellem Design und Interaktionsdesign. Wer schreibt, kommuniziert mit Wörtern statt mit Pixeln.

Wer als UX Writer arbeitet, schreibt diese Texte zusammen mit dem Design. Zuerst geht es darum, was Nutzer in diesem Moment wissen. Dann wird der nächste Schritt mit möglichst wenigen Wörtern beschrieben. Werbetexte gehören nicht dazu, denn Nutzer haben das Produkt schon geöffnet und wollen eine Aufgabe erledigen.

In kleinen Teams gibt es oft keinen eigenen UX Writer, dann schreibt das Design die Texte. Ich schreibe Mikrotexte schon im Wireframe, denn das Layout eines Screens ändert sich mit dem Text.

Arten von Mikrotexten

Ein Mikrotext ist ein kurzer Text, der auch allein gelesen funktionieren muss. Diese fünf Arten begegnen mir am häufigsten:

Buttons und Links

NN/g empfiehlt für Befehlsnamen höchstens 2 bis 4 Wörter und einen Anfang mit dem Verb. Die Beschriftung soll zeigen, was nach dem Klick passiert. Deshalb schreibe ich „Änderungen speichern“ statt „Absenden“.

Fehlermeldungen

Eine Fehlermeldung sagt, was passiert ist und wie man es behebt. Dieses Thema behandle ich mit Beispielen im Muster zu Fehlermeldungen.

Texte für leere Zustände

Der Text in einer leeren Liste erklärt, warum sie leer ist und was Nutzer tun können. Arten und Beispiele stehen im Muster zum leeren Zustand.

Bestätigungsdialoge

Jakob Nielsen rät, in Bestätigungsdialogen statt allgemeinem Ja und Nein Buttons zu nutzen, die die Folge jeder Wahl nennen. Wer nur „Sind Sie sicher?“ gefragt wird, klickt laut Nielsen ohne Nachdenken auf Ja. Der Dialog soll benennen, was gelöscht wird, und die Folge sagen.

Nielsen warnt außerdem: Erscheint der Dialog zu oft, lesen Menschen die Frage nicht mehr. Heben Sie ihn für Aktionen mit ernsten Folgen auf, die sich nicht rückgängig machen lassen. Wo es geht, bieten Sie Rückgängig an.

Platzhalter

Ein Platzhalter (Placeholder) ist der blasse Text in einem leeren Feld. Der NN/g-Artikel von Katie Sherwin hält es für schädlich, den Platzhalter als Label zu nutzen. Sobald man tippt, verschwindet der Text, und man muss sich merken, was gefragt war.

Laut demselben Artikel hat der blassgraue Text wenig Kontrast, und manche Screenreader lesen Platzhalter nicht vor. Die empfohlene Lösung: Label und Hinweis sichtbar außerhalb des Felds. Zum Aufbau von Formularen lesen Sie die Seite zum Formulardesign.

Prinzipien guter Mikrotexte

Die Quellen, die ich gelesen habe, nutzen andere Wörter, kommen aber zum selben Ergebnis. Ich habe die Prinzipien in diesen Überschriften gesammelt.

Klar

NN/g sagt, einfache Sprache muss beim ersten Lesen verständlich sein. Fachjargon schreiben Sie nur, wenn Ihre Zielgruppe ihn ohnehin nutzt. Auch die Kommunikationsprinzipien von Googles Material raten zu einfacher, direkter Sprache, ohne Jargon und ohne erfundene Funktionsnamen.

Kurz

Material formuliert es so: kurz, aber nicht roboterhaft. Kurze Texte sind dort kleine Abschnitte, die man beim Überfliegen erfasst. Kürzen Sie, ohne den Sinn zu verlieren. Reicht „Speichern“ nicht, nennen Sie auch das Objekt.

Nützlich

Material empfiehlt, nur die Details zu zeigen, die für die Aufgabe nötig sind. Überlegen Sie bei einem Dialog oder einer Benachrichtigung, welche Information die Aktion erklärt. Im Fehlerfall darf sich auch der Ton ändern: von locker und gesprächig zu unterstützend und genau.

Nutzen Sie für dieselbe Funktion auf jedem Screen dasselbe Wort. Wenn Sie ein Bedienelement erwähnen, nennen Sie seine Beschriftung. Ich schreibe „Tippen Sie auf Speichern“ statt „Tippen Sie auf den Button unten rechts“.

Satzanfang statt Title Case

Aus englischen Vorlagen rutscht oft die Großschreibung jedes Worts in deutsche Oberflächen: „Jetzt Kostenlos Testen“. Ich schreibe Buttons, Tabs und Überschriften wie einen Satz. Groß sind nur das erste Wort und die Substantive: „Jetzt kostenlos testen“.

Live-Beispiel: vier Texte umschreiben

Mikrotexte umschreiben

• Button

  Der Button unter dem Formular „Profil bearbeiten“.

  Schwache Version

  NameAnna Schmidt

  StadtLeipzig

  Absenden

  Empfohlene Version

  NameAnna Schmidt

  StadtLeipzig

  Änderungen speichern

  Was besser ist: Beginnt mit dem VerbSagt, was passiert

• Bestätigungsdialog

  Der Dialog, bevor ein Ordner gelöscht wird.

  Schwache Version

  Sind Sie sicher?

  Diese Aktion kann nicht rückgängig gemacht werden.

  NeinJa

  Empfohlene Version

  Ordner „Rechnungen März“ löschen?

  Die 12 Dateien darin werden ebenfalls gelöscht. Das lässt sich nicht rückgängig machen.

  AbbrechenOrdner löschen

  Was besser ist: Nennt, was gelöscht wirdSagt die FolgeButtons benennen die Aktion

• Fehler

  Der Text, wenn die Karte im Bezahlschritt abgelehnt wird.

  Schwache Version

  Kartennummer

  •••• •••• •••• 4821

  Fehler 402: Vorgang konnte nicht ausgeführt werden.

  Empfohlene Version

  Kartennummer

  •••• •••• •••• 4821

  Diese Karte ist abgelaufen. Versuchen Sie es mit einer anderen Karte.

  Was besser ist: Grund statt CodeSchlägt eine Lösung vor

• Platzhalter

  Das Telefonfeld im Lieferformular.

  Schwache Version

  Geben Sie Ihre Telefonnummer ein

  Empfohlene Version

  Mobilnummer

  Zum Beispiel 0151 23456789. Der Kurier ruft diese Nummer vor der Lieferung an.

  Was besser ist: Label außerhalb des FeldsHinweis verschwindet beim Tippen nichtSagt, wofür die Nummer ist

Alle vier Texte sind von mir erfundene Beispiele und stammen aus keinem echten Produkt. Ein Druck auf den Button zeigt die empfohlene Version und was besser geworden ist. Ein zweiter Druck bringt die schwache Version zurück.

Bei allen vier Beispielen habe ich mit derselben Frage begonnen: Was tun Nutzer, nachdem sie diesen Text gelesen haben? Die schwachen Versionen beschreiben den Zustand des Systems. Die empfohlenen Versionen sagen Nutzern den nächsten Schritt.

Anrede: du oder Sie?

Im Englischen deckt „you“ beide Anreden ab, im Deutschen müssen Sie wählen. Meine Regel: Wählen Sie eine und halten Sie sie auf jedem Screen gleich. Ein häufiger Fehler ist eine Überschrift mit „Sie“ und ein Hinweis mit „du“.

Wie Sie die Anrede festlegen und im Team festhalten, beschreibe ich im Ratgeber zur Tonalität. Kurze Buttons in der Ich-Form wie „Mein Konto erstellen“ funktionieren mit beiden Anreden.

Laut Material ist im Englischen die zweite Person meist direkter und klarer. Die erste Person passt, wenn Besitz betont werden soll, aber beide sollen nicht im selben Ausdruck gemischt werden. Schreiben Sie „Erstellen Sie Ihr Konto“ oder „Mein Konto erstellen“, nicht „Erstellen Sie mein Konto“.

Namen in Variablen: das Problem mit {name}s

Dieser Fehler begegnet mir in deutschen Oberflächen oft. Die Entwicklung schreibt eine feste Vorlage wie {name}s Warenkorb. Bei Anna klappt das, bei Lukas steht auf dem Screen „Lukass Warenkorb“.

Im Englischen funktioniert „{name}’s cart“ mit jedem Namen. Im Deutschen hängt die Endung vom letzten Buchstaben des Namens ab. Was in der Übersetzungsdatei wie eine Zeile aussieht, ist eine kleine Grammatikaufgabe.

Die Regel

Der Duden fasst die Regel so zusammen:

1. Endet die Grundform des Namens auf s, ss, ß, tz, z, x oder ce, steht im Genitiv statt des -s nur ein Apostroph: Lukas’, Max’, Moritz’. Der Duden nennt dazu Beispiele wie „Marx’ Philosophie“ und „Maurice’ Freundin“.
2. Sonst steht das Genitiv-s ohne Apostroph: „Brechts Dramen“, also auch „Annas Warenkorb“.
3. Steht ein Artikel oder Pronomen vor dem Namen, gibt es nie einen Apostroph: „die Streiche unseres kleinen Tobias“.

Die Regel löst nicht jeden Fall. „Andreas Warenkorb“ ist für Andrea richtig, liest sich aber wie der Männername Andreas. Einen Apostroph wie in „Andrea’s“ erlaubt der Duden nur, wenn der Name mit dem Substantiv einen Eigennamen bildet, etwa „Andrea’s Kiosk“. In einer Oberfläche hilft hier nur ein anderer Satz.

Genitiv-Rechner für Namen

Die richtigen Formen nach der Regel:

Name	Genitiv	Warum
Anna	Annas	Endet auf a: Genitiv-s ohne Apostroph.
Lukas	Lukas’	Endet auf s: nur der Apostroph.
Max	Max’	Endet auf x: nur der Apostroph.
Moritz	Moritz’	Endet auf tz: nur der Apostroph.
Maurice	Maurice’	Endet auf ce: nur der Apostroph, Duden nennt genau dieses Beispiel.
Andrea	Andreas	Regelgerecht, liest sich aber wie der Name Andreas. Hier hilft nur ein anderer Satz.

Die Regel ist einfach: Endet der Name auf s, ss, ß, tz, z, x oder ce, steht nur ein Apostroph, sonst ein -s ohne Apostroph. Die Namen und der Satz sind meine Beispiele. Bei Namen wie Andrea hilft die Regel nicht weiter, da hilft nur ein anderer Satzbau.

Wie lösen Sie es mit der Entwicklung?

Ich schlage zwei Wege vor. Der erste: Bauen Sie den Satz so, dass er keinen Genitiv braucht. Statt „Annas Warenkorb“ schreiben Sie „Warenkorb von Anna“ oder „Ihr Warenkorb“. Das ist meist die robusteste Lösung.

Ist der Genitiv nötig, lassen Sie ihn im Code nach der Regel oben berechnen. Prüfen Sie dazu Namen mit Endungen wie -s, -x, -tz und -ce. Das gleiche Problem haben Zahlen: „1 Dateien“ ist genauso falsch. Hier hilft die Unterscheidung von Singular und Plural im Code statt einer festen Vorlage.

Großbuchstaben und das ß

In Großbuchstaben wird das ß traditionell zu SS, laut Duden „STRASSE, AUSSEN, FUSSBALL“. Daneben gibt es einen Großbuchstaben ẞ, dessen Verwendung freigestellt ist: „STRAẞE“.

Das betrifft Oberflächen, sobald Sie Text per CSS in Großbuchstaben setzen. MDN beschreibt, dass text-transform: uppercase sprachspezifische Regeln beachtet und im Deutschen aus ß ein SS macht. Der Browser liest die Sprache aus dem Attribut lang, also gehört lang="de" auf die Seite.

Bei Namen kann die Umwandlung Daten verfälschen. Aus „Heinz Große“ wird „HEINZ GROSSE“, und ein Abgleich mit „Grosse“ ist plötzlich nicht mehr eindeutig. Der Duden erlaubt deshalb in Dokumenten bei Namen auch „HEINZ GROßE“. Ich setze Namen und Adressen in Formularen und Bestätigungen nie per CSS in Großbuchstaben.

Mikrotext-Check vor dem Release

Bevor ein Screen live geht, lese ich die Texte mit diesen Fragen einzeln durch:

• Beginnt jeder Button mit dem Verb und sagt, was nach dem Klick passiert?
• Nennt der Bestätigungsdialog, was gelöscht oder geändert wird? Stehen auf den Buttons noch „Ja“ und „OK“?
• Sagt der Fehlertext Grund und Lösung, oder zeigt er nur einen Code?
• Hat jedes Feld ein sichtbares Label? Ersetzt ein Platzhalter das Label?
• Ist die Anrede überall gleich?
• Wurden Texte mit Variablen mit Namen auf -s, -x und -tz und mit der Zahl 1 getestet?
• Bleiben Namen und Adressen in Großbuchstaben unverändert, oder wird aus ß plötzlich SS?

Am häufigsten übersprungen werden die letzten beiden Fragen. Heißt der Beispielname in der Designdatei Anna, sieht die Vorlage {name}s richtig aus. Der Fehler zeigt sich erst mit einem echten Nutzernamen.

Meine Notiz

In Audits notiere ich Textprobleme meist als Designprobleme, denn Nutzer trennen die beiden nicht. Ein Bestätigungsbutton mit „OK“ kann für mich genauso zu Fehlern führen wie ein Button an der falschen Stelle.

In deutschen Produkten sehe ich am häufigsten gemischte Anrede und feste Genitiv-Vorlagen. Beides fällt in der Übersetzungsdatei nicht auf und zeigt sich erst mit echten Daten auf dem Screen. Deshalb teste ich Texte mit realistischen Namen wie Lukas und Moritz.

Einem neuen Team empfehle ich als ersten Schritt einen einseitigen Textleitfaden. Dort stehen die Entscheidung zur Anrede und die häufigsten Button-Beschriftungen. Wenn Sie einen Blick von außen auf die Mikrotexte Ihres Produkts möchten, prüft das UX Audit auch diese.