Wensity UI Copy (Deutsche Übersetzung)
Wörter sind Teil des Designs. Vage oder aufgeblähte Texte lassen eine polierte Oberfläche generisch wirken; klare, präzise Texte lassen eine schlichte Oberfläche vertrauenswürdig wirken. Der Test für jede Zeichenfolge: Hilft sie jemandem, etwas zu verstehen oder zu handeln?
1. Stil
- Klare Worte. Schreibe so, wie eine hilfsbereite Person es laut sagen würde. „Änderungen speichern“, nicht „Modifikationen persistieren“. „Dein Guthaben ist aufgebraucht“, nicht „Guthabenstand erschöpft“.
- Die Worte des Nutzers, nicht die des Systems. „Benachrichtigungen“, nicht „Webhook- Konfiguration“. Benenne Dinge nach dem, was Menschen damit tun.
- Kurz. Streiche jedes Wort, das die Bedeutung nicht verändert. Dann streiche noch einmal.
- Durchgängig Satzfall: Überschriften, Buttons, Menüpunkte, Tabs, Beschriftungen. „Neues Projekt erstellen“, nicht „Neues Projekt Erstellen“.
- Aktiv, an den Nutzer gerichtet. „Du hast keinen Zugriff auf dieses Projekt“, nicht „Der Zugriff auf dieses Projekt ist nicht erlaubt“. Wenn das System versagt hat, sag es klar: „Wir konnten deine Datei nicht speichern“, nicht „Die Datei konnte nicht gespeichert werden“.
- Ruhig. Keine Ausrufezeichen außer bei echten Erfolgen, keine Entschuldigungen bei Fehlern, keine Witze in Fehlerzuständen.
2. Wörter, die Texte generiert klingen lassen
Vermeide diese. Sie sagen nichts, was ein Leser überprüfen kann:
- Verben: freischalten, entfesseln, steigern, befähigen, optimieren, revolutionieren, transformieren, rationalisieren, nutzen, einsetzen, neu denken, in die Höhe schnellen lassen.
- Adjektive: nahtlos, mühelos, hochmodern, zukunftsweisend, erstklassig, robust, leistungsstark, intuitiv, innovativ, All-in-One.
- Phrasen: „In der heutigen schnelllebigen Welt“, „Bringen Sie Ihr X auf die nächste Stufe“, „Ob Sie ein X oder ein Y sind“, „Verabschieden Sie sich von“, „Nicht mehr suchen müssen“.
- Formen: drei Adjektive in Folge („Schnell. Sicher. Einfach.“), Mittelpunkt-
Listen (
Design · Bauen · Ausliefern) und Gedankenstriche irgendwo im Produkttext, einschließlich des Seiten-<title>, der Meta-Beschreibung und des Alt-Textes. Verwende einen Doppelpunkt, ein Komma oder zwei Sätze: „Ledgerline: Rechnungen in jeder Währung“.
Ersetze jedes durch eine konkrete Tatsache: was es tut, wie schnell, für wen, mit welchem Ergebnis. „Verkürzt einen 40-minütigen Bericht auf 2 Minuten“ ist besser als „Optimieren Sie Ihren Workflow“.
3. Überschriften
- Eine Überschrift sagt den Punkt, nicht das Thema. „Rechnungen werden 9 Tage schneller bezahlt“ ist besser als „Funktionen“. „Dein Arbeitsbereich ist leer“ ist besser als „Arbeitsbereich“.
- Keine Überzeilen. Setze keine kleine Großbuchstaben-Beschriftung über eine Überschrift („FUNKTIONEN“, „PREISGESTALTUNG“, „SO FUNKTIONIERT ES“). Schreibe eine Überschrift, die für sich allein steht.
- Seitentitel benennen die Seite, damit Leute wissen, wo sie sind: „Abrechnung“, „Teammitglieder“.
4. Buttons und Links
- Beginne mit einem Verb und nenne das Ergebnis: „Rechnung erstellen“, „Einladung senden“, „CSV exportieren“. Nicht „Absenden“, „OK“, „Ja“, „Hier klicken“, „Mehr erfahren“ allein.
- Der Button muss dem entsprechen, was als Nächstes passiert. Wenn der Button „Veröffentlichen“ sagt, sagt der Toast „Veröffentlicht“, und die Seite zeigt den veröffentlichten Zustand.
- Primär und Sekundär müssen klar unterschiedliche Aktionen sein: „Projekt löschen“ und „Abbrechen“, nicht „Ja“ und „Nein“.
- Ein bis drei Wörter sind ideal. Ein CTA kann auf fünf gehen, wenn er einen konkreten Nutzen hinzufügt („Kostenlos starten, keine Karte“).
- Link-Text ergibt allein Sinn (Screenreader listen Links aus dem Kontext): „Lies die API-Anleitung“, nicht „hier“.
- Zerstörerische Aktionen nennen die Sache: „3 Dateien löschen“, „Sam aus Team entfernen“.
5. Formulare
- Beschriftungen über den Feldern, immer sichtbar. Platzhaltertext ist keine Beschriftung; er verschwindet, wenn die Eingabe beginnt.
- Platzhalter zeigen das Format, keine Anweisungen:
[email protected],MM / JJ. Lasse sie weg, wenn die Beschriftung ausreicht. - Hilfetext unter dem Feld für Regeln, die Leute vor der Eingabe brauchen: „Mindestens 12 Zeichen“.
- Markiere optionale Felder, nicht Pflichtfelder, wenn die meisten Felder Pflichtfelder sind: „Firma (optional)“.
- Validiere bei Verlust des Fokus oder beim Absenden, nicht bei jedem Tastendruck. Zeige den Fehler neben dem Feld an, zu dem er gehört.
6. Fehler
Jeder Fehler beantwortet zwei Fragen: Was ist passiert und was jetzt zu tun ist.
| Schwach | Besser |
|---|---|
| Ungültige Eingabe | Gib ein Datum nach heute ein |
| Etwas ist schiefgelaufen | Wir konnten den Server nicht erreichen. Überprüfe deine Verbindung und versuche es erneut. |
| Fehler 403 | Du hast keinen Zugriff auf dieses Projekt. Bitte einen Besitzer, dich einzuladen. |
| Upload fehlgeschlagen | Diese Datei hat 24 MB. Das Limit beträgt 10 MB. |
| Zahlung abgelehnt | Deine Karte wurde abgelehnt. Versuche eine andere Karte oder kontaktiere deine Bank. |
- Gib dem Nutzer nie die Schuld („Du hast eine ungültige E-Mail eingegeben“). Beschreibe die Lösung („Gib eine E-Mail wie [email protected] ein“).
- Halte Codes und Stacktraces aus der Nachricht heraus. Gib eine Referenz-ID am Ende an, wenn der Support eine braucht.
- Behalte, was der Nutzer eingegeben hat. Leere niemals ein Formular, weil ein Feld fehlgeschlagen ist.
7. Leere Zustände
Ein leerer Zustand ist das Erste, was ein neuer Benutzer sieht. Behandle ihn als Onboarding:
- Sage, was hier erscheinen wird: „Rechnungen, die du sendest, werden hier angezeigt.“
- Gib die eine Aktion, die ihn füllt: einen primären Button, „Rechnung erstellen“.
- Optional: ein Link zum Importieren, eine Vorlage oder eine kurze Anleitung.
Für leere Zustände bei „keinen Ergebnissen“ sage, wonach gesucht wurde und wie die Suche erweitert werden kann: „Keine Ergebnisse für ‚invioce‘. Überprüfe die Schreibweise oder setze Filter zurück.“
8. Laden, Erfolg und Toasts
- Laden: Sage, was passiert, wenn es länger als eine Sekunde dauert: „Bericht wird erstellt…“. Verwende das Auslassungszeichen.
- Erfolgs-Toasts: Vergangenheit der Aktion plus das Objekt: „Einladung an [email protected] gesendet“, „Projekt gelöscht. Rückgängig machen“.
- Biete Rückgängig machen anstelle eines Bestätigungsdialogs für umkehrbare Aktionen. Frage nach Bestätigung nur, wenn die Aktion nicht rückgängig gemacht werden kann.
- Bestätigungsdialoge: Die Frage im Titel („‚Q3-Bericht‘ löschen?“), der Text beschreibt die Konsequenz („Dies entfernt ihn für alle. Du kannst dies nicht rückgängig machen.“), die Buttons nennen die Aktion („Bericht löschen“ / „Abbrechen“).
9. Zahlen, Daten und Einheiten
- Verwende Ziffern: „3 Dateien“, nicht „drei Dateien“.
- Formatiere mit der Locale des Nutzers:
Intl.NumberFormatundIntl.DateTimeFormat(odertoLocaleString) anstelle von selbst gebauten Zeichenketten. - Relative Zeit für aktuelle Ereignisse („vor 2 Min“), absolute Daten für ältere („4. März“) und den vollständigen Zeitstempel in einem Tooltip.
- Pluralisiere richtig: „1 Datei“, „2 Dateien“, „0 Dateien“. Verwende
Intl.PluralRulesoder einen Helfer, niemals „Datei(en)“. - Halte Zahlen und Einheiten mit einem geschützten Leerzeichen zusammen (
10 MBin HTML,"10\u00A0MB"in JavaScript), damit sie nie auseinander umbrechen.
10. Realistische Platzhalterinhalte
Wenn ein Design ohne echte Inhalte erstellt wird, schreibe Inhalte, die echt aussehen:
- Konkrete Namen und Daten: „Maya Chen, Produktdesignerin bei Northwind“, „12.480,00 $“, „Rechnung INV-2041“. Nicht „Max Mustermann“, „XX €“, „Lorem ipsum“.
- Realistische Längen, einschließlich einiger langer, damit das Layout getestet ist: ein 40-Zeichen-Name, eine 3-zeilige Beschreibung neben einer 1-zeiligen.
- Erfinde nie Beweise. Keine erfundenen Kundenlogos, Sternbewertungen, Benutzerzahlen
oder Erfahrungsberichte, die als echt präsentiert werden. Verwende markierte Platzhalter
(
[Kundenstatement],[Logo]) oder frage den Benutzer nach den echten. - Passe an die Produktwelt an. Die Beispieldaten eines Entwicklertools sind Repos und Deployments; die einer Klinik-App sind Termine und Patienten.
11. Barrierefreiheit im Text
- Jeder nur aus Symbolen bestehende Button erhält einen zugänglichen Namen:
aria-label="Dialog schließen". - Alt-Text beschreibt, was ein Bild zeigt, wenn es Informationen trägt
(„Balkendiagramm: Umsatz seit Januar um 24 % gestiegen“). Dekorative Bilder erhalten
alt="". - Verlasse dich nicht nur auf Farbwörter („klicke den grünen Button“).
- Schreibe Abkürzungen beim ersten Mal aus, es sei denn, das Publikum verwendet sie täglich.
12. Überprüfe vor dem Abschluss
- Keine Füllwörter aus Abschnitt 2, keine Drei-Adjektiv-Taglines, keine Gedankenstriche in Benutzeroberflächenstrings.
- Jede Überschrift sagt einen Punkt; keine Überzeilen.
- Jeder Button beginnt mit einem Verb und nennt sein Ergebnis.
- Jeder Fehler sagt, was passiert ist und was zu tun ist.
- Jeder leere Zustand erklärt sich selbst und bietet die nächste Aktion.
- Durchgängig Satzfall.
- Beispielinhalte sind spezifisch, in der Länge variiert und enthalten keine erfundenen Beweise.
- Nur-symbolische Bedienelemente und bedeutungsvolle Bilder haben zugänglichen Text.