Readability/Usability/Quality 2-01 (July 2001) by Barbara Giammona by Bogo Vatovec

(With thanks to Alesha Erbter for her reporting of the debate for the Forum 2000 Post Harvest)

At Forum 2000 last June, two seasoned technical writers debated the question of Quality in Technical Communication.

The following statement was the basis for the debate:

Technical communicators have always been proud of the quality of their work. Can it be that we are overdoing it? Do we need to change our understanding of what we do? Is readiness to compromise and economize to keep pace more important today than perfecting our work?

Barbara Giammona, who took the position in favor of preserving quality as we know it, has been a technical writer since 1982 and is currently the Manager of Information Technology Documentation for Morgan Stanley in New York City. She has a B.A. Degree in English and American Literature from the University of California, Irvine.

Bogo Vatovec, who took the position that it is time to re-examine our definition of quality, is a Senior Human Factors Consultant with Icon Medialab in Germany. He specializes in international software development, localization, performance improvement systems, and Internet-based solutions. Currently he is pursuing a Master’s degree in Management and Organizational Behavior.

The following is a summary of the 90-minute debate:

 

Position Statement Pro

Barbara Giammona began the debate with a discussion of the importance of quality:

"It is still important to make the effort to preserve the level of quality in our work. We need to always ask ourselves if there is a point at which compromising the writing process also comprises the quality of the product, the completeness of the message, and the safety and satisfaction of the customer. I believe that there is still a value in upholding the quality of our work, even with the shortcuts available to us today, and with the time pressures of the marketplace. While we may change how we do our job, the end result should still be to strive for complete and correct communication."

Here are some reasons why quality is important:

• For the Customer/User of the product. A professional appearance makes a difference in product sales. Impressive documentation helps create customer trust and repeat business.
• For the employer. When high quality is expected and delivered, there is less liability and risk to the employer. "Done once, done right" saves money in production and personnel costs. Finally, "done right" preserves intellectual capital, so that the information provided by SMEs (subject matter experts) is not lost, misconstrued, or misunderstood.
• Because there are consequences for NOT upholding quality. Poor quality documentation can have many results ranging from user confusion and frustration to danger or even death. It can also affect the bottom line. Customers/users will not continue to work with companies that don't produce consistent quality products. If documentation is not written to a high level of quality, then translations will be more costly or inaccurate. When documentation is captured in only a "good enough," informal fashion, the document often becomes incomprehensible after the original authors or experts leave the company.
• Pursuing quality makes standardization possible. Taking the time to instill quality allows for the time to establish and enforce standards. Adhering to standards helps avoid distracting small errors, fosters professional pride in the work, avoids work process slow-down, reinforces product branding, facilitates revisions and enhancements, and makes information easy to use and find.
• Good quality documentation can be understood by everyone and stands the test of time. Most well-respected works from the past are still understood today because they are well written. Good quality ensures that communication will always take place and that the information gathered will have lasting value.

 

Position Statement Con

On behalf of re-evaluating the concept of quality, Bogo Vatovec explained his position:

"Technical writing is a meticulous process: gathering information, structuring information, writing, rewriting, reviewing, editing, final checking, production. I've seen technical writers spending hours polishing one sentence, only to redo it all over again the next day. And improvement from a first draft to the final version is clear to all of us. But is it clearly visible to our customers and our managers? What is clear to our manager is the time spent working on these improvements. Is the time worth it? Have you ever thought that your users and managers simply cannot appreciate your quest for excellence?"

Even though Bogo was speaking with a heavy accent, his message was still clearly understood--and this was one premise of his position. Although technical writers may spend a lot of time writing and rewriting to represent their perception of "perfect" or "quality" work, managers and ultimately end users, may not notice or appreciate the difference. This incongruity stems largely from the use of the term "quality" and how writers, managers, and end users of a document define it.

In re-evaluating the concept of quality, here are some important points:

• Technical writers should not confuse process with quality. Is it worth spending so much time rewriting documentation when the message is already correct? Instead of spending time focusing on individual pieces, focus on getting the information good enough within time limits.
• Who defines quality? Customer, manager or technical writer? It is easy to confuse our definition of quality with that of the customers or the managers. While we may be focused on perfection, they are more interested in time-to-market. From their perspective, the first product to market will be first to receive sales, as long as the product represents "reasonable" quality and fulfills the end user's expectations.
• Who do you really write for? Most writers would say that they write for the end user, but in fact, in typical product documentation, writers must first please the project manager and the product client. Writers can waste a lot of time trying to please all the audiences with absolute perfection.
• We all invest ourselves in what we work on, but that shouldn't overshadow the existence of deadlines. Especially in the case of the web-it is better to be there than to be late. Only 5-10% of the people use the online help, the information on a web site, etc. It is important that technical writers focus on delivering "good-enough" quality for that 5-10%, rather than wasting time on perfecting materials to their own standards of quality.

 

Rebuttals

The following are the comments made in response to the opening statements. Responses from Barbara Giammona:

• Errors undermine the importance of the message. Think of product instructions. How many times have we failed to use a product because the instructions were not clear? Good quality, which communicates correct, accurate information understood by the intended audience, helps assure that products are consumable.
• Sometimes we need to educate the "middle user," such as the project manager, to the value of quality work. Technical writers are not merely transcribers. We provide value-added services that help to elevate sales and reduce costs.
• Only 5% of product users may use the documentation, but what about internal usage? Since the remaining 95% of users may never read or consult the documentation, customer support personnel often rely heavily on the technical writers' work.
• Shouldn't writers take the time to edit or risk perpetuating bad information?

• "Good enough" means that the materials give enough information to meet expectations.
• "Good enough" is also cheaper to produce, as long as customers are still satisfied. In one study, consumers chose the less perfect manual when presented with different levels of "quality" documents.
• Customer support personnel should know more than the end user. If the same documents are being used for both audiences, then isn't too much information being included in the product user documents?
• Technical writers’ definitions of quality are set too high and vary from person-to-person and organization-to-organization. How can we expect to please everyone?

 

Conclusions

The ultimate answer to the question of quality in technical communication today probably lies somewhere in between the two positions in this debate. Aiming for extreme perfectionism may be as costly to a company as publishing sloppy, incomplete information. The value is difficult to measure. Sadly for the product consumers, pleasing the manager or internal client may be more important today than satisfying the actual user.

Quality is always worth striving for; however, today quality may no longer always be defined by the rigid standards of the typical technical writer. Our goal as technical communicators is to communicate information in the best way that time, budget, and our skills allow. As long as that goal is accomplished without causing difficulties for our employer or confusing or endangering the consumers of our work, then we can probably be said to be successful, even if we aren’t perfect!  

"transline Deutschland - Übersetzungsdienst für technische Übersetzung"