A product glossary should give each important business concept a clear meaning and consistent user-facing label. Distinguish concepts that affect different actions or states rather than using several attractive synonyms interchangeably. Terminology is part of the workflow: changing a label can change what users think they are committing to.
Let’s plan your product terminology.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Collect language from actual tasks
Review forms, navigation, emails, reports and support questions. Ask users what terms mean in context. A developer's Request object and a finance team's Payment request may not refer to the same thing.
For a hypothetical procurement app, supplier, vendor and payee could overlap but still have distinct responsibilities. Decide which distinctions the product needs and record them with domain owners.
Create a terminology register
| Entry | What to record | Example question |
|---|---|---|
| Preferred term | User-facing name | What should the screen call this record? |
| Definition | Meaning and boundary | Does it include drafts? |
| Related concepts | Differences that matter | How is a request different from an order? |
| State labels | Permitted lifecycle meanings | Does Approved mean posted or merely reviewed? |
| Avoided terms | Misleading synonyms | Which label caused support confusion? |
| Ownership | Who approves changes? | Which domain role resolves disagreement? |
Keep definitions short enough to use in design reviews. A glossary that nobody can understand without another document will not guide interface decisions.
Apply terms across channels
Use the same meaning in the app, confirmation messages and downloadable reports. If an integration uses a different external name, document the mapping without forcing internal codes into every user-facing label.
Review verbs carefully. Save draft, Submit and Approve communicate different consequences. A generic Done button can hide an important transition and make recovery harder to explain.
Validate comprehension
Ask representative users to predict what an action will do and explain the state they see. Test with people new to the product as well as experienced staff who may have learned its quirks.
Record terminology changes alongside product changes. Update help content, translations and analytics definitions where meaning changed. A renamed metric should not silently become a different calculation.
Glossary questions
Should the interface use the database's field names?
Only when those names are also appropriate to the user. Maintain an explicit mapping where internal and user-facing terms differ.
Is consistency more important than familiar language?
Choose language users understand and use it consistently for the same concept. Preserve meaningful distinctions rather than forcing one word onto different tasks.
Pair the glossary with UX research planning, and review the most consequential labels with Drema's UI/UX team.