CommunitySchreiben & Editierengithub.com

wensity/wensity-ui-copy

Schreibe die Wörter in einer Benutzeroberfläche: Überschriften, Buttons, Beschriftungen, Hilfetexte, Fehler, leere Zustände, Toasts, Bestätigungen, Onboarding- und Landingpage-Texte sowie realistische Beispielinhalte. Verwende es, wenn du nutzerorientierte Texte in einer UI schreibst oder überarbeitest, eine neue Seite oder Komponente mit Inhalten füllst, wenn der Text wie Marketing-Füllmaterial oder von einer KI geschrieben klingt, oder wenn der Nutzer nach besseren Formulierungen, Mikrokopie, CTA-Texten, Fehlermeldungen oder leeren Zuständen fragt. Überspringe es für Änderungen, die den vorhandenen Text beibehalten.

Was ist wensity-ui-copy?

Dieses Skill hilft Entwicklern und Designern, präzise und nutzerorientierte UI-Texte zu schreiben, die klar, hilfreich und frei von übertriebenen Marketing-Floskeln sind. Es bietet eine umfassende Anleitung für alle Textarten in einer Benutzeroberfläche – von Überschriften und Buttons über Fehlermeldungen bis hin zu leeren Zuständen und Toasts. Die Richtlinien legen besonderen Wert auf eine natürliche, knappe und aktive Sprache (z. B. „Änderungen speichern“ statt „Modifikationen persistieren“) und vermeiden typische KI-generierte Phrasen wie „nahtlos“, „revolutionieren“ oder „Ihre X auf die nächste Stufe heben“. Das Skill unterstützt alle Plattformen, die Markdown-basierte Skill-Definitionen akzeptieren, wie Claude Code, Cursor oder Codex. Es funktioniert, indem es eine Checkliste und konkrete Beispiele bereitstellt, die den Schreibprozess leiten – etwa die Regel, dass jeder Button mit einem Verb beginnen und das Ergebnis nennen soll („Rechnung erstellen“ statt „OK“), oder dass leere Zustände als Onboarding-Möglichkeit genutzt werden, indem sie erklären, was erscheinen wird, und die nächste Aktion anbieten.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/wensity/skills/tree/HEAD/skills/wensity-ui-copy

Installed? Explore more Schreiben & Editieren skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

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.

SchwachBesser
Ungültige EingabeGib ein Datum nach heute ein
Etwas ist schiefgelaufenWir konnten den Server nicht erreichen. Überprüfe deine Verbindung und versuche es erneut.
Fehler 403Du hast keinen Zugriff auf dieses Projekt. Bitte einen Besitzer, dich einzuladen.
Upload fehlgeschlagenDiese Datei hat 24 MB. Das Limit beträgt 10 MB.
Zahlung abgelehntDeine 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:

  1. Sage, was hier erscheinen wird: „Rechnungen, die du sendest, werden hier angezeigt.“
  2. Gib die eine Aktion, die ihn füllt: einen primären Button, „Rechnung erstellen“.
  3. 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.NumberFormat und Intl.DateTimeFormat (oder toLocaleString) 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.PluralRules oder einen Helfer, niemals „Datei(en)“.
  • Halte Zahlen und Einheiten mit einem geschützten Leerzeichen zusammen (10&nbsp;MB in 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.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Verwandte Skills