mailchimp-copy-style

---
name: mailchimp-copy-style
description: House copy style guide adapted from Mailchimp. Use whenever writing or reviewing copy for app surfaces (UI strings, buttons, errors, empty states, onboarding, push notifications) and for websites, marketing pages, App Store descriptions, release notes, and emails. Covers voice, tone, grammar, microcopy, accessibility, and inclusive-language rules. Triggers on "house style", "copy style", "write copy", "rewrite this", "review this string", "button text", "error message", "empty state", "onboarding copy", "UI copy", "microcopy", "push notification", "release notes", "App Store copy", "email subject", or "style guide".
---

# Mailchimp-Style Copy Guide

How we write copy across all our apps, websites, marketing, and in-product surfaces. **Distilled from the [Mailchimp Content Style Guide](https://styleguide.mailchimp.com/)** — the most widely respected public style guide for product writing — and adapted for our portfolio.

Default home is **app surfaces**: every UI string, button, error, empty state, and onboarding line should run through this guide. The same rules apply to web, marketing, and email so the voice stays consistent end-to-end.

When in doubt, read it out loud. If it sounds weird, rewrite it.

---

## 1. The four standards

Every piece of copy should be:

- **Clear** — Understand the topic. Use simple words and short sentences. If a user has to re-read it, it's broken.
- **Useful** — Before writing, know the purpose, the audience, and the one thing they need. Cut everything else.
- **Friendly** — Write like a human. Break a grammar rule if it makes the line more natural.
- **Appropriate** — Match the register to the moment. A delete confirmation isn't the place for a joke. An onboarding tip is.

---

## 2. Voice (stays constant)

Same voice everywhere — landing page, app, email, error message.

- **Plainspoken.** No hyperbole, no marketing fluff. Say what the thing does.
- **Genuine.** Warm, not corporate. Talk like a person who actually uses the product.
- **Translator.** When something is technical, explain it like you'd explain it to a smart friend who doesn't work in tech.
- **Dry, subtle humor.** Straight-faced and a touch weird is fine. Loud, try-hard, or meme-y is not. If a joke needs explaining, cut it.

**Do:** active voice, plain English, positive framing.
**Don't:** force jokes, lean on slang or jargon, write in passive voice.

---

## 3. Tone (shifts with context)

Voice is who you are. Tone is how you read the room.

Ask: *what is the user feeling right now?* Confused? Relieved? Frustrated? Excited? Match it.

| Context | Tone |
|---|---|
| Onboarding / empty states | Warm, encouraging, light |
| Success confirmations | Brief, celebratory, get out of the way |
| Errors | Calm, specific, no blame, point to the fix |
| Destructive confirms (delete, cancel) | Sober and direct. No humor. |
| Marketing pages | Confident, benefit-led, never grandiose |
| Legal / billing | Plain and precise. Friendly framing is fine; vagueness is not. |
| Educational content | Patient, structured, never condescending |

---

## 4. Writing about people

We write the same way we build apps: person-first.

- **Singular "they"** when gender is unknown or irrelevant. Use whatever pronouns a person communicates; ask if you don't know.
- **No "guys"** for mixed groups. No "girls" for grown women.
- **Neutral job terms.** Server, not waitress. Businessperson, not businessman.
- **Don't mention age, disability, or medical conditions** unless directly relevant. When relevant, person-first ("person with a disability") unless the person prefers identity-first ("disabled person").
- **Capitalize racial and cultural identities** (Black, Asian, Indigenous). Lowercase "white". No hyphen in dual heritage ("Asian American").
- **Never use:** "suffers from", "victim of", "handicapped" (except "handicapped parking"), "lame", "crazy", "insane", "addicted to" as a casual intensifier.
- **Identity terms are modifiers, not nouns.** "A gay man", not "a gay". "A trans woman", not "a transgender".
- **Audiences are people, not data.** Use "they", not "it". Treat contacts as humans, not rows.

---

## 5. Grammar & mechanics

The practical rulebook.

### Voice
- **Active voice.** Subject does the action. ("We sent the email" — not "the email was sent".)
- Passive is fine only when the action matters more than who did it.

### Capitalization
- **Sentence case** for everything by default: page titles, headings, form labels, checkboxes, radios, dropdown items, menu items.
- **Title case** is reserved for proper nouns, product names, and primary nav items.
- **Buttons:** title case is acceptable for buttons across our products; pick one per product and stay consistent. (When in doubt, sentence case.)
- Lowercase: website, internet, online, email (mid-sentence), URLs, email addresses.

### Contractions
- **Use them.** They're, you're, we'll, can't. They make copy sound human.

### Numbers
- Spell out one through nine; use numerals for 10+.
- Always use numerals for times, dates, measurements, percentages, money, and ordinals (1st, 2nd).
- Commas in 4+ digit numbers: 1,000.
- Spell out fractions: two-thirds.
- Use `%` not "percent" outside of headlines.
- En dash for ranges: 20–30 days.

### Dates & time
- Spell out day and month: Saturday, January 24.
- Lowercase am/pm with a space: 7 am, 7:30 pm.
- Use the user's local time when shown in product. Specify the zone when ambiguous.

### Punctuation
- **Oxford comma, always.** "Eggs, milk, and bread."
- **Em dash —** for asides and emphasis. No spaces around it.
- **Hyphen -** for compound modifiers (well-known, full-time).
- **En dash –** for ranges (Mon–Fri, 5–10).
- **Ampersands** only inside brand or company names. Otherwise "and".
- **Ellipses…** sparingly. Not for dramatic effect.
- **Semicolons** sparingly. Em dash or a new sentence usually reads better.
- **Periods and commas** go inside quotation marks.
- **Exclamation points:** rarely. One per screen, max. Never in error messages.

### Pronouns
- **"You"** to address the user.
- **"We"** to refer to us / the product team.
- Never "one". Never the royal "we" for the user.

### Companies & products
- Honor official capitalization (iPhone, YouTube, GitHub).
- Companies are "it", not "they".

### Formatting
- Left-align body copy.
- Single space between sentences.
- Italics for product UI references ("tap *Save*"), titles of long works, and rare emphasis.
- **Don't combine** bold + italics + underline. Pick one.
- **Never underline** anything that isn't a link.

### Positive framing
- Write what *will* happen, not what *won't*.
- "Save to continue" beats "You can't continue without saving".
- "Available on Pro" beats "Not available on Free".

---

## 6. Headlines, microcopy & web elements

### Page titles & headings
- One topic per page or screen.
- Descriptive, front-load the keyword. "Edit recipe", not "Make changes to your recipe".
- Use proper header hierarchy (H1 → H2 → H3). Don't skip levels — screen readers rely on it.

### Buttons & CTAs
- **Verb first.** "Save changes", "Add ingredient", "Send invite".
- 1–3 words ideal. 4 max.
- Be specific. "Delete account" beats "Confirm".
- Destructive actions name what's being destroyed.

### Links
- **Link the meaningful phrase.** "See [pricing plans]" — not "[click here] for pricing".
- A blind user tabbing link-to-link should understand each one out of context.

### Forms
- Labels in sentence case, above the field.
- Mark required fields with `*` or "Required". Don't only mark optional ones unless most are required.
- Inline error messages: what went wrong + how to fix it. Never blame the user.
  - Good: "Email needs an @ symbol."
  - Bad: "Invalid input."
- Placeholder text is not a label. Don't rely on it.

### Empty states
- One sentence saying what this is.
- One CTA telling them how to fill it.
- Skip the apology.

### Confirmations & toasts
- Past tense, brief. "Recipe saved." "Invite sent."
- No exclamation marks. No "Yay!". The action succeeded — that's the celebration.

### Errors
- Plain language. No error codes in the user-facing line (put them in details if needed).
- State the problem, then the path forward.
- Never "Something went wrong" alone. Always add what they can do.

### Lists
- Numbered for sequence (steps 1, 2, 3).
- Bulleted for unordered sets.
- Parallel grammar: every item starts the same way (all verbs, all nouns).

---

## 7. Accessibility (this is copy work, not just design)

- **Front-load the important stuff.** First sentence carries the message.
- **No directional language.** "Tap *Save*" — not "tap the button on the right". Layouts change; left/right is meaningless on mobile, screen readers, or RTL languages.
- **Plain words over clever ones.** A reader with a cognitive disability, a non-native speaker, and a tired user all benefit equally.
- **Spell out abbreviations on first use** unless universally known (API, URL, HTML are fine).
- **Alt text on every meaningful image.** Decorative images get empty alt (`alt=""`). Functional images describe the function ("Search"), not the appearance ("magnifying glass icon").
- **Caption every video.** Provide transcripts for audio.
- **Don't rely on color alone** to communicate state. Add an icon, label, or text.

---

## 8. Writing for translation (and just for clarity)

Even if you never translate, these rules tighten copy.

- Active voice.
- No double negatives.
- Consistent terminology — pick one word for a concept and stick with it. "Recipe" everywhere, not "recipe" / "dish" / "meal" interchangeably.
- Drop idioms, slang, clichés, sports metaphors. "Hit it out of the park" doesn't translate, and half your English-speaking audience misses it too.
- Minimize abbreviations.
- Trade brevity for clarity when they conflict.

---

## 9. The 30-second checklist

Before shipping any string, ask:

- [ ] Would a stranger understand this on first read?
- [ ] Is the most important word in the first three?
- [ ] Active voice?
- [ ] No directional language ("above", "to the right")?
- [ ] Sentence case (unless it's a proper noun or button)?
- [ ] Oxford comma where needed?
- [ ] No exclamation marks I can't defend?
- [ ] If it's a button, does it start with a verb?
- [ ] If it's an error, does it tell the user what to do next?
- [ ] Read it out loud — does it sound like a person?

---

## 10. Patterns we keep getting wrong

A running list. Add to it.

- "Please" is usually filler. Cut it. ("Please enter your email" → "Enter your email".)
- "Successfully" is filler. ("Successfully saved" → "Saved".)
- "In order to" → "to".
- "At this time" → "now" (or just delete it).
- "Utilize" → "use".
- "Click here" → link the actual phrase.
- "Something went wrong" → say what went wrong.
- Marketing superlatives ("powerful", "seamless", "revolutionary") → describe what it does instead.