How often have you fought bitter battles over the names of buttons, actions, or processes? Do you remember capitulating to terrible names just because your seniors demanded it? As technical writers we are naturally sensitive to words, but others rarely share the same feelings.
Names Hold Power
Words evoke feelings and associations in the reader and hold the ability to confuse or enlighten in equal measure. A solid terminology base holds a project together, creating a shared understanding not only between customers and developers, but also between development teams. I can recall more than one meeting where parties argued, not because they had different points of view, but because of terminology confusion.
Get Buy In
You need your project leads to act as champions for the terminology. They should use the terminology in emails, draft plans, and any written or verbal content. Most project leads understand the need for this consistency; it really does save pain later in the project. Especially with larger projects get the projects leads together to get their group buy in on terms and definitions.
This type of meeting can also help to solidify your “expert status” and assists in cementing a communal understanding between larger teams. Having experienced this first hand on many occasions I can say these meetings can be “fiery” but well worth it in the end and very positive experiences for all involved.
Define Early
Strive to define precise project terminology early in the development cycle. If you wait too long, older, defunct terms can become ingrained in your project members memory and surface later to confuse customers and ticket-solvers alike. Define not only your terms, but also the synonyms that you aren’t using to eliminate confusion.
The Right Tool for the Job
Finding the correct term for an object or process can be challenging. Between scientific, industrial, academic, and other terminology types it can be hard to find the perfect term. Start out with accepted terminology for your industry, then look to experts in your field, and lastly consider the context and reader: a text intended for use by someone in emergencies should be short and readily identifiable, while one intended for complex accounting process might sacrifice utility for precision.
Your Turn!
Do you prioritize terminology for your projects? Do you struggle with buy in? Have you got any great tips to share with the community?
