My friend who visited me in Vienna for the past week was set to return home on Easter weekend, but options were limited. Easter is a bad time to travel. There’s traffic, trips cost more, and you’ll likely get delayed at least once.
The best option for him was a rideshare. Someone else would be driving, he’d pay less than with the train or Uber, and get to his home in Germany sooner.
After looking at the reviews, he started talking to a driver about booking the route with them. My friend told the driver he had a large, 23 kg suitcase with him. The driver’s response confused and cracked me up.
You can give your SUITCASE in a day 😉
if you want
The all-caps SUITCASE made me curious. The wink emoji confirmed that something was being said between the lines.
My friend wasn’t sure what he was being offered, but he politely declined and thanked the driver. The driver clarified:
With Suitcase I meant The Green Ones) let me know if you will book. Thanks!
My first thought was drugs, specifically marijuana. The driver confirmed the assumed information exchange to the rider, my friend, and let them know they were okay with transporting The Green Ones, maybe even with them lighting a joint during the ride.
This information exchange got me thinking about how fascinating language is and how much we understand even through elusive text conversations with strangers.
The driver could be referring to all sorts of green things, but through the little context we have, we assume that he isn’t referring to green things like edamame, frogs, pesto, or four-leaf clovers.

AI Policy: All content on this website is written by me. I do not use AI such as ChatGPT or other LLMs to generate articles from prompts or similar. All content reflects my own thinking, ideas, style, and craft. Occasionally, I ask AI (such as Frase or Formalizer) to summarize or re-state my own ideas on the basis of a complete skeleton I’ve written. Based on the response, I may reorder, restructure, or alter my original thinking. I personally write each draft and final copy.
In this article:
Benefits of a shared language
The green ones or Big Suitcase may be widely recognized metaphors in the world of cannabis consumers, particles of a secret shared language.
There are many reported cases of people creating languages. John W. Weilgart released the book “aUI: The Language of Space” in 1968. Weilgart claimed that a green alien taught him the aUI language. I created my own language when I was a kid. The language contained tens of symbols; alas, no aliens were involved.
Groups develop their own unique language, whether among friends, couples, fandoms, consumers of a certain product, or companies.
Studies show that sharing the same languages helps us work better together.
“Sharing the same languages could enhance performance in both collaborative insight problem-solving and divergent thinking tasks in multilingual teams potentially through better and more efficient communicative and collaborative processes. It is also possible that a greater affinity and affiliation toward the familiar-speaking other facilitated the collaborative process via factors such as accent and ethnicity.”
Yow, W.Q., Lim, T.Z.M. Sharing the same languages helps us work better together. Palgrave Commun 5, 154 (2019). https://doi.org/10.1057/s41599-019-0365-z
Sharing a business language can make it easier to communicate and collaborate with others within the group, improve onboarding for newcomers, and serve to align behavior.
The negative effects of jargon and internal language
If having a common language enhances our collaboration, I infer that a lack of shared language hinders it.
There comes a time when shared languages become a problem, as a design leader at a previous employer discovered. After encountering multiple instances of jargon during his first few weeks, he implemented an acronym Slack bot. Whenever you encountered a term you didn’t know, you could ask the bot privately in a Slack message to explain it. The bot clarified terminology that had become second nature for most employees, but wasn’t clear or immediately evident to new team members.
The author Abby Covert also encountered this problem, documenting “a hundred acronyms in the first week of a project for a large company, only to find 30 more the next week.”
Here are some recommendations from my perspective as an information architecture consultant on how a company can achieve this balance by developing shared terminology (a business glossary) that promotes rather than hinders effective collaboration.
Organize a documentation hackathon – Building a business glossary dos and don’ts
Pick a Friday and make it into a game: whoever gathers the most company acronyms and jargon, wins.
The prize is quite team-dependent. Some people enjoy spending time with coworkers outside of work, and winning a nice dinner with them as a token of appreciation would be greatly appreciated. I once got a gift for a facial treatment from an esthetician I really liked after working hard to meet an aggressive launch timeline for a client. They asked what I wanted, and it’s what I picked. Some people enjoy competing for the sake of it (cough, student athletes, cough), and winning is enough for them.
Gamifying the documentation process makes a fairly tedious task kind of enjoyable.
The short timeline (one full day or one afternoon) also helps make it more bearable.
Where to start with a glossary and documenting shared company language
- Start with an unstructured brain dump. Get as many terms on paper as possible. Don’t worry about their meaning, usage frequency, or offending people at this stage. They’re your notes.
- Review your latest communications in Slack and email. Have you used any acronyms or terms that you’re not 100% sure make sense to people outside your immediate team? Write them down.
- Identify your most frequently used documents. If you’re in sales, those might be pitch decks, proposals, and outreach templates. Read through them carefully, or better yet, hand them over to someone in another field and ask them to highlight acronyms and unclear terms.
- Create small groups with team members from other disciplines, where everyone has to explain their duties and an example of a day in their life, and others note mentions of acronyms or terms they didn’t quite understand.

