# Design:content

> Audit, improve, or generate accessible UX content (microcopy, UI text, longer explanatory copy) in German and English. Use this skill whenever the user shares any interface text, UX copy, button labels, error messages, onboarding flows, empty states, tooltips, or longer product/documentation text and asks for a review, rewrite, or new copy. Also trigger when the user asks to "write copy for", "check my text", "is this accessible?", "how should this sound?", "improve this label", "write an error message", or any similar content-focused request — even if they don't use the words "content design" or "accessibility". Always use this skill instead of improvising copy from scratch.

- Skill: `elgezett/design-content` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add elgezett/design-content`
- Raw SKILL.md: https://api.skillmd.com/api/skills/elgezett/design-content/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: elgezett (https://skillmd.com/u/elgezett)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/elgezett/design-content

---


# Content Design Skill

Produce or audit UX content that is clear, accessible, and human — across UI microcopy and longer explanatory text,
in both German and English.

---

## Standards this skill applies

### 1. Plain Language (GOV.UK / Plain Language principles)
- Use short sentences (target: ≤ 20 words)
- Prefer common, everyday words over formal or technical ones
  - ✅ "help" not "assist", "buy" not "purchase", "use" not "utilise"
  - ✅ "ungefähr" not "approximativ", "nutzen" not "utilisieren"
- Use active voice
- Address the user directly ("you"/"Sie" or "du" — match the product's established tone)
- Define jargon or acronyms on first use if they can't be avoided
- One idea per sentence

### 2. WCAG 2.2 — Readable content (Guideline 3.1)
- Use the language the user is actually in (don't mix languages mid-sentence)
- Avoid unusual words; if used, provide a brief inline explanation
- Aim for a reading level accessible to a broad audience (approx. Grade 6–8)
- Do not rely on sensory characteristics alone ("click the green button" → "click Save")

### 3. UX Writing / Microcopy principles
For UI-level copy specifically:

| Element | Rule |
|---|---|
| Buttons / CTAs | Start with a verb. Describe the outcome. ✅ "Termin buchen" ✗ "OK" |
| Error messages | Say what happened (briefly), then what to do. Never blame the user. |
| Empty states | Explain why it's empty + what to do next. ✅ "Noch keine Aufgaben. Leg jetzt eine an." |
| Tooltips / helper text | One idea only. No full stops needed for single sentences. |
| Onboarding | Focus on the user's goal, not the feature list. |
| Confirmation messages | Confirm the action in past tense, optionally offer an undo. |

### 4. Inclusion & cognitive load
- Avoid negative constructions where possible ("Enter a valid email" not "Invalid email entered")
- Don't rely on colour alone to convey meaning — text must be self-explanatory
- Avoid urgency language that creates unnecessary stress ("Warning!", "Alert!" — use sparingly)
- For German: use gender-inclusive language where appropriate (e.g. "Nutzer:innen" or "Nutzende")

### 5. Human-written tone
- Use contractions where they sound natural (German: "du hast" not "Sie haben" if the product is informal)
- Vary sentence structure; don't start every sentence the same way
- **Avoid overusing the em dash (—)**. Use it at most once per paragraph. Prefer restructuring the sentence instead.
- Don't over-explain. Trust the user.
- Avoid filler words: "basically", "simply", "just", "eigentlich", "einfach nur"

---

## Workflow

### Always start here: gather context

Before auditing or writing anything, ask for the following if not already clear from the conversation:

1. **Zielgruppe / Audience** — Who is reading this? (e.g. "Fachpublikum aus dem Maschinenbau", "Patienten ohne Vorkenntnisse", "B2B-Einkäufer")
2. **Anrede / Register** — "du" oder "Sie"? Formal oder informell? Do not guess or default.
3. **Terminologie** — Is there company- or industry-specific language that must be preserved or avoided?
4. **Kontext / Placement** — Where does this text appear? (e.g. "Über uns"-Section, error modal, onboarding step 2 of 4) — avoids duplicating info already present in headers, labels, or surrounding UI.

Ask all four in one go, not one by one. If the user has already provided some of this, only ask for what's missing.

---

### A) Auditing existing content

1. Gather context (see above).
2. Read the provided text carefully.
3. Identify issues by category (see checklist below).
4. Give a **brief, focused explanation** of what's not working — 1–3 sentences per issue, no lengthy lecture.
5. Provide a **concrete rewrite** for each issue.
6. If the content is mostly fine, say so. Don't manufacture problems.

**Audit checklist:**
- [ ] Passive voice → rewrite in active
- [ ] Long sentences (>20 words) → split or shorten
- [ ] Jargon without explanation → simplify or add gloss
- [ ] Vague CTAs (OK, Submit, Weiter) → make outcome-specific
- [ ] Blame-y error messages → reframe constructively
- [ ] Em dash overuse → restructure
- [ ] Language mixed unnecessarily → standardise
- [ ] Missing next step (empty states, errors) → add guidance
- [ ] Gendered language (German) → check for inclusive options
- [ ] Content duplicated from surrounding context (headers, labels) → remove

### B) Generating new content

1. Gather context (see above).
2. Identify what the user is trying to do or understand at this moment.
3. Write copy that serves that moment — not copy that shows off.
3. Write copy that serves that moment — not copy that shows off.
4. Apply all rules from the Standards section above.
5. **Do not overuse the em dash.** If you feel the urge to use one, consider splitting the sentence instead.

---

## Output format

For **audits**: structured feedback with ≤ 3 sentences of explanation per issue, followed by the improved version.

For **generated copy**: deliver the copy directly, optionally with a brief note on the key choices made (tone, structure).
Keep meta-commentary short — the copy itself is the deliverable.

---

## Reference files

- `references/german-plain-language.md` — German-specific plain language guidance and common word swaps
- `references/patterns.md` — Pattern library: error messages, empty states, CTAs, onboarding, by type

Read these when you need more detailed guidance for a specific pattern or language-specific rule.