A glossary looks like an easy task for AI: supply a list of unfamiliar words and ask for simple definitions. The difficult part is that a familiar word can mean something very specific inside your product. A smooth explanation of “archive” may promise permanent storage, deletion, or recoverability even when your notes establish none of those things.
This worked example shows how to turn approved product notes into a short glossary that helps readers make the right choice. It complements our protected-terms guide: that guide preserves important wording during a rewrite; this one explains that wording to a newcomer. All product names, rules, and examples below are fictional.
Choose terms that affect a reader's next step
Imagine you are writing help content for a fictional shared reading-list app called Bookroom. Its approved notes say: “A collection groups reading links. A draft collection is visible only to its creator. A shared collection is visible to invited members. Archiving removes a collection from the active list. Archived collections can be restored from the Archive view. Invitations are managed separately from collection status.”
A useful glossary would explain collection, draft, shared, and archived. It does not need an entry for every ordinary word in the interface. Focus on terms readers must distinguish before clicking a control or asking for access. Gather exact interface labels, approved explanations, and relevant help-page links before requesting the draft.
GOV.UK's accessible-document guidance recommends explaining technical terms and abbreviations when they first appear. A glossary can support that explanation, but it should not force readers to leave an instruction just to understand its central noun. Define the essential term briefly where it is used, then link to the fuller entry if needed.
Give each definition a job
For this example, each entry needs three pieces: the exact term, its meaning in Bookroom, and a concrete example or distinction. Keep the structure consistent without forcing identical sentence lengths. Do not start every entry with “An innovative feature that allows users to”; the reader needs to understand the term, not evaluate marketing language.
Collection: A group of reading links in Bookroom. For example, you could create a collection for articles to discuss with your book club.
Draft: A collection visible only to its creator. Use this term for the collection's visibility status; it does not describe whether the links themselves are finished articles.
Shared: A collection visible to invited members. Shared does not mean publicly visible to everyone on the internet.
These definitions explain the supplied rules and separate two possible interpretations of each term. They do not invent limits on the number of links, membership fees, or editing permissions. If readers need those facts, obtain them from the product owner before expanding the entry.
Catch the promise hidden inside a definition
Weak AI entry: “Archived: A collection that has been permanently deleted from your workspace, freeing storage while keeping a backup you can recover at any time.”
The sentence combines incompatible ideas and unsupported promises. The notes say the collection leaves the active list and can be restored from a named view. They say nothing about storage, backups, permanent deletion, or how long restoration remains available. Those additions matter even though the entry sounds like routine help text.
Source-backed entry: “Archived: A collection removed from the active list. You can restore it from the Archive view.”
That shorter definition preserves what is known. It also leaves a real question visible: does archiving change who can access the collection? The supplied notes do not answer it. Record that question for the product owner; do not infer an answer from another app that uses the same word.
Keep examples from becoming new rules
An example should illustrate the definition without adding a requirement. “A collection for your book club” is one possible use. “A collection for up to twelve book-club members” invents a limit. “Restore it whenever you want” introduces a duration promise that is absent from the source. Review the examples as carefully as the first sentence.
Use generic, fictional details when demonstrating a feature. If an example needs a screenshot, make sure the labels match the current interface and the account contains no private material. The illustration and definition should teach the same behavior; an outdated button name can make an otherwise accurate explanation difficult to follow.
Use a prompt that exposes unanswered questions
Try: “Using only these approved product notes, draft glossary entries for collection, draft, shared, and archived. Preserve exact interface labels. Give each term a plain-language definition and one optional example. Do not add permissions, limits, storage behavior, retention periods, or guarantees. List unanswered questions separately from publishable text. Identify the source sentence supporting each definition.”
Check those source matches yourself. A model's claim that an entry is supported is not verification. If you use the AIUndetectable humanizer to explore more natural wording, compare the revised definitions with the approved notes again. Natural phrasing and detector results cannot establish how a product behaves.
Check the glossary in the place readers use it
Ask a colleague unfamiliar with the app to explain the difference between draft, shared, and archived after reading the entries. If they assume “shared” means public, improve that distinction. If they ask whether archived collections remain visible to members, take the question back to the product owner. A reader's uncertainty can reveal a missing rule, not merely a writing problem.
Before publishing, confirm the labels, example links, and first-use explanations across the relevant help pages. Keep the approved source beside the glossary so a future product change has an obvious editing starting point. Our source-of-truth guide explains how to maintain that connection. The finished glossary should help readers understand the actual product without quietly designing a different one.