Creating a shared glossary of UX terms for your project

UX teams often use familiar language without checking whether everyone means the same thing. A “user” may refer to a customer, administrator, student or support worker, while “accessibility” may be treated as a compliance task rather than an experience requirement. These small differences can create large gaps in research, design and delivery.

A shared glossary gives a project one dependable vocabulary. It records important terms, explains how they are used, and makes decisions easier to trace. For teams working across Melbourne, Brisbane, Perth or regional Australia, this is particularly useful when colleagues, suppliers and stakeholders collaborate remotely.

The glossary should support practical work rather than become a static dictionary. Terms can be connected to personas, use cases, usability findings, accessibility reviews and product requirements. In UCDmanager, a project team can keep this material alongside its broader user-centred design documentation.

The best time to begin is early, before research notes and interface decisions become filled with unexplained abbreviations. Start with the words your team already uses, then refine definitions as evidence emerges from interviews, testing and design analysis.

Start with the language already in use

Collect terms from project briefs, workshop notes, Jira tickets, research plans and customer-support records. Look for words that are ambiguous, frequently shortened or used differently by different disciplines. Common examples include task, journey, scenario, requirement, conversion, error, prototype and accessibility issue.

Ask representatives from research, product, design, engineering, content and customer operations to review the initial list. Australian organisations may also need input from legal, government-relations or service-delivery teams, particularly when a digital service must align with the Disability Discrimination Act 1992 and the Australian Human Rights Commission’s accessibility expectations.

Each entry should have a plain-English definition, a preferred term, related terms and a short example from the project. Add the date, owner and review status so the glossary remains accountable. Avoid definitions copied from textbooks if they do not help someone make a decision in the current product.

For example, define “primary user” as the person performing the main task, then describe that task in context. A warehouse supervisor in Sydney may use a tablet between deliveries, while a regional health worker may rely on an inconsistent mobile connection. The examples make the term operational rather than abstract.

Separate similar concepts clearly

Many UX misunderstandings come from near-synonyms. A persona is a research-based representation of a user group; a user role describes responsibilities or permissions within a system. A use case explains how an actor interacts with a product to achieve an outcome, while a user story usually expresses a need in a compact delivery format.

Teams can strengthen this distinction by linking definitions to working artefacts. Guidance on writing effective personas can help establish what evidence belongs in a persona and what should remain a hypothesis. UCDmanager’s persona workspace also provides a useful reference for organising these profiles.

Include a “do not confuse with” field for terms that regularly overlap. For instance, explain that an accessibility defect is a barrier affecting access or use, whereas a usability issue may affect efficiency, clarity or learnability without necessarily creating a disability-related barrier.

This distinction supports better reporting. A keyboard-navigation failure, unclear form error and slow page response may all harm an experience, but they require different investigation methods, owners and acceptance criteria.

Make definitions useful during research

A glossary should influence research planning, not merely document terminology after a workshop. Define terms such as participant, recruitment criterion, observation, insight, finding, assumption and evidence. State whether “finding” means an observed behaviour, an interpreted pattern or a validated problem.

When planning usability testing, agree on what counts as task success. It might include completion, accuracy, time, confidence or the need for assistance. Recording these meanings prevents teams from comparing results that were measured in incompatible ways.

Local context deserves space in the definitions. A participant recruited in Canberra may have different service expectations from someone in a remote community, and a public transport journey in Sydney may involve different constraints from one in Adelaide or Hobart. The glossary can document relevant contexts without turning regional differences into stereotypes.

It can also capture inclusive research practices. Define how the project uses interpreters, captions, screen readers, translated materials or assisted digital support. If a participant cannot complete a task because the prototype excludes their input method, record that as a research condition rather than blaming the participant.

Connect terms to design and delivery

The glossary becomes more valuable when each important definition is connected to project decisions. A term such as “critical task” should point to the relevant use case, persona, success measure and test evidence. A term such as “content pattern” can link to examples, accessibility requirements and approved language.

Set a simple rule for new terms: anyone may suggest one, but an appointed product or UX owner approves the definition. Keep a change history for terms that affect requirements or acceptance tests. This is especially helpful when an organisation has distributed teams in Perth, Sydney and regional offices.

Technical language should be included where it affects experience. Define performance measures such as response time, load time, availability and error rate in terms that product and UX colleagues can understand. A practical explanation of performance monitoring tools can help teams connect user complaints with measurable system behaviour.

Use the glossary during backlog refinement and design reviews. If a ticket uses an unapproved synonym, replace it before work begins. Consistent terminology reduces rework in requirements, interface copy, test scripts and release notes.

Support remote and low-connectivity work

A collaborative glossary must remain usable when people work from home, travel between offices or operate with limited bandwidth. Australian teams may include staff in regional Queensland, the Northern Territory or Western Australia, where connectivity can be less reliable than in inner-city offices.

Keep entries short, searchable and readable on mobile devices. Avoid large attachments when a concise example or linked project record will do. Teams designing education services can also consider lessons from offline learning access, particularly when a product must remain useful during interruptions.

Provide an export or backup method so the vocabulary is available during workshops or temporary service outages. A glossary that exists only inside one tool can become a barrier if a supplier, community partner or workshop participant cannot access it.

Use labels such as draft, approved, deprecated and project-specific. This lets readers distinguish a stable organisational term from a temporary phrase created for a pilot or discovery activity.

Review the glossary as the product changes

Schedule a short review at key points: after discovery, before usability testing, during accessibility evaluation and before launch. Remove duplicate entries, clarify vague wording and retire terms that no longer describe the service. Do not delete historical language if it explains an earlier decision.

Track useful signals such as repeated clarification questions, inconsistent labels in designs, conflicting test instructions and defects caused by terminology. These signals show whether the glossary is improving collaboration rather than simply growing in size.

Invite content designers, developers and customer-facing staff to challenge definitions with real examples. A term that appears clear to a UX team may be confusing to a call-centre adviser or a person completing a government form on a phone.

Over time, the glossary becomes a shared project memory. In UCDmanager, it can sit beside research findings, personas, evaluation records and requirements, giving every contributor a common language for discussing users, evidence and outcomes.