Ein Interface kann optisch perfekt wirken und trotzdem verwirren. Oft liegt das nicht an Farben oder Abständen, sondern an den Texten: unklare Buttons, vage Fehlermeldungen oder Hinweise, die zu spät kommen. Gute UI-Texte (kurze Texte direkt im Interface) geben Orientierung, reduzieren Fehler und machen Abläufe spürbar leichter.
In der Praxis geht es dabei nicht um „schöne Worte“, sondern um Klarheit: Was passiert als Nächstes? Was wird erwartet? Welche Konsequenz hat ein Klick? Dieser Leitfaden zeigt, wie UI-Text systematisch entsteht, wie er zum Layout passt und wie typische Stolperfallen vermieden werden.
Was UI-Texte leisten müssen: Orientierung statt Deko
UI-Text ist alles, was Nutzer in einer Oberfläche lesen: Button-Beschriftungen, Feldlabels, Hilfetexte, Fehlermeldungen, Bestätigungen, Leerstates (Zustände ohne Inhalt) oder kurze Hinweise in Dialogen. Diese Texte sind Teil der Bedienung – nicht nur „Inhalt“.
Vier Aufgaben, die jeder UI-Text erfüllen sollte
- Orientierung: Nutzer verstehen, wo sie sind und was sie hier tun können.
- Handlungsführung: Der nächste Schritt ist eindeutig (ohne Rätselraten).
- Fehlervermeidung: Texte helfen, Probleme vorher zu verhindern (z. B. Eingabeformat erklären).
- Vertrauen: Sprache wirkt zuverlässig, transparent und respektvoll.
Ein schneller Selbsttest: Wenn ein Button „OK“ heißt, fehlt meist Kontext. „OK“ ist keine Handlung – es ist nur Zustimmung. Besser ist eine klare Aktion wie „Termin buchen“ oder „Änderungen speichern“.
Microcopy planen: Ton, Begriffe, Konsistenz
Bevor einzelne Texte entstehen, braucht es ein kleines Set an Regeln. Das verhindert, dass sich die Oberfläche „zusammengewürfelt“ anfühlt.
Wording: Nutzerbegriffe schlagen interne Sprache
Viele Teams schreiben aus ihrer Systemlogik heraus: „Datensatz“, „Anfrageobjekt“, „Ticket erstellen“. Nutzer denken eher in Aufgaben: „Kontakt hinzufügen“, „Anfrage senden“, „Problem melden“. Eine einfache Methode: Begriffe sammeln, die im Team genutzt werden, und daneben Nutzerbegriffe notieren. In UI-Texten sollten die Nutzerbegriffe gewinnen – interne Begriffe können im Backend bleiben.
Tonfall: freundlich, aber nicht kumpelhaft
Ein konsistenter Ton spart Erklärungen. Die meisten Webprodukte fahren gut mit: klar, direkt, respektvoll. Humor funktioniert nur, wenn er zur Marke passt und nie auf Kosten des Nutzers geht – besonders nicht bei Fehlern oder sensiblen Themen (Zahlung, Daten, Kündigung).
Konsistenz: gleiche Handlung, gleiche Worte
Wenn „Speichern“ an anderer Stelle „Übernehmen“ heißt, entsteht Unsicherheit. Konsistenz heißt nicht Einheitsbrei, sondern Wiedererkennen: gleiche Aktion, gleiches Verb. Das ist auch eine Brücke zur komponentenbasierten Arbeit: Wenn Buttons und Dialoge als Komponenten gedacht sind, sollten ihre Standardtexte mitgepflegt werden. Passend dazu hilft der Blick auf komponentenbasiertes Webdesign, weil sich dort Text-Patterns gut standardisieren lassen.
Button-Texte, die Entscheidungen leichter machen
Buttons sind Mini-Entscheidungen. Je unklarer der Text, desto eher zögern Nutzer – oder klicken falsch.
Verben statt Zustände
Statt „Weiter“, „OK“, „Senden“ funktioniert oft besser: „Konto erstellen“, „Rechnung herunterladen“, „Nachricht senden“. Das beschreibt die Wirkung des Klicks und reduziert das Risiko, dass Nutzer „blind“ bestätigen.
Primär- und Sekundäraktionen sauber trennen
In Dialogen stehen oft zwei Buttons: eine Hauptaktion und ein Abbruch. Typischer Fehler: Beide wirken gleich wichtig oder sind sprachlich zu ähnlich („Abbrechen“ vs. „Schließen“). Klare Paarungen sind zum Beispiel:
- „Änderungen speichern“ / „Nicht speichern“
- „Termin buchen“ / „Zurück“
- „Zahlung bestätigen“ / „Abbrechen“
Wichtig: „Zurück“ ist nur sinnvoll, wenn wirklich ein vorheriger Schritt folgt. Sonst besser „Schließen“ (Fenster zu) oder „Abbrechen“ (Vorgang stoppen).
Kleine Zusätze nur, wenn sie wirklich helfen
Zusätze wie „(empfohlen)“ oder „in 2 Minuten“ können nützlich sein, aber sie sollten wahr sein und nicht wie Marketing wirken. Wenn Informationen nötig sind, gehören sie lieber als kurzer Satz in den Dialogtext statt in den Button.
Formulartexte: weniger Fehler, weniger Frust
Formulare sind der Ort, an dem Microcopy direkt Geld, Leads oder Supportkosten beeinflusst. Gute Texte helfen, Eingaben richtig zu machen – ohne dass jemand die Fehlermeldung überhaupt sieht.
Labels sind nicht optional
Placeholder (grauer Beispieltext im Feld) ist kein Ersatz für ein Label. Placeholder verschwindet beim Tippen – und damit auch die Orientierung. Ein Label bleibt sichtbar und macht auch bei Autocomplete oder späteren Korrekturen das Feld klar. Wer tiefer in Formularlogik und Fehlerfälle einsteigen will, findet ergänzende Praxis in Formular-UX optimieren.
Hilfetexte: kurz, konkret, vor der Eingabe
Hilfetexte sollten erklären, was erwartet wird, nicht was „nicht“ erlaubt ist. Beispiele:
- Statt: „Ungültiges Passwort“ lieber: „Mindestens 8 Zeichen, eine Zahl“.
- Statt: „Bitte korrekt ausfüllen“ lieber: „Postleitzahl mit 5 Ziffern“.
Fehlermeldungen: sagen, was passiert ist – und wie es weitergeht
Eine gute Fehlermeldung enthält drei Bausteine: Problem, Ursache (falls sicher), Lösung. Und sie vermeidet Schuldzuweisungen („Sie haben… falsch…“). Besser ist eine neutrale Form: „Die Postleitzahl hat 4 Ziffern. Bitte 5 Ziffern eingeben.“
Systemmeldungen, Leerstates und Bestätigungen
Nutzer brauchen nicht nur Texte beim Eingeben, sondern auch beim Warten, nach Aktionen oder wenn noch nichts da ist.
Ladezustände: Erwartung klar machen
„Lädt…“ ist besser als nichts, aber oft zu vage. Wenn möglich, hilft ein Hinweis auf den Kontext: „Dokument wird hochgeladen…“ oder „Verbindung wird hergestellt…“. Bei längeren Prozessen beruhigt Transparenz: „Das kann einen Moment dauern.“
Leerstates: erklären, warum es leer ist, und was zu tun ist
Ein leerer Bildschirm wirkt wie ein Fehler. Gute Leerstates beantworten zwei Fragen: Warum ist hier nichts? Was kann jetzt passieren? Beispiel: „Noch keine Projekte angelegt. Neues Projekt erstellen, um Aufgaben zu planen.“
Bestätigungen: nicht nur „Erfolg“, sondern nächste Schritte
Nach dem Absenden eines Formulars hilft mehr als „Danke“. Nützlich sind konkrete Infos: „Nachricht wurde gesendet. Antwort folgt per E-Mail.“ oder „Buchung bestätigt. Termin im Kalender speichern.“ Solche Texte reduzieren Nachfragen.
Kurzer Ablauf, der in Teams wirklich funktioniert
Microcopy wird oft zu spät geschrieben: wenn das UI schon fertig ist. Dann quetschen Texte ins Layout, statt das Layout Texte zu unterstützen. Besser ist ein kleiner Prozess, der sich in Design- und Entwicklungsarbeit integrieren lässt.
So lässt sich UI-Text in den Designprozess einbauen
- Pro Screen die wichtigsten Entscheidungen notieren (z. B. „Zahlung starten“, „Kündigung bestätigen“).
- Für jede Entscheidung eine klare Primäraktion formulieren (Verb + Ergebnis).
- Fehlerfälle sammeln: Was geht häufig schief? Welche Eingaben sind missverständlich?
- Texte in der Gestaltung früh einsetzen, damit Abstände und Zeilenumbrüche realistisch sind.
- Vor dem Handoff eine kurze Textprüfung machen (Konsistenz, Ton, Verständlichkeit).
Für eine saubere Übergabe an Entwickler hilft es, Texte genauso verbindlich zu behandeln wie Maße oder Zustände. Dazu passt der Ansatz aus Design-Handoff für Entwickler, weil dort Spezifikationen und Varianten klar dokumentiert werden.
Typische Microcopy-Fallen (und bessere Alternativen)
Unklare Referenzen: „Hier“, „Klicken Sie“
„Klicken Sie hier“ sagt nicht, wohin es geht. Linktexte sollten das Ziel nennen: „AGB lesen“, „Passwort zurücksetzen“, „Rechnung herunterladen“. Das hilft auch bei Barrierefreiheit (z. B. bei Screenreadern).
Negationen und Doppelformen
„Nicht deaktivieren“ ist schwer zu verarbeiten, weil das Gehirn erst „deaktivieren“ liest. Besser: „Aktiv lassen“ oder „Deaktivierung abbrechen“. Besonders in Bestätigungsdialogen verhindert das Fehlklicks.
Zu viel Text, weil das UI unklar ist
Wenn ein Screen lange Erklärtexte braucht, stimmt oft die Struktur nicht. Dann lohnt es sich, die Informationshierarchie zu prüfen (Was muss zuerst verstanden werden?). Hier kann eine bessere Seitenstruktur helfen – beispielsweise durch saubere Priorisierung im sichtbaren Bereich, wie sie in Above the Fold im Webdesign beschrieben wird.
Ein kleines Vergleichsbild: kurz vs. hilfreich
| Stelle im UI | Unklar | Besser |
|---|---|---|
| Button | „Weiter“ | „Adresse bestätigen“ |
| Fehlermeldung | „Eingabe ungültig“ | „Bitte E-Mail im Format name@domain.de eingeben“ |
| Leerer Zustand | „Keine Daten“ | „Noch keine Favoriten. Artikel als Favorit markieren, um sie hier zu sehen.“ |
| Bestätigung | „Erfolg“ | „Profil gespeichert. Änderungen sind sofort aktiv.“ |
Prüffragen für den letzten Schliff vor dem Release
Verständlichkeit im schnellen Scan
- Erkennt man pro Screen in wenigen Sekunden, worum es geht?
- Steht die wichtigste Aktion sprachlich im Vordergrund?
- Sind Fachbegriffe erklärt oder ersetzt?
Konsistenz über das Produkt hinweg
- Heißt die gleiche Aktion überall gleich?
- Wirken Dialoge wie aus einem Guss (Ton, Satzbau, Zeichensetzung)?
- Gibt es widersprüchliche Begriffe (z. B. „Konto“ vs. „Profil“)?
Zugänglichkeit und Respekt
- Vermeiden die Texte Druck und Schuld („Sie haben… falsch…“)?
- Funktionieren Linktexte ohne Kontext („mehr erfahren“ allein ist selten gut)?
- Ist die Sprache für alle verständlich, auch ohne Produktwissen?
Wenn diese Punkte sitzen, wird Microcopy zu einem echten Bedien-Element: Sie spart Erklärungen, reduziert Unsicherheit und macht Abläufe messbar reibungsloser – ganz ohne visuelle Lautstärke.
