Microcopy und Fehlermeldungen im eigenen Ton
Buttons, Fehlerzustände, Leerzustände, Tooltips, Onboarding — die Oberfläche besteht größtenteils aus Text, und die meisten Produktteams haben keinen eigenen UX-Writer. NN/g bezeichnet Schreiben als den wertvollsten Beitrag, den KI derzeit zur UX-Arbeit leistet, und die UX-Tools-Umfrage fand heraus, dass rund 75 % der KI-Nutzung von Designern auf Texten und Inhalten liegt, nicht auf Visuellem. Tonrichtige Varianten zum Vergleichen zu generieren, geht schneller, als auf eine leere Textebene zu starren.
Du bist UX-Writer und arbeitest innerhalb einer etablierten Produktstimme. Hier ist unser Voice-and-Tone-Guide: {{voice_and_tone}}. Hier ist das UI-Element und sein Kontext: {{component_context}}. Ziel-Leseniveau: {{reading_level}}. Schreibe drei unterschiedliche Optionen für diesen Text. Gib für jede Option an: - Den Text selbst (Button, Label, Fehlermeldung, Leerzustand oder Tooltip, je nach Fall). - Eine Einzeiler-Begründung, die sich auf den Voice-Guide bezieht. - Zeichenanzahl für alle längenbeschränkten Elemente. Regeln: - Klare, konkrete Sprache; kein Jargon, keine Füllwörter, keine Ausrufezeichen, außer der Voice-Guide erlaubt sie. - Barrierefreiheit: Schreibe für Screenreader — verlasse dich nie auf „hier klicken" oder Richtungshinweise wie „der Button rechts"; Link- und Button-Text soll die Aktion beschreiben. - Fehlermeldungen: Sag, was passiert ist und was als Nächstes zu tun ist; gib dem Nutzer nie die Schuld. - Beziehe dich nicht auf Funktionen, Limits oder Daten, die nicht in dem von mir gegebenen Kontext stehen. Wo eine konkrete Zahl, ein Name oder ein Limit gebraucht wird, setze [PRODUKT: bestätigen] ein, statt zu raten. Halte alle drei Optionen in derselben Stimme, aber wirklich unterschiedlich in der Formulierung, damit ich Ansätze vergleichen kann.
Tragen Sie Ihre Angaben ein — der Prompt aktualisiert sich live. Dann kopieren.
**Leerzustand — noch keine Projekte** Option A — „Hier ist noch nichts. Erstellen Sie Ihr erstes Projekt, um loszulegen." (70 Zeichen) Begründung: neutral, handlungsorientiert, passt zur ruhigen Stimme. Option B — „Hier erscheinen Ihre Projekte. Bereit, eines zu starten?" (56 Zeichen) Begründung: schafft eine Erwartung, sanftere Einladung. Option C — „Noch keine Projekte. Starten Sie eines mit [PRODUKT: bestätigen – Button-Beschriftung]." Begründung: am kürzesten; verlässt sich auf den echten Button-Text, statt ihn zu erraten. Alle drei vermeiden „hier klicken" und beschreiben die Aktion für Screenreader-Nutzer.
Der komplette Arbeitsablauf
- Fügen Sie Ihren Voice-and-Tone-Guide und den Kontext der Komponente ein.
- Generieren Sie drei Optionen und vergleichen Sie sie mit dem Guide.
- Ersetzen Sie jeden Platzhalter [PRODUKT: bestätigen] selbst durch den echten Wert.
- Lassen Sie den Gewinnertext eine Barrierefreiheitsprüfung durchlaufen (Kontrast, Screenreader-Formulierung).
- Fügen Sie ihn der Designdatei und Ihrer zentralen Content-Quelle hinzu.
Worauf Sie achten sollten
Barrierefreiheit gilt auch für Texte: WCAG deckt einfache Sprache sowie Link- und Button-Text ab, also verzichten Sie auf „hier klicken” und Richtungshinweise und achten Sie auf ein passendes Leseniveau. KI garantiert davon nichts — das müssen Sie sicherstellen.
Fügen Sie keine unveröffentlichten Produktnamen, Funktionen oder Roadmap-Details in Consumer-KI-Tools ein; NDA- und Vertraulichkeitspflichten gelten für Designs genauso wie für Dokumente.
Verlassen Sie sich zu stark auf KI, klingt am Ende jedes Produkt gleich — schützen Sie die eigene Produktstimme, indem Sie redigieren statt nur zu übernehmen.
Woher das stammt
Jeder Anwendungsfall auf dieser Website beruht auf echten Berichten, die UX-Designer aus der Praxis geteilt haben — nichts davon ist von uns erfunden.