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.