Clarity · nuanced · v4.7.0

CLR-01

Use plain language. Avoid jargon, technical terms, or insider language unless the audience requires it.

Pass example

Your payment didn't go through. Try a different card.

Fail example

Transaction declined due to insufficient authorization parameters.

Relevant content types

Notes by content type

All content types
CLR-01 covers three distinct failure modes. Match your suggestion to the actual problem: (1) Jargon — domain-specific terms the audience won't know. Suggest a plain-language equivalent. (2) Non-standard English — unnecessarily complex words with simpler alternatives (e.g., 'utilize' → 'use'). Name the simpler word. (3) Vacuous copy — filler phrases that add no meaning (e.g., 'in order to' → 'to'). Suggest removing or tightening. (4) Domain-mainstream terminology — medical and financial terms that have entered mainstream awareness through cultural discourse (e.g., GLP-1, FDIC, 401(k)) do not violate plain language requirements. Evaluate jargon relative to the target audience and domain, not in absolute terms. Terms may also be required by regulatory constraints (e.g., GLP-1 is the correct generic term when brand names cannot be used pre-prescription).

Weighted in these moments

This standard behaves differently depending on the reader's moment. Moment-aware evaluation picks one of these adjustments when the moment matches.

  • first_encounter — emphasize
    First-time users have zero context. Plain language is critical.
  • decision_point — emphasize
    Users making decisions need precise, jargon-free language.
  • error_recovery — emphasize
    Error messages must be jargon-free — the user is already stressed.
  • destructive_action Destructive — emphasize
    Consequences must be stated in plain, unambiguous language.
  • trust_permission Permission-gated — emphasize
    Users can't consent to what they don't understand.
  • compliance_disclosure Compliance — relax
    Legal and financial terms may be mandated precision, not jargon.

Example pairs

Concrete before/after pairs observed in public style guides, each with inline attribution. See /sources for the full source list and licensing.

  • browsing_discovery · short_ui_copyOGL-3.0

    Not this. We will endeavour to utilise the most appropriate methodology.

    But this. We'll use the best method.

    GOV.UK's plain-English canon: prefer 'use' over 'utilise', 'try' over 'endeavour'. — GOV.UK Style Guide · A to Z — plain English

  • error_recovery · error_messageCC-BY-NC-ND-4.0

    Not this. An unexpected authentication error occurred.

    But this. We couldn't sign you in. Try again.

    Mailchimp voice: plain language + actionable recovery instead of jargon. — Mailchimp · Content Style Guide — Error messages

  • compliance_disclosure · long_form_copyCC0-1.0

    Not this. Failure to comply with the aforementioned stipulations may result in penalties.

    But this. If you don't follow these rules, you may be fined.

    18F: plain language even in compliance contexts — accessibility is a civic obligation. — 18F Content Guide · Write in plain language

  • compliance_disclosure · short_ui_copyCC0-1.0

    Not this. Applicants must submit documentation prior to commencement.

    But this. Send your documents before you start.

    USWDS: federal guidance — plain language serves accessibility and civic participation. — USWDS · Plain language

  • empty_state · short_ui_copyall-rights-reserved

    Not this. No data available.

    But this. No orders yet. They'll show up here as they come in.

    Polaris empty-state principles: name what's missing, set expectations, point at next action. — Shopify Polaris · Empty states

  • trust_permission · long_form_copyall-rights-reserved

    Not this. By proceeding, you acknowledge and consent to the collection, processing, and storage of your personal information.

    But this. We'll store your email so you can sign back in. You can delete it anytime in Settings.

    Carbon: plain language in legal-adjacent contexts. Specificity + action beat legalese + abstract consent. — IBM Carbon · Writing — Technical audiences

Sources

Style guides that shaped this standard. Each is listed on /sources with its license and opt-out path.

  • Mailchimp
  • GOV.UK Style Guide
  • 18F Content Guide
  • Microsoft Writing Style Guide
  • USWDS

Influences — how the sources relate

ContentRX's standards are syntheses, not weighted averages of external guides. Where the influence is worth naming explicitly — because the sources disagree, or because the standard deliberately takes a third position — it's recorded here. Aligns with, diverges from, and synthesizes are the three relationships the model uses.

  • SynthesizesMailchimp

    Mailchimp's plain-language guidance drives the voice — 'write for everyone' — but treats jargon as a style issue. CLR-01 treats jargon as an audience-dependent judgment, which is a synthesis across the five sources rather than a direct adoption.

  • SynthesizesGOV.UK Style Guide

    GOV.UK's 'plain English' canon informs the hard-line phrasing (e.g. 'utilize' → 'use'). The audience-relative clause in CLR-01 generalizes GOV.UK's civic-audience assumption to product audiences that might include specialists.

  • Aligns with18F Content Guide

    18F's 'plain language even in compliance contexts' position aligns directly; CLR-01's audience-relative exception picks up the same carve-out for domain-mainstream terminology (GLP-1, FDIC, 401(k)).

Version history

  1. v4.7.0 · 2026-04-24

    Session 35 — added `influences` metadata showing CLR-01 synthesizes the plain-language positions across Mailchimp, GOV.UK, 18F, Microsoft, and USWDS. Rule text unchanged.

  2. v4.6.1 · 2026-04-23

    Per-standard version tracking introduced. Every standard starts at the library version current at introduction; bump per-standard when the rule text, examples, or content_type_notes change.

Related standards

Other standards in the Clarity category.

  • 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.

← The content model