Plain English Writing

Translates technical content into decision-ready communication for non-technical stakeholders.

When to Use

Apply when writing for: executives, business managers, compliance/legal, or cross-functional stakeholders without the requesting team's domain knowledge.

When Not to Use

Skip when writing for engineers or technical specialists. You may optionally apply selective translation for mixed audiences; consider keeping technical depth for peer reviews or developer-facing docs.

Mindset

Technical writing optimises for completeness. Plain-English writing optimises for decisions.

Before writing a single word, ask:

"What does this person need to decide or do — and what is the minimum information required for that?"

The single most reliable fix: move the recommendation to sentence one. Everything else is secondary.

Decision Framework

┌─────────────────────────────────────────────┐
│  OPENING (required)                          │
│  Problem + Business impact + Action needed   │
├─────────────────────────────────────────────┤
│  SUPPORTING CONTEXT (only if needed)         │
│  Background / Options / Tradeoffs / Timeline │
├─────────────────────────────────────────────┤
│  APPENDIX (optional)                         │
│  Technical detail / Metrics / Implementation │
└─────────────────────────────────────────────┘

If a reader only reads the opening, they must still know what to do.

Workflow

Step 1: Identify Audience

executive (zero jargon) | manager (minimal jargon) | compliance/legal (tech translated) | cross-functional (inline definitions). See references/constraints-and-fallbacks.md for the audience depth guide.

If unknown: Audience: unknown. Applying manager-level clarity (fallback).

Step 2: Define the Outcome

One sentence — what must the reader decide or do? Write it before drafting.

Step 3: Draft Key Message First

Opening must contain: problem + business impact + required action.

BAD:  [3 paragraphs of background] "...we recommend approving the budget."
GOOD: "We need your approval for a $50k security fix by Thursday. [Impact follows.]"

Step 4: Add Supporting Context

Every action item MUST follow:

[Owner] must [specific action] by [concrete deadline].

BAD:  "The database should be optimized."
GOOD: "Database team (Alex) must optimize query performance by March 15."

For acronym-heavy documents, extract all acronyms first:

grep -oE '\b[A-Z]{2,}\b' file.md | sort -u

Define each, then draft — rewrite still leads with key message, not the glossary.

Step 5: Verify

- [ ] Every acronym defined on first use.
- [ ] Opening paragraph contains the key decision or recommendation.
- [ ] All technical terms translated — no unexplained jargon.
- [ ] Every action: [Owner] must [action] by [deadline].
- [ ] Paragraphs are concise and scannable.

Constraints

Hard rules: ALWAYS state audience · ALWAYS define acronyms · ALWAYS lead with key message for executives · NEVER hide decisions · NEVER use passive voice for owned actions · NEVER leave deadlines undefined · NEVER present options without a recommendation.

Fallback paths (state explicitly at the top of your output before writing):

Full formats: references/constraints-and-fallbacks.md.

Anti-Patterns

Full catalogue: references/anti-patterns.md.

References

External: PlainLanguage.gov