Think across disciplines – Building a business glossary dos and don’ts
Dissonance confuses people. Ensuring cross-functional collaboration will be key in making this work valuable and usable.
If only the design team gets to document instances of internal terminology and their meaning, the marketing team will continue to use the terminology, but it won’t be consistent across experiences, likely meaning different things in marketing collateral and in-app flows. Your customers don’t view your teams as separate entities, though. They don’t think, “I have a word with the developer who built this,” or “I can tell the designer put a lot of thought into this header,” or “the PM prioritized the right things.”
This is part of the reason I love documentation hackathons. Each team can have its own language, or they may share terms. Getting different teams to document the terminology ensures:
- Everyone is included, which creates a smooth, consistent user experience by not using the same term differently.
- Each team has input in the decision-making process, fostering a sense of involvement and ownership in the project’s success.
Don’t exclude new hires – Building a business glossary dos and don’ts
It’s tempting to consider only including people who’ve been with the company for a year or longer, since they have all the context.
Please include new hires. If you’ve joined a company right after their yearly retreat or a big launch, you know that by the fifth time, shared stories start to feel tiresome if you weren’t part of them.
Including new hires is also a good idea because they’re more aware during this stage. At least where I live, it’s easier to fire a new hire than someone who’s been with the company for years, so people are naturally more careful during the first few months. New hires have likely already asked their managers about a term they heard that didn’t quite make sense to them. Use their fresh eyes to spot tricky terms that you’ve become oblivious to.
Don’t make documentation difficult to access or change – Building a business glossary dos and don’ts
The more loops to jump through, the harder it is to convince people to jump through the first one. If that sounded like the driver with The Green Ones, here’s a more literal note:
Fewer fields lead to higher conversion rates, as long or complex forms discourage completion.
Designing Efficient Web Forms: On Structure, Inputs, Labels And Actions, Nick Babich
If I have to access 3 different platforms, grab my phone for the SSO code, and get Gary from IT to approve my request before I can get in, I’ll likely not do it.
Make it as quick and efficient as possible to access and search the documentation. While not everyone should have editing access to the platform, everyone should be able to request updates or new terms easily.
Don’t use jargon – Building a business glossary dos and don’ts
I can almost hear you protest, using technical jargon is the only way to explain our product without infantilizing readers or undermining their expertise. I have a few thoughts on this, as someone who recently wrapped up an information architecture redesign for vision AI hardware and AI modeling software. Brené Brown says, “Clear is kind,” and I fully agree, while acknowledging there’s a limit to how much you can simplify complex subjects.
In The Magic of Knowing When to Use Concrete vs. Abstract Language, Jonah Berger, a marketing professor at the Wharton School, shares some of my favorite examples of the benefits of using concrete language:
- When customer service agents used more concrete language, customers were more satisfied with the interaction and thought the agent had been more helpful.
- When employees used more concrete language, customers spent 30 percent more with the retailer in the following weeks.
- When prisoners apologize for their actions, those who give more concrete explanations for their transgressions are more likely to be granted parole.
- Using concrete language holds people’s attention, encourages support, and drives desired action.
- Using concrete language to present ideas makes them easier to understand.
If you want to be more concrete, Berger recommends focusing on the how. How does a product meet consumer needs?

How the mind makes meaning
In Louder Than Words: The New Science of How the Mind Makes Meaning, Benjamin K. Bergen asks:
“Suppose I tell you that I was in the park and saw a guy in a purple track suit jog past me. Which way did you see him jogging?”
…You saw him going from your left to your right, didn’t you?
Most people tend to see him heading in that direction than any other. The book is filled with similar fascinating facts related to the concept of meaning. For example, words like “eat,” “pray,” and “poop” evoke different images for different people. In Japan and Korea, the way you hand over small objects to someone depends on who the person is.
From communicating about illegal substances to increasing conversions and affecting parole decisions, language is incredibly powerful. We’re meaning machines, eager to identify and assign significance. 11:11 anyone?
These were my recommendations, based on my expertise as an information architecture consultant helping orgs simplify and standardize their content, on how companies can develop shared terminology that promotes rather than hinders effective collaboration.
Leave a Reply