neeeophytee/agent-stylebooks

govuk

Draft, rewrite, or audit plain-language public-service content using an independently expressed interpretation of GOV.UK content design.

Quelltext ansehen
Originales Skill-Dokument

Aus dem Quell-Repository gerendert; Überschriften, Beispiele, Code, Tabellen, Links und Bilder bleiben erhalten.

GOV.UK

Write around the person's need, not the institution's structure or policy-making process.

Protect meaning

  • Preserve legal conditions, duties, dates, amounts, evidence requirements, and

consequences exactly.

  • Do not simplify away an exception. Separate the main case from exceptions.
  • Do not infer eligibility or give personal legal advice from incomplete facts.
  • Flag conflicts between plain-language clarity and mandated wording.

Start with the user need

  1. Write the question the person is trying to answer or the task they need to do.
  2. Identify the decision they must make before reading further.
  3. List the minimum facts needed for that decision: who qualifies, what it costs,

what evidence is needed, how long it takes, and what happens next.

  1. Order the page by user journey, not by department, legislation, or internal team.
  2. Remove information that does not help the user decide, act, or understand a

consequence. Link to specialist detail when it serves a smaller audience.

Write plainly

  • Put the answer or action near the beginning.
  • Use common, concrete words. Explain a necessary technical or legal term in the

same sentence.

  • Address the reader as you. Name the responsible organization when it acts.
  • Use active voice and strong verbs. Replace abstract nouns with the action they

hide when meaning stays intact.

  • Keep sentences focused. Split chains of conditions into bullets or separate

cases.

  • Use examples only when they clarify a rule. Label them as examples, not as the

rule itself.

  • State uncertainty, discretion, and possible outcomes honestly.

Structure the service content

  • Use front-loaded, sentence-case headings that match words people would search.
  • Place universal information first, then conditional routes and exceptions.
  • Use numbered steps only for a required sequence.
  • Put warnings immediately before the risky action, not in a general introduction.
  • Make link text describe the action or destination.
  • Give forms and fields labels that name the requested information, with hint text

only when the label is not enough.

  • End with the next action, alternative route, or source of help.

Avoid

  • opening with a department's mission, announcement, or policy history
  • formal substitutions for ordinary words when the ordinary word is accurate
  • unexplained acronyms, internal programme names, and legislative shorthand
  • promotional claims, reassurance without evidence, or blame
  • please, simply, easy, obvious, and language that judges the user's effort
  • long noun strings, idioms, rhetorical questions, and decorative introductions
  • hiding deadlines, costs, disqualifying conditions, or appeal routes

Final pass

Check whether a first-time reader can answer: Is this for me? What do I need? What will it cost? How long will it take? What can go wrong? What do I do next? If any answer is unavailable, expose the gap instead of smoothing over it.

Read references/provenance.md only for source, attribution, licensing, or maintenance questions.