A payroll product's screens call the same thing 'pay run', 'payroll batch' and 'pay cycle', and users file tickets about it; how would you fix terminology across teams?
answer
- different words imply different things
- inventory the strings first
- users' words and legal meanings
- glossary with rejected synonyms
- checks so it stays fixed
basics
~20 sAudit the terms in use, choose one term per concept from the words users and the law actually use, publish a glossary with definitions and rejected synonyms, update every surface, and add checks so new copy stays consistent.
solid answer
~50 sUsers assume different words mean different things, so 'Is a payroll batch the same as a pay run?' becomes a ticket - and in payroll, some terms carry legal meaning. First I inventory the strings across web, mobile, emails and help content and cluster synonyms by concept. For each concept I choose one term, weighing what users and payroll professionals already say (tickets, search logs, interviews), any legal definition, and whether it is distinct from neighbouring concepts - 'pay run' versus 'pay period' versus 'pay date'. The **glossary** records the term, a definition, when to use it, rejected synonyms and capitalisation. Then I update every surface in one pass, including help articles and notifications. To keep it fixed: a named owner, string review in code review, a check that flags rejected synonyms, and a ticket count to confirm the confusion drops.
go deeper
Use the glossary's preferred term for every concept and never introduce a synonym, even to avoid repeating a word.
Explain why users read synonyms as different things, what a glossary entry contains, and why rejected synonyms are the field that prevents drift.
Show how you would inventory terms across platforms, choose one per concept from user and legal evidence, roll it out in one pass and add checks.
Weigh regional legal terms against a single global vocabulary, and decide who owns terminology when many product lines share one system.
## Why inconsistent terms hurt When one concept has three names, users do not see three synonyms; they see three things. A payroll manager who approves a 'pay run' on one screen and is then asked to 'close the payroll batch' on another reasonably wonders whether there is a second step they have missed. The results are predictable: - **Support tickets** asking whether two terms mean the same thing. - **Errors**, when users act on the wrong object because the words did not match. - **Failed searches** in help content that uses a different term from the interface. - **Onboarding cost**, because new users must first learn which words mean the same thing before they can learn the product. - **Legal risk** in HR and payroll, where words such as 'employee', 'contractor', 'gross pay' and 'net pay' can carry defined meanings. ## Audit what exists 1. **Inventory the strings** - interface text from every platform, emails, notifications, exported reports and help articles. 2. **Cluster by concept** - group every term that refers to the same thing, and note where one term is used for two different things. 3. **Count and locate** - how often each variant appears and which teams own it; this shows the cost of each choice. 4. **Collect the users' words** - support tickets, search queries, sales calls and interviews reveal what customers call the concept. ## Choosing the term | Criterion | Question to ask | |---|---| | User language | What do payroll managers already call this? | | Legal and industry meaning | Does a law, contract or standard define the term? | | Distinctness | Does it stay clearly different from neighbouring concepts? | | Durability | Will it still fit when the product adds features? | | Brevity | Does it fit in labels and table headers? | User language and legal meaning usually win over internal names. A term engineers use in the database is not a reason to show it to users; the interface and the code may legitimately use different words, as long as the interface is consistent. Distinctness deserves special care. A payroll product has several neighbouring concepts - the **pay run** (the process of calculating and paying), the **pay period** (the span of work being paid for) and the **pay date** (when money arrives). If the glossary defines all three together, writers stop using them interchangeably. ## The glossary entry A useful entry contains: - **the preferred term** and its capitalisation; - **a one-sentence definition** in plain words; - **when to use it**, and when a neighbouring term is correct instead; - **rejected synonyms** - 'not payroll batch, not pay cycle' - which is the field that most prevents drift; - **an example** of the term in a real label and a real sentence; - **the owner** who can approve changes. ## Rolling out the change Change every surface in one coordinated pass where possible: interface strings on every platform, notifications and emails, help articles, onboarding content and sales decks. A half-finished migration creates a fourth state - old and new terms side by side - which is worse than the start. Tell support staff first, so they can answer questions during the transition. Where the old term appears in data users can see - exported reports, column headers, saved filter names - plan those too. Keep the old terms findable in help content for a while, listing them as 'formerly called', so people who learned the old words can still find answers. ## Keeping it consistent - **A named owner** for the glossary, usually a content designer or the design system team. - **String review** as part of code review for any change that adds interface text. - **Automated checks** that flag rejected synonyms in new strings. - **A route for new terms**, so a team launching a feature proposes its terms to the glossary before shipping. - **Measurement** - ticket volume and search failures for the affected terms should fall; if they do not, the chosen term may not match how users think. Terminology is one of the cheapest parts of a product to get right early and one of the most expensive to fix late, because every surface and every team's habits carry the old words.
- Engineers call it 'batch' in the code; should the interface follow the code?No. The interface should use the users' term, and the code may keep its own name if renaming it is costly. What matters is that the mapping is written down so engineers know which word to show. Leaking internal names into the interface is one of the commonest sources of terminology drift.
- What do you do when two legitimate terms exist because of different countries' payroll laws?Treat it as two concepts or as one concept with regional variants, and decide explicitly. If the law defines different things, show the legal term in each region and define both in the glossary. If only the words differ, pick one per region and keep it consistent within that region. Either way, the glossary records the rule so teams do not improvise.
saying these in an interview costs you the question
- Varying the term keeps copy from sounding repetitive.
- Internal engineering names are fine in the interface because they are precise.
- A glossary is a one-off document; consistency follows once it is written.
- Terminology is a cosmetic concern and cannot cause real user errors.
- Each team can keep its own terms as long as its own screens are consistent.