A brand vocabulary guide records the terms a team prefers, avoids or uses only under stated conditions, with definitions, examples and reasons. Build it from customer language, product truth, accessibility needs and recurring internal disputes. Give every high-risk term an owner and review date. The guide should improve recognition and accuracy without banning useful variation or natural speech.
Decide what belongs in the guide
Prioritise words that affect meaning, trust or consistency:
- company, product and feature names;
- category and audience terms;
- customer language for important problems and outcomes;
- technical terms, acronyms and definitions;
- claims requiring conditions or evidence;
- inclusive and accessible alternatives;
- outdated internal language;
- words that create legal, regulatory or operational risk.
Do not try to list every acceptable adjective. A small, searchable decision tool is more useful than a dictionary no one can maintain. Keep broader language behaviours in the brand voice guidelines so vocabulary entries do not have to carry the whole voice system.
Use evidence to choose preferred terms
Review interview transcripts, search queries, support tickets, sales notes and usability studies. Customer language can reveal familiar terms, but frequency alone does not make a phrase accurate or appropriate. Check it against the product and intended audience.
The GOV.UK guidance on writing for GOV.UK recommends using the language of users and explaining unusual terms. That does not mean copying harmful, exclusionary or factually wrong language. Editorial judgement remains necessary.
Connect core terms to the messaging framework so product pages, articles and sales material describe the same category and capabilities.
Give each entry useful fields
Use a table or searchable database with:
- term;
- status: preferred, allowed, conditional, avoided or deprecated;
- plain definition;
- when to use it;
- when not to use it;
- preferred alternative;
- example in a sentence;
- reason or evidence;
- owner and review date.
Add translations or regional variants only when reviewed by people competent in those languages and markets. Do not assume a literal translation preserves meaning or tone.
Illustrative example: automation terminology
Illustrative example: imagine workflow software that suggests actions but requires human approval.
| Term | Status | Guidance |
|---|---|---|
| Automated | Conditional | Use for steps completed without manual action; name the trigger and exception path |
| Autonomous | Avoided | The product does not operate independently across the workflow |
| Suggestion | Preferred | Use for system-generated options that a person reviews |
| AI-powered | Conditional | Use only when the specific function and user value are explained |
The guide protects accuracy. It does not prevent a writer from choosing “recommendation” instead of “suggestion” when both are defined and the context supports it.
Include accessibility and inclusion checks
Use people-first or identity-first language according to the expressed preference of the relevant community and current editorial policy; there is no single construction appropriate to every context. Avoid ableist metaphors and unnecessarily gendered role names.
Plain language benefits many readers, including people working in a second language or under time pressure. Explain necessary technical terms on first use. The W3C guidance for readable content discusses supplementary content or simpler alternatives when text requires advanced reading ability.
Make the guide part of the workflow
Add vocabulary checks to content briefs, product naming and editorial review. Link entries from the brand voice chart and content management system. Let teams suggest additions with the context that prompted them.
Review terms after product changes, customer research, policy updates or repeated confusion. Keep deprecated terms searchable so people understand what replaced them and why.
Limitations and trade-offs
Strict vocabulary improves consistency but can make language repetitive or unnatural. Define where variation is welcome. Search optimisation should not force awkward repetition or unsupported terminology; write for reader understanding first.
Language changes. A guide is a maintained record, not permanent authority. High-risk decisions may require legal, technical or community expertise beyond an editorial owner.
Vocabulary-guide checklist
- Focus on terms that affect meaning or trust.
- Use research and product truth.
- Define preferred, conditional and avoided status.
- Provide examples and reasons.
- Explain acronyms and specialist language.
- Include accessibility and inclusion review.
- Add owner and review date.
- Keep deprecated terms searchable.
Frequently asked questions
Should a vocabulary guide include SEO keywords?
It can record language readers use, but keywords should not override accuracy or natural expression. Map a reader question to the most useful page instead of repeating a phrase everywhere.
Is a banned-word list enough?
No. Writers need the reason, preferred alternative and situations where a term may still be accurate.
How often should the guide be reviewed?
Review it when products, markets or policies change and schedule periodic checks for high-impact entries. Update individual terms whenever evidence changes.
Your useful next step
Collect ten terms that teams use inconsistently. Give each a status, definition, example, reason and owner. Test the guide on a current page before expanding it.