Standards

47 rules, organized into 9 categories. Each one carries a pass and fail example and a list of the content types it's relevant to.

Clarity

CLR-01 — Use plain language. Avoid jargon, technical terms, or insider language unless the audience requires it.
CLR-02 — Lead with the most important information. Put the action or outcome first.
CLR-03 — Use short sentences. Aim for 15-20 words per sentence. Sentences over 25 words should almost always be split.
CLR-04 — One idea per sentence. Don't chain multiple concepts together.
CLR-05 — Avoid confusing double negatives that make the reader work to parse the meaning. Constructions like 'not irreversible' or 'not uncommon' should be rewritten as direct statements. Natural phrasing like 'can't proceed without' is acceptable when it reads clearly.

VT-01 — Use active voice when giving instructions or describing user actions. Passive voice is acceptable for confirmations and system status messages where the actor is irrelevant or where naming the actor would feel unnatural.
VT-02 — Address the user directly with 'you' and 'your' in consumer-facing UI copy. Third-person references to 'users,' 'members,' or 'customers' are acceptable in admin interfaces, documentation, and system descriptions where the reader is not the subject.
VT-03 — Be conversational but not casual. Write like a knowledgeable colleague, not a robot or a buddy.
VT-04 — Be confident, not arrogant. State things directly without hedging or over-qualifying. Qualification language is acceptable when making definitive claims would be misleading or legally inaccurate — for example, eligibility statements in healthcare, finance, or legal contexts where outcomes depend on individual circumstances.
VT-05 — Show empathy in error and failure states, scaled to the severity of the problem. High-impact errors (payment failures, data loss) should acknowledge the frustration and reassure the user. Low-impact errors (failed upload, timeout) should be clear and helpful without over-dramatizing.

CON-01 — Use consistent terminology. Don't switch between synonyms for the same concept.
CON-02 — Use sentence case for headings and UI labels, not title case.
CON-03 — Use consistent date and time formats. Spell out the month to avoid ambiguity.
CON-04 — Use the same word for the same action throughout the product. Don't mix 'delete,' 'remove,' and 'trash.'
CON-05 — Capitalize product names and features consistently. Follow the product's own conventions.

ACC-01 — Write descriptive link text. Never use 'click here' or 'learn more' as standalone links.
ACC-02 — Don't rely on color alone to convey meaning. Pair color with text or icons.
ACC-03 — Write alt text that describes the function or content of an image, not just what it looks like.
ACC-04 — Avoid directional language that assumes visual layout. Don't say 'above,' 'below,' 'to the right.'
ACC-05 — Use readable font sizes and sufficient contrast. Body text should be at least 16px.
ACC-06 — Don't include preceding articles (a, an, the) inside linked text. Link only the meaningful words.
ACC-07 — Write clear, concise form labels. Only mark fields as required when they are truly necessary.

ACT-01 — Start button and CTA text with a verb. Tell the user what will happen. Navigation labels, tabs, section headings, and confirmation or status messages are not CTAs — patterns like 'Project created' or 'Payment sent' are valid confirmation copy and should not be flagged.
ACT-02 — Use specific verbs over vague ones. Prefer 'save,' 'send,' 'export' over 'submit' or 'process.'
ACT-03 — When communicating a limitation, lead with what the user can do or offer an alternative path. Don't leave users at a dead end. Stating a restriction is acceptable when it's paired with a next step or workaround.
ACT-04 — Make the next step obvious. Every screen should have a clear primary action.

STR-01 — Use headings to create scannable structure in help content, onboarding flows, and long-form UI copy. Short UI copy like error messages, tooltips, and confirmations don't need headings.
STR-02 — Keep paragraphs short. 2-3 sentences max for UI copy and help content.
STR-03 — Use parallel structure in lists and sequential steps. Each item should follow the same grammatical pattern. In multi-step flows, a final result-state item ('You're ready to go', 'Your account is set up') may shift to declarative when it describes an outcome rather than an action.
STR-04 — Front-load key information in tooltips and microcopy. Users may not read to the end.
STR-05 — Group related information together. Don't scatter details across disconnected sections.
STR-06 — Nest headings hierarchically. Never skip heading levels for visual styling. H1 for page title, H2 for sections, H3 for subsections.

GRM-01 — Use the serial comma (Oxford comma) in lists of three or more items.
GRM-02 — Spell out abbreviations and acronyms on first use in body copy and help content. Use the short form for subsequent mentions. Universally understood abbreviations (FAQ, URL, ZIP, LLC, IRS) and regulated accessibility terms (TTY) do not require expansion in any context. Internal or organization-specific abbreviations should always be expanded on a public-facing page. If the surrounding copy acknowledges the reader may not know a term, expand it.
GRM-03 — Use exclamation points sparingly. Never use more than one at a time, and never in error messages or alerts.
GRM-04 — Don't use ampersands in body copy unless they are part of a brand name. Ampersands are acceptable in headings, navigation labels, footer links, and other space-constrained UI elements where '&' is a conventional shorthand.
GRM-05 — Use numerals for numbers in body copy. Spell out a number only when it begins a sentence.
GRM-06 — Hyphenate number-unit compound modifiers before nouns. The unit takes singular form when hyphenated.

INC-01 — Use 'they,' 'them,' and 'their' as singular pronouns when the user's gender is unknown or irrelevant.
INC-02 — Don't ask for gender in forms unless it's necessary for the product. When you do, provide a text field rather than a limited dropdown.

TRN-01 — Avoid words with multiple meanings that confuse translators. Replace 'once' (use 'after'), 'right' (use 'correct'), and 'since' (use 'because').
TRN-02 — Avoid unnecessary -ing words that create ambiguity in translation. Rewrite gerunds and -ing adjectives when a simpler form exists. Progressive verb forms are acceptable when they describe an ongoing action ('Uploading your file...', 'Loading results...').
TRN-03 — Repeat subjects and verbs in compound sentences instead of relying on implied subjects. Many languages require explicit subjects.
TRN-04 — Avoid idioms, slang, and culturally specific references. These don't translate and confuse non-native speakers.
TRN-05 — Keep function words like 'the,' 'a,' 'that,' and 'to' even if they seem unnecessary. Removing them creates ambiguity in translation.
TRN-06 — Use metric measurements and 3-letter ISO currency codes (USD, EUR, GBP) instead of symbols when writing for international audiences. Currency symbols are acceptable in locale-specific content that will be localized (adapted per region) rather than translated (same content in multiple languages).
TRN-07 — Avoid using different words for the same concept within a single piece of content. If 'workspace,' 'team hub,' and 'project space' all refer to the same thing, pick one term and use it consistently. Different terms are acceptable when they refer to genuinely different concepts.