One of the challenging things about communication skills at work, particularly in creative jobs like design or software engineering, is that we're frequently bridging between different areas of specialization.
Which means that we often use the same words to mean very different things.
For example, when a designer uses the word 'clean' to describe a software product, they are probably talking about an uncluttered visual design, crisp lines, and lot of space.
If a software engineer uses the word 'clean' to describe the same software product, they are likely talking about clear, logical functions and a well-written codebase without much technical debt.
These are very different things! And if you're not careful, this type of difference can very quickly lead to frustrations with designers and engineers thinking they are agreement when in reality they mean completely different things.
The problem is even worse between specializations that are further apart, such as engineering and marketing or sales.
The solution is to carefully and deliberately develop a shared language for describing the work you are doing whenever you are interacting with different teams.
What a shared language looks like
A shared language is one where we have agreement about what things mean. One where we've explicitly defined what we do and do not mean when we say particular words.
And often a shared language is one where you take ambiguous words like 'clean' and add qualifiers that disambiguate between multiple meanings.
To go back to our engineering and design example, we could explicitly specify that instead of using the word 'clean', we're going to use 'visually clean' to mean uncluttered visual design with crisp lines and plenty of space, while we'll use 'cleanly implemented' to describe clear logical functions and a well-written codebase.
By making this distinction, we can keep ourselves on the same page, and also have language for clarifying when we're confused. If someone just says "it doesn't feel very clean", we know to ask "Wait, do you mean visually clean or cleanly implemented?"
How to develop shared language
Developing a shared language is an involved process. It typically involves lots and lots of conversations, asking lots of questions like "When you say 'X', do you mean 'Y'? How about 'Z'?"
As you go through the process, you need touch base both on what is and what is not included.
That said, this process is 100% worthwhile, particularly any time you are collaborating between individuals or teams with different expertise and backgrounds.
The rise in interest in design systems is evidence to me that folks in the software world understand this. A design system is essentially a shared language for user interface between design and development.
But this is not enough. We need to create shared languages between our business and engineering teams, between our marketing and design teams, between ourselves and our customers.
Anywhere we are bridging between worlds, we need to create the language, because that language is the bridge.
Yes, it's a lot of work. But the alternative is talking past each other.
