Most weeks I am ridiculed by someone for insisting on plain language – avoiding acronyms and technical language / jargon in particular. People tell me that I’m slowing the team down by making them use proper words, and that their end users or stakeholders expect them to use technical language.
These things are both true. You should still use plain language.
Technical language is exclusive.
If you know all the fancy terminology then you’re allowed to fully participate, if not, you’re at least partially excluded. This is unfriendly and can also severely limit the number and type of people who can fully contribute to the work your team is doing.
Recently someone insisted that they needed an incredibly experienced and excellent user researcher who was an expert in all the technologies associated with commercial banking. Do you know how many of those people their are in the entire world? not many.
Do you really want to make hiring that hard for yourself?
If you use plain English in your team, then more smart people can be involved and help you to think about ways that you can improve. That is a good thing.
Technical language bundles assumptions.
If you are in the business of transforming service design, then you are in the business of questioning assumptions. You are constantly asking: what is this really? how does it really work? is it actually the right thing? does it really need to be that way?
One of the best ways we can do this is to keep questioning things until they are broken down into their most basic parts.
We stop calling things by their name (‘we’re working on the registration form’) and we start talking about what things do (‘we’re working on a way people can to access health benefits more easily’).
We can recognise opportunities to design things better and differently by describing and understanding the real intent of each component.
Technical terms and jargon almost always bundle up assumptions about the necessity of a thing that, if unchallenged, allow teams to completely miss the real opportunities for transformation.
Plain language is slower.
Yes, switching to using plain language is slower for those who are proficient in the technical terms. It’s not slower for the rest of us. Anyway, there is no advantage in doing the wrong thing faster. (Or, at least, there shouldn’t be).
Plain language is unexpected.
Yes, your colleagues in banking, government, etc. will be surprised and maybe even scornful when you stop doing the linguistic secret handshake and start using plain language. This is no reason to revert to jargon. This is your chance to change culture, one word at a time. Really, it’s the easiest bit of transformation you can do in your organisation ever single day.
Starting now.
Great advice!
Reminds me of Elon Musk’s email forbidding acronyms at SpaceX: https://twitter.com/davejohnson/status/602951117413216256
Avoiding unnecessary jargon is also a good recommendation for social movements, who often develop so much of their own language that they are unable to communicate effectively or empathetically to uninitiated outsiders.
“every single day” not “ever” ;)
Otherwise, I feel really strongly about this article. I think its a lot easier to do when you’re defining your own space and your own company, however if you’re a B2B company, you often have to (questionably?) adopt industry language to communicate with your clients, otherwise you’re the uninitiated outsider. Thoughts on climbing that mountain?
This is also a good way to know if your team, or the contracting team, truly understands what they are trying to do for you. If they can’t break it down, they don’t understand it themselves.
This is different than being able to explain complex concepts requiring years of experience to master. They key is in the word breakdown, not the concept itself.