Content Design Microcopy Review

---
name: Microcopy Review
description: Four-lens review of UI strings for plain language, voice consistency, error quality, and action clarity.
when_to_use: User pastes buttons, labels, errors, toasts, or empty-state copy and asks for a content review.
---

# Microcopy Review

## What this skill does
Reviews UI strings through four lenses — plain language, voice and tone, error quality, action clarity — and returns rewritten strings, not suggestions. Matches an existing product voice if one is given; otherwise infers and mirrors.

## When to load this skill
Load when the user pastes a set of UI strings (buttons, labels, placeholders, errors, toasts, empty states, tooltips, confirmation dialogs) and asks for a review, a rewrite, a "content pass", a "voice check", or help with error messaging.

## The procedure

### Step 1 — Establish voice before touching words
Ask the user: does the product have a documented voice? If yes, request the doc or a summary. If no, ask for three strings they think represent the product at its best. Mirror those. Never rewrite a product's copy into a generic chirpy SaaS voice — that's the opposite of content design. Claude's job is to help the product sound more like itself, not more like everyone else.

### Step 2 — Lens one: plain language
Walk each string and flag: jargon, insider language, acronyms, long words where a short one works ("utilize" → "use", "initiate" → "start"), nominalizations ("perform the validation" → "check"), and the passive voice when active is available. For each flag, rewrite. Keep the string's length roughly the same — plain language usually makes copy shorter, but shortening is not the goal; clarity is.

### Step 3 — Lens two: voice and tone consistency
Check that strings in similar moments feel like they came from the same writer. If one confirmation says "Got it!" and another says "Thank you for your submission", one of those is wrong. Flag inconsistencies and pick the one that matches the documented or inferred voice. Also check tone-to-context fit: serious moments (errors, account deletion, billing) should not use exclamation points, playful emoji, or "oops". Playful voice is not the same as always-cheerful voice.

### Step 4 — Lens three: error message quality
Every error must answer three questions: **what happened, why, and what to do next.** Walk each error and grade it: 0 for "something went wrong", 1 for "what happened only", 2 for "what and why", 3 for all three. Any error below 3 gets rewritten. Banned phrases: "Invalid input", "An error occurred", "Something went wrong", "Please try again later" without a reason. Errors caused by the user (wrong format, missing field) must be specific and actionable. Errors caused by the system must apologize briefly and give an alternative path.

### Step 5 — Lens four: action verb clarity
Every button, link, and call-to-action gets checked for verb specificity. "Submit" is almost always wrong — submit what? Fix: "Send invite", "Save changes", "Publish post", "Delete account". Buttons should name the outcome, not the interaction. Same for confirmation dialogs: "Are you sure?" with "Yes"/"No" is a UX failure. Replace with "Delete this project?" and "Delete project" / "Keep project". The destructive action should name what it destroys.

### Step 6 — Write the revised set
Close with a table or list: **original string → revised string → lens that caught it → one-sentence reason.** Add a short "voice notes" section summarizing patterns worth the team documenting (e.g., "use sentence case for all buttons", "never use 'please' — it's filler here"). Hand off to [The Content Design Coach](/agents/soul-the-content-design-coach) if the user wants to discuss voice at a strategic level.

## A worked example

**User:** Review these strings from our task app. We want to sound calm and practical, not chirpy.

```
- Button: "Submit"
- Error: "Invalid input"
- Empty state: "No tasks to display."
- Toast: "Awesome! Your task was created successfully!!"
- Confirm dialog: "Are you sure?" with buttons "OK" / "Cancel"
- Tooltip: "Click here to initiate the synchronization process."
```

**Claude:** Voice: calm and practical. Four-lens pass.

**1. Submit** — action verb lens. What is it submitting? Assuming this is a new-task form:
→ **"Add task"**. Short, specific, names the outcome.

**2. Invalid input** — error quality lens. Grade 0: says nothing. If this is a date field that needs MM/DD/YYYY:
→ **"Use the format MM/DD/YYYY (example: 04/13/2026)."** Grade 3: what, why, what to do.

**3. No tasks to display** — plain language lens. "Display" is jargon for users; it's also a missed opportunity. Calm-and-practical version:
→ **"Nothing here yet. Add your first task above."** Gives the next action.

**4. Awesome! Your task was created successfully!!** — voice lens. "Awesome" and the double-exclamation are chirpy, which the product explicitly isn't. Also redundant — the task appearing in the list is already confirmation.
→ **"Task added."** Or delete the toast entirely. A toast that announces something the user can already see is noise.

**5. Are you sure? OK / Cancel** — action verb lens. "OK" doesn't name the action. Assuming this confirms task deletion:
→ Dialog: **"Delete this task?"** Buttons: **"Delete"** / **"Keep task"**. The destructive button names what it destroys; the safe button says what the user will still have.

**6. Click here to initiate the synchronization process** — plain language and action verb lenses. "Click here" (avoid, also fails link-purpose in screen readers), "initiate" (use "start"), "synchronization process" (say "sync"). Also a tooltip shouldn't tell the user what to click — it should tell them what will happen.
→ Tooltip: **"Syncs your tasks with the server. Runs automatically every minute."**

**Voice notes for the team:**
- Exclamation points: reserve for genuine celebration, not confirmations. The calm voice rarely uses them.
- Never "Click here" — name the action.
- Skip the word "please" in UI. It's filler and makes the product sound apologetic about asking for things.
- Destructive confirmations name what gets destroyed, in both the question and the button.

**User:** What about placeholder text?

**Claude:** Placeholders weren't in the set, but a quick principle: placeholders are not labels. They disappear the moment the user starts typing, so anything that needs to stay visible (format, example, validation rules) belongs in the label or a helper text below the field, not in the placeholder. The form accessibility skill covers this in more detail if you want me to load it.

## What this skill will NOT do
- Will NOT impose a generic "friendly SaaS" voice on a product with its own established voice.
- Will NOT rewrite marketing copy, landing-page hero text, or long-form content. This skill is for UI strings only.
- Will NOT accept error messages that don't answer what/why/what-to-do. They get rewritten or flagged for deletion.
- Will NOT invent product details to pad a rewrite. If a button's target is unknown, Claude asks.
- Will NOT use emoji, exclamation points, or "please" unless the documented voice explicitly calls for them.