Clarify the task and decision
This guide turns terminology and glossaries into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
Treat terminology as governed content with owners, statuses, approved explanations, and controlled exceptions.
Practical workflow
- 1
Define the audience with evidence, including reading experience, context, device, and support available.
- 2
Select one real task and state what a successful reader must understand or do.
- 3
Create the language version while preserving every decision-relevant fact, condition, date, and contact path.
- 4
Run specialist and editorial review with recorded acceptance criteria.
- 5
Test with members of the intended audience, record findings, revise, and approve the release.
Worked example or tool
A glossary record shows preferred, prohibited, and audience-specific terms with CMS guidance. In the tool, also record the baseline, owner, decision, evidence, open issue, and approval date. Use a real page or transaction so the team sees dependencies, exceptions, and the maintenance work that follows release.
| Decision point | Record | Acceptance criterion |
|---|---|---|
| Baseline | Observed current state | Source and date recorded |
| Decision | Selected option and rationale | Risk and audience considered |
| Evidence | Test, document, or measure | Reviewable and version-specific |
| Approval | Name, role, and date | All mandatory criteria met |
Make every term a governed record
A useful glossary is more than a list of preferred words. Each record should contain a stable identifier, preferred term, prohibited or deprecated variants, definition, audience explanation, grammatical forms, examples, language mode, domain, owner, status, approval date, source, and review trigger. Keep the technical definition separate from the wording shown to readers. A precise internal definition can support several audience-specific explanations without allowing their meanings to drift.
Use explicit statuses: proposed, under review, approved, deprecated, and prohibited. Only approved records are offered to authors or applied by automated systems. A deprecated term remains searchable so old content can be found and migrated. A prohibited term includes the reason and approved replacement, which helps editors resolve a warning without guessing. Version each decision and retain the previous value for audit and rollback.
| Glossary element | Example | Acceptance rule |
|---|---|---|
| Preferred term | benefits office | One approved form per domain and language mode |
| Audience explanation | The office that checks and pays your benefit | Meaning preserved and tested for the audience |
| Status | Approved | Owner, reviewer, and date recorded |
| Exception | Official form title retains legal term | Scope, reason, and expiry are documented |
Run a repeatable term-decision workflow
Collect candidates from search logs, support questions, reviewer comments, policy changes, and repeated manual corrections. Before creating a new record, search existing terms, variants, and related concepts. The term owner writes the definition and identifies the authoritative source. A subject specialist confirms meaning, an editor proposes reader wording, and an accessibility specialist checks the selected language modes. Test high-impact explanations with intended readers.
The terminology group then approves, rejects, or requests evidence. It should meet on a predictable schedule and have an urgent route for legal or service changes. Decisions state where the term applies and where it does not. For example, a plain-language page may say ‘benefits office’, while an application field must retain the statutory authority name. The exception belongs in the same record so authors see both choices in context.
- 1
Capture the candidate term and the content where it caused difficulty.
- 2
Confirm the concept, domain, authoritative source, and affected audiences.
- 3
Draft preferred wording, explanation, variants, and migration guidance.
- 4
Review meaning, language mode, accessibility, and operational impact.
- 5
Approve and publish the versioned record, then update affected content.
Integrate terminology into authoring and delivery
Expose the glossary through an API or synchronised repository with stable identifiers. The CMS should highlight prohibited and deprecated terms, show the preferred replacement and explanation, and let authors open the full decision. Suggestions must respect locale, domain, content type, and language mode. Do not replace words automatically when grammar or legal context can change meaning. Require an author to accept the suggestion or record a governed exception.
Store the glossary version used for each language revision. When an approved term changes, query the CMS for affected records and create review tasks by risk. Preview checks can block new prohibited terms, missing first-use explanations, or an expired exception. Runtime delivery should not depend on a live glossary request. Resolve and validate terms before publication so a terminology outage cannot alter or block published pages.
CMS suggestions use stable term identifiers rather than text matching alone.
Locale, domain, language mode, and grammatical form are respected.
Automatic checks explain a resolution instead of only reporting an error.
Exceptions have scope, owner, evidence, and expiry.
A glossary change creates review tasks for affected published content.
Measure adoption and resolve conflicts
Track use of preferred terms, new prohibited-term findings, unresolved candidates, average decision time, expired exceptions, and content waiting for migration. Combine these operational measures with comprehension evidence and support demand. A high adoption rate does not prove that an explanation works. If readers still misunderstand an approved term, reopen the decision and preserve the evidence that prompted the change.
When departments need different wording, determine whether they mean the same concept. If the concept differs, create linked records with clear domains. If only the audience differs, keep one underlying definition and provide separate audience explanations. Assign a terminology steward to decide ownership disputes and prevent duplicate records. Review the highest-impact terms at least annually and whenever the governing law, service process, or selected language standard changes.
Roles, evidence, and approval
Language quality is an operating responsibility. Give the source owner responsibility for factual accuracy, an editor responsibility for clarity, a specialist responsibility for accessibility rules, and a product owner responsibility for publication. The release record should identify the source version, language mode, reviewers, test evidence, approval date, and the event that triggers a new review.
Operations and maintenance
The work does not end at publication. Link the language version or configuration to its source, monitor quality and service measures, and define concrete review triggers. Triggers include source changes, legal changes, new audience needs, recurring support questions, technical changes, and incidents. A named owner evaluates the trigger, opens a new revision when needed, and records renewed approval.
Release checklist
The audience and task are explicit.
All legal and operational facts match the source.
Dates, amounts, conditions, and exceptions are complete.
Headings describe reader questions or actions.
Links and controls have meaningful labels.
Specialist terminology is explained consistently.
The intended audience has tested the critical journey.
Ownership and the next review trigger are recorded.