There’s this game I play called Dota. It’s competitive, strategic, fast-paced, and it’s taught me a lot about teamwork.
In the game, there are over 100 characters to choose from, all with different abilities and complementary roles. My favourite part is how they combine in different ways to face off in a 5-on-5 match. Individual skill offers limited success. It’s a team’s ability to conceive and adjust a strategy that actually nets them wins.
Watch this video of a competitive game and listen to how rapidly they update their plans. It’s a fast game. If the team stops talking, they’ll fall apart in seconds.
Beyond both Russian and English, they’re speaking the language of Dota. There are a ton of loaded terms in a professional Dota player’s vocabulary and players use them to their advantage by communicating succinctly as their team updates plans. Each player has a different role, but they all speak the same language.
What language does your team speak?
Google thinks that the future of work will be more team-based, but that’s already what work looks like for many of us working on digital projects. It’s difficult work. Things change fast. The landscape is constantly shifting while we struggle to keep up. Language is a force that can either work for you or against you. As such, your team should be working together to build a shared vocabulary. Having one will get you to yes faster during meetings. The sooner everyone can get on the same page, the sooner you can make a decision.
Sharing a vocabulary empowers your team. Many of you know what I’m talking about. You’ve probably experienced it before. I’m talking about those times when you and your teammates are deep into it, ironing out the last kinks in a project launch. You’re working in sync and everything is clicking. You’ve invented terms and titles that make sense to you but sound totally weird to anyone not on that project because they’re not fluent in the project’s language. That’s a shared vocabulary at work.
Not my job.
Three words can kill an entire organization.
Words move mountains—and projects
Sometimes we get precious about our roles. But when you look at the big picture, all our jobs are the same: getting the work out the door and into people’s hands.
Scenario #1
Your developers are heads down building components for a project that’s fallen behind. At the same time, the designers are increasingly concerned that brand standards aren’t being met.
When the developers talk about the components at the daily stand-up, their descriptions sound different and more and more complicated. The designers, confused, stay out of the code despite knowing HTML and CSS.
Meanwhile, the project manager is figuring out how to translate what the developers are describing to make sure the components correspond to the list of features they agreed to implement.
Yes—in this example the developers look kind of bad. But it’s not their fault. Their vocabulary is subject to change faster than others. They do more translation than most: mapping constantly changing project requirements against the tools they have available and ultimately turning all of that into code.
Because of the speed at which our projects move, it’s easy to lose people—even on small teams. It doesn’t help that many of us work with people from different disciplinary backgrounds that have their own disciplinary languages. You probably have your own too. But if you can connect all those languages to the project, then the project also becomes a powerful conduit for sharing all that interdisciplinary knowledge.
Scenario #2
You walk up to a whiteboard and sketch out a new page. You draw a few rectangles. You scratch your chin a bit and then you label them, trying to give each rectangle a name that suits its function. Sometimes you follow common conventions, sometimes not. One or two post-its get a question mark that you’ll come back to later. You head to your desk and get down to work.
These naming decisions will impact the entire team. But too often, we create terms and categories without enough thought. The moment of conception for any feature, component, product, or web element spawns useful (or not!) terminology that will get used by every designer, developer, and manager involved in the project. All those people will have to use and understand (or not!) those names in their daily work, too.
There are only two hard things in Computer Science: cache invalidation and naming things.
Building a project’s vocabulary
You and your team can prevent future headaches by putting some thought into a shared language up front. Let’s go over some basic aspects of a project vocabulary that you’ll want to develop: adjectives, verbs, and nouns.
Adjectives
The qualities of a project
Adjectives are the guiding principles for project decision making. They will likely be the most stable words you introduce into your project’s vocabulary.
When you start a project, ask yourself: what characteristics should this project take on? What would honour the brand and acknowledge the user’s goals? The answers to these questions will influence many project decisions so determine your adjectives early on. Many companies, like MailChimp make boundaries for the adjectives they want their project to have and include them in a style guide:
- Fun but not childish
- Clever but not silly
- Confident but not cocky
Make note of which qualities you want your project to have. Make them concise, memorable, and visible. MailChimp made a small site dedicated to theirs, but post-its on the wall or a note on the whiteboard can work just as well.
Verbs
The -ings of your project
This is where your project will get swept up in the waves of the industry. There are many jobs to do before a project ships and people are inventing new ways of doing those jobs every day.
Here are some common project tasks that might need dedicated verbs:
- Research
- Wireframe
- Interaction design
- Data analysis
- Styling
- 3rd party integrations
How many jobs on your team go unmentioned, are misunderstood, or unthanked? Everyone in your team probably has a specific role or job title. But those aren’t necessarily the roles they’ll have in delivering the project. Those jobs deserve definition too.
When designing your process, consider doing a lightweight skills matrix with your team to identify the different verbs for that project. Creating a vocabulary for all these different jobs is also a good way to recognize each team member’s contributions while also making sure your team doesn’t cut corners.
Nouns
Your outputs, and the tools you used to make them.
These are the meat of your project, what everyone gets the most fired up about. These are the headers and the footers, the sidebars, the add to cart widgets, the headers, titles, bylines, and labels.
Nouns are most often a signifier for something visual. Whenever possible, include a drawing, sketch, or screenshot of what the name represents. Nouns are what the guy in the whiteboard scenario struggled with. This stage is where the bulk of the invention happens, but you should try not to be too clever with your names; follow conventions whenever possible unless you invent a novel piece of functionality that is totally unique to your project. In that case, go ahead and name it something extraordinary.
Achieving adoption
The larger the team, the larger the problem of nomenclature becomes, especially when it comes to achieving adoption. The difference between a title and a caption can get lost as work travels between departments.
These are the words your team will use every day for the duration of the project so you will want to make sure everyone is on the same page. Here are my favourite ways of getting a team to agree on language and terminology:
Follow conventions
This is an important first step so I’m stressing this point again. Try to refrain from being excessively creative.
Asking for details when you hear an unclear term
It can be a simple question like: ‘What were you referring to when you said ____?’ If the questionable term is a one-off coined in the late stages of a project, then it probably won’t come back to haunt you. However, if you created it early on when features were first getting established, it could cause unnecessary confusion down the road.
Documentation
This step gets ignored far too often. Yes—it’s easy to neglect documenting terms and it is just as easy for others to ignore existing documentation. But if you work in a larger team, documentation will be paramount to the success of your project’s vocabulary adoption.
Flexible component labels
Paste-up wireframes or mockups on a wall and then use post-its to label all the components. These have the benefit of being flexible while also making the changes highly visible. It feels more organic and adaptable like real languages often are.
The payoff
When you’re moving quickly and trying to meet deadlines, your team will face any number of challenges. With a shared language in place, you can say more with less. You will have the ability to communicate succinctly, adapt, and act in unison. And you can be confident that when the team gets heads down into execution they’ll all be on the same page.
Go get ‘em!
