Terminology Isn’t Just for the Documentation Department

An Interview with Val Swisher

During Lavacon 2011, I sat down with Val Swisher of Content Rules to discuss the importance of terminology when it comes to thinking about your content strategically. I discovered that the terminology underpinnings of your content strategy are often a much bigger undertaking than I had imagined and that they can be infinitely vital to your company’s budget and brand.

If you’ve already implemented a metadata strategy, you’re doing well, but you could have a long way to go in planning and implementing content strategy if you haven’t fleshed out terminology.


JS: What is terminology?

VS: Terminology is essentially word choice. Everyone sits down and says “not that word or that one, let’s use this word.” But this is a choice that is only effective when it’s shared. So it’s important to create a lexicon that’s used company wide. This can start with documentation department, but you need to align these decisions throughout the whole company. From pre-sales marketing, all the way through legal/branding, right to the end-user documentation and training content, then carry it through to support content in knowledge base articles.


JS: Why is terminology important?

VS: If you’re using the same terms in the same way throughout the user’s experience of content, then you’re maintaining a good relationship with them. If you don’t use the same terms, if you switch words and phrases, users are going to be confused first, and then simply not be able to find content. If you use the word “dog” in marketing material, “boxer” in user documentation, and “canine” in training and support material, the user learns either that you’re “missing” content (because they can’t find it under the word they’ve been exposed to) or they learn not to trust you. It’s not a consistent user experience, which means you’ve shattered their view of the product and of your company. This is bad business.


JS: What parts of DITA support terminology?

VS: Companies tend to be good at it when creating terminology metadata for their user documentation. But when creating content that is a mixture from various chunks that people have written [across departments], single sourcing terminology is now mixed. The end result is a fractured or shattered reality for the user; it’s no longer a seamless user experience.

The first step can be conref’ing product and feature names as variables. But this doesn’t cover enough content for the purposes of standards, translation, and efficiency. For example, word choice for “Select, hit, click,” when selecting a button in the UI is not something you can have controlled by conrefs. You need something that says “it will always be “’select,’” or whatever you choose.


JS: How do you maintain this tight control over word choice? It sounds pretty difficult to enforce across departments.

VS: Yes, it can be tough. But governance of terminology is the key. There are two aspects to governance. First is consensus: People who represent different avenues of content creation all need to have their say but have to come to a consensus. Third-party consultants are very useful here when you need to do an end-run around politics. The consensus has to include words that are permitted, deprecated, and possibly allowed but not ideal. The second aspect of governance is enforcement, and this is not easy. Enforcement can either be done as a “push” or a “pull”. The problem with the pull method is that no one actually does it (requires them to be pro-active and check the list). Sometimes new writers will look up terminology and check writing against list, but mostly it’s either not done or it’s wildly inefficient. And don’t forget it’s a constantly changing list if terms. The pull method turns out to be ridiculous and is NOT a good solution. But it’s what people are doing right now. A big disaster!

The better way is the push method. As I’m writing, the magic button reads the documentation I’m writing to look for terms that are not allowed. This means I need a central database that checks terminology, which, don’t forget, can change daily. Across an entire enterprise or company, it’s software that says “you used the wrong word here” and more importantly, suggests the correct term. A tool that doesn’t suggest a correct term is practically useless and ends up frustrating everyone.


JS: OK, so we’re talking some serious tools that can be implemented company wide. What are the options and what should people look for?

VS: Yes, there are a number of tools out there that can do the job. You’re looking for automated workflows for efficiency and well as a way for authors to submit suggestions back to the terminology managers. There are tools that do this like Acrolinx and Congree. SDL has terminology built in and can integrate with translation memory (as can Acrolinx). There are other tools out there; so like any other tool, you need to figure out your requirements and budget, and then find the right tool for you.


JS: This seems like a costly endeavor.

VS: Yes, but the bigger cost is not managing it. It’s easy to measure increased translation costs due to inconsistent terminology (and those are wickedly high), but brand impact, reputation, and buzz? It’s hard to measure the loss of revenue because of those. One tweet about how bad your documentation is can be devastating.

But of course, the huge [measurable] savings are in translation costs. Consistency in terminology can save millions (easily) in translation costs as soon as you’re translating to more than a couple of languages.


JS: So what strategies should people developing terminology keep in mind?

VS: The terminology must be maintained rigorously, and by each group that has buy-in to the terminology development in the first place. You can’t leave a group out. It’s also vital that strategy includes customer word choice. If you’re deciding which terms to use in a bubble without user input, then you’re guessing and you’ll guess wrong. The point is for the customers to find the content, so use the words they would use.


JS: So developing and using consistent terminology can make or break a company, all the way from costs to reputation.

VS: Yes. In the end, what we’re doing is selling content and it has to be a uniform experience. If the content doesn’t use the same words across the board, it’s a mess.


Key Points:

  • A consistent and tightly managed lexicon is critical to content and brand
  • Implement a governance process incorporating consensus and enforcement
  • Select and implement the right terminology management tools for your requirements and budget
  • Stakeholder buy-in and inclusions of customer word choices are keys to effective management of terminology

Mark Baker

13 years ago

I certainly agree with Val that consistent terminology improves comprehension and reduces translation cost, but there is a wrinkle here. If we are looking at consistent terminology as an aid to comprehension, what counts is consistent terminology across the user’s whole experience. If we are internally consistent, but at odds with everything else that the user hears and reads, we are not providing them with consistent terminology, and not enhancing their comprehension.

This would not be such a big problem if all our users used the same terminology for the same things. We would simply have to discover the user’s terminology and use it consistently in all our communication. But in fact, different users, and different user communities, do not always use the same terminology for the same things.

Imposing a uniform technology across an enterprise could therefore mean imposing an unfamiliar terminology on the users of some of the company’s products. It then becomes a choice between consistency within the company, and providing consistency within each user community.

The problem can get worse when you are dealing with a product which itself crosses user communities. This can occur particularly when developing products that are subject to certification. In some cases, the certification authorities have a defined (and artificial) terminology which is not shared by the people who actually use the regulated product. If you don’t use the terminology used by the regulatory body, you risk losing certification or having certification be delayed or more expensive to obtain. If you do use the terminology of the regulatory authority, you risk confusing users not familiar with that terminology (and likely being mocked by plain language advocates).

And, of course, if you have some products that require certification, you will have to deal with the question of whether they will use the terminology of the certifying authority or your corporately mandated terminology.

Overall, my point is this: terminology is local. While having a strategy for managing terminology is certainly important, that strategy has to recognize that terminology is local, and that you are probably going to have to deliver content to multiple locales. A strategy that simply imposes uniform terminology across the board, therefore, has the potential to do more harm than good.

TechWhirl Tech Writer Recap for December 9 2011 | Tech Writer Today Magazine by TechWhirl

12 years ago

[…] LavaCon 2011: Interview with Val Swisher on Tech Writing Terminology […]

DocSoup Digest 002 | DocSoup

12 years ago

[…] Terminology Isn’t Just for the Documentation Department (EN) […]

Subscribe to TechWhirl via Email