When collaborating with people from different domains and departments on a project, a shared understanding of words and their meaning is key to preventing frustrating and time-consuming mistakes.
A colleague and I once famously spent more than half an hour discussing the term "copy deck". It was part of a project briefing and we had very different opinions about what the term means. Heated arguments and a massive undertaking in information retrieval ensued. It wasn’t exactly time well spent and the argument could have most likely been easily avoided if we had a common glossary.
When collaborating with people from different domains and departments on a project, a shared understanding of words and their meaning is key to preventing frustrating and time-consuming mistakes.
How many times have you been in a meeting where two people are talking about the same thing, but confusing each other with slightly different terminologies. Or even worse: very different meanings for the same word.
Language is often messy. Take a minute and think about the different words you have seen people use to describe the following UI element:
From the top of my head the following terms come to mind:
This is just one example of somewhat abstract terms that can be explained to us in very different ways. These abstract terms describe processes, roles we assume in these processes, design deliverables, and tools or methods we work with. If you have a couple of hours to spare, try to determine the difference between UX and CX, or try to find a definitive definition of "Jobs To Be Done". You get the point - you can’t.
A team that lacks a shared vocabulary is more likely to waste time and resources due to misunderstandings about what means what. This is even more likely to happen with remote teams and people who are not communicating in their native language. Luckily, there are things you can do to prevent this from happening.
People often don’t like admitting not knowing the meaning of technical terms used by colleagues or clients. A lack of understanding what the other party is talking about could fuel the fear of appearing incompetent.
On the contrary: asking your colleague to define what they mean when they mention “content strategy,” for example, shows that you paid attention and really want to understand them. It is entirely possible that you also clarified the term for others in the room who were also afraid to ask.
Your team should have a unified language when communicating with clients. If you find that there are a multitude of ambiguous technical terms and abbreviations floating around, it’s useful to sort them out once and for all. This can be done in a workshop where you:
A simple list that is shared throughout your organization is a great start. Make sure that it is up to date and ensure to keep everyone informed about new revisions. You could even use this exercise as a catalyst for creating a UX Playbook – a document which lists and explains your tools and methods – to help onboard coworkers.
We have to constantly remind ourselves that the language used in UX processes (think “heuristic evaluation”, “think-aloud method”,”How Might We’s”) is not necessarily accessible to other coworkers. We need to clearly make our points using words that everyone in the room understands. A shared glossary goes a long way to making that happen.
This article is my contribution to this co-created book. The individual chapters highlight different but important aspects of the UX work environment and offer beginners a good insight into the multi-layered aspects of this discipline.