Latest posts by techwriter (see all)
- 15 Questions to Ask After You Finish a Technical Document Project - February 12, 2018
- THY’s Perfect Information Design - February 9, 2018
- Waterfall vs. Agile Models in Technical Documentation - February 7, 2018
© 2009 Ugur Akinci
You’ve heard it a thousand times and it’s true: you should stay away from jargon and write as you speak. But is this rule true ALL the time, unconditionally? No, it’s not.
There are actually times when you’d better use jargon if you want to be understood. Otherwise you’ll be stamped as an “amateur” and not taken seriously.
Take the term “deconflicting”, for example.
If the context is scheduling your day and increasing your personal productivity, “deconflicting” is a piece of painful jargon that you should avoid.
Instead of saying “You have to deconflict your priorities to finish your homework on time” it’d be a hundred times more preferable to say: “Assign different priorities to your conflicting action items to finish your homework on time.”
But imagine you are writing a manual for air traffic controllers… a totally different context.
For air traffic controllers “deconflicting” is a very real and important concept and ALL controllers refer to that process as “deconflicting” and nothing else.
That’s their common language and lingo.
If instead of “deconflicting” you say “making sure the airplanes have distinct flight paths so that they don’t crash into each other” in order not use “jargon,” they’ll only laugh at you!
In such special context jargon will help you establish your credentials right away as an “insider” and will help you communicate your ideas much more rapidly, with authority. That would help not only you as a professional technical writer but your audience as well since they can concentrate on the content of your copy rather than get distracted by the everyday language you’re using.