In a conventional development cycle, there are multiple document types affiliated with a single product. Whether they’re specifications, user manuals, text-based software GUI, marketing content, or knowledge base materials, all product-specific documents are generally created by different people who, working in parallel, don’t necessarily have access to the documents their peers are writing. Without a degree of synchronization between resources, it’s easy to inadvertently precipitate usability problems, particularly because consumers are simultaneously exposed to every type of user documentation available. So if the user interface and online help for a given product use different terms for key functions, then that creates a user problem, which comes with its own set of costs.
According to a study on usability conducted by Elke den Ouden in 2006, nearly half of all “faulty” products in America and Europe are not returned to manufacturers on account of any technical reasons or malfunctions, but rather because customers can’t effectively navigate the product’s functionality. This shows a compelling correlation between customer satisfaction and product usability, which is in part heavily affected by the consistency of key terminology in explanatory product literature.
To return to the example given in previous section, let’s take a closer look at the development process of a medical device in the Life Sciences industry. As mentioned, product development is seldom executed serially, but is rather the collective effort of several operative teams working in parallel. For Life Sciences manufacturers, there are generally four different steps in the development process: the Feasibility phase, the Design phase, the Development phase, and the Release phase.
In a typical situation, a major portion of new terminology is conceived by software engineers shortly after the Feasibility phase of a project. This is not because software engineers are especially adept at naming product-specific functions, but rather because software UI needs to be created early on in the development cycle. As a result, software engineers are often the first ones to encounter the need to coin new terms.
So let’s say that, for a new blood analyzing device, an engineer who is working on the textual strings for the device’s graphical user interface coins the term “Analyze” for a functional button in the software. When a user clicks on this button, the engineer reasons, the device will proceed to analyze the blood sample provided. It’s safe to say that most people would agree that the word analyze is a sensible term for referring to this function.
At the same time this engineer (or group of engineers) is coining a new term for the device’s software GUI, the company’s marketing department begins to prepare pre-launch material to help sell their newest blood analyzer. They aren’t sure which term to use to refer to the analysis function of the new device, so they defer to the technical publications team, which has just started working on user documentation between the Design and Development stages of the product’s life cycle.
Now, for leverage purposes, the technical publications department generally bases user documentation on previous releases of similar products. This not only enables their tech writers to save time, but it also saves money on translations of legacy content when the product’s supporting materials are sent out for multilingual localization. Because this Life Sciences organization had previously released a product that, although not a blood analyzer, was similar in functionality to the new device, their technical writers decide to use that product’s user manual as a basis for the new device’s user documentation. Nobody realizes, however, that the older user manual uses the term “Sample” to refer to the device’s analysis function, whereas the software engineering department has already coined a new and different term.
The marketing department, being the marketing department, decides that the term sample is okay in some instances, but that the words analyze and run are more appropriate for different audiences. They begin preparing the new device’s marketing collateral accordingly, and because this Life Sciences manufacturer does not actively manage their terminology, there are now three different departments using three different terms for a single function, and there will be no consistency between product deliverables when their respective deadlines arrive.
In the next section of this article we will delve deeper into the repercussions of poor terminology management in the Life Sciences product development cycle.