Editorial: Tooltips for the Next Millennium

by George F. Hayhoe

Before founding George Hayhoe Associates in 1995, George Hayhoe led a software documentation team at Westinghouse Savannah River Company for 12 years and was assistant director of the writing program and writing lab director at Virginia Tech for seven years. He earned a Ph.D. from the University of South Carolina.

A fellow of the Society for Technical Communication and editor of its journal, Technical Communication, he served on the society's board of directors from 1992 to 1996. He is also a senior member of the Institute of Electrical and Electronics Engineers and has served on the IEEE Professional Communication Society's administrative committee since 1994.

This article originally appeared in the May 1998 issue of Technical Communication.

What are the essential tools that all technical communicators must know? Despite the fact that almost every job ad in our field calls for extensive knowledge of FrameMaker, RoboHELP, or Word, I think the answer is the same as it was in the days before computers became a part of our common work experience. Simply put, any reasonably intelligent person can learn to use this software more or less proficiently within a few weeks. Mastery of such tools has no relation whatever to skill in communicating technical information with words, graphics, and other media.

The software technical communicators need to use well is between their ears.

Now let me make it clear: I am no Luddite. Those who know me are familiar with my fascination with software and computer technology generally. I’ve made my living for most of the past two decades documenting scientific and business applications. I pride myself on having the latest versions of software that makes me more productive and gives the documents I prepare a more sophisticated and professional appearance. But these characteristics don’t really go to the heart of what I do.

Why is it, then, that we—and our employers and clients—cling to the notion that our qualifications and knowledge as technical communicators depend on our ability to operate one or more of these software packages? The answer is simple, I think. It’s easier to measure proficiency with software than it is to measure the ability to write, edit, design, illustrate, or use multimedia.

Managers seeking to hire or contract work from a technical communicator often find themselves in an awkward position. They may lack the expertise to evaluate a communicator’s work, or they may not be able to list the qualifications for the job. Frequently they’re in a hurry and want to find someone who can hit the ground running and become immediately productive. In either case, specifying "3 years’ experience developing online information with RoboHELP" or "2 years’ experience designing document templates with FrameMaker" seems to them a good substitute for the more subtle qualifications for the job.

What really sets us apart from word processing operators and desktop publishers? Clearly, it is not our ability to operate software but rather our knowledge of how to communicate effectively.

What skills comprise effective technical communication? Here’s my short list. It may not be exhaustive, but I think it covers the essentials.

Know Why and with Whom We’re Communicating

We’ve known since ancient times that analysis of purpose and audience is the foundation of all effective communication. We must begin by analyzing audiences and the tasks they need to perform, and understand the purpose of each document we produce if we want to communicate successfully. Indeed, studying unsuccessful information products typically reveals that they were created without planning that considered their reason for being, the people who will use them, or both.

In technical communication it is especially important to determine the goals and objectives of the documents we create, to know as much as we can about our audiences, and to analyze in detail the tasks that our audiences will need to perform with the products our documents support. But all too often, we assume that "this audience is just like the audiences of the last dozen help files I’ve created" when, if we were honest, we’d admit that we didn’t take the time to analyze the audiences of any of those last dozen projects either. Additionally, we’ve too often assumed that user tasks are identical to project functionality, and that one document can provide procedural, conceptual, reference, and instructional information, without considering the implications or validity of our assumption that one size fits all.

Let’s be honest with ourselves. How many of us have ever visited users to observe them using products and documents we’ve produced to support those products? How many of our organizations have ever conducted product and document usability tests? Instead, how many of us have protested that we don’t have the time or that the engineers would never stand for such testing, when the truth is that we’ve never asked them to because we’re comfortable doing business as usual?

If we’re going to take ourselves and our work seriously—and if we expect that others will do the same—we can’t afford that kind of complacency. Is it any wonder that our employers and clients sometimes think that anyone can do what we do when we do it with so little thought?

The first step in outfitting our toolbox for the next millennium, then, is to recognize that the Greek rhetoricians knew what they were writing about more than 2,000 years ago. We must learn how to perform audience, task, and user environment analysis; we must know how to determine a document’s purpose; and we must know how to apply what we learn from these exercises to the task at hand. And we must make these steps a routine and essential part of our information development process, disciplining ourselves to do this up-front planning on every project. It’s not necessarily glamorous or fun, but it’s always worthwhile and often produces surprising results.

Work Smart, not Overtime

To work smart as technical communicators, we need to know how to manage our projects and work effectively as members of a team. The tools required to do these things aren’t specific to technical communication, though effective communication is key to success in both.

Whether we manage documentation departments, lead documentation projects, or serve as members of project teams, we all need to learn more about project management. If we rely on luck or intuition to complete projects on time and under budget, we can’t reliably predict our successes or correct problems before they become disasters. Good luck will inevitably change, and sound intuition will fail us as soon as we’re faced with an unfamiliar challenge. We need a project management toolset that will help us save ourselves from embarrassment and our employers or clients from cost overruns, delayed product launches, and defaults on contractual obligations.

To be successful managers of departments, projects, or our individual assignments, we need to know how to estimate tasks, measure progress, and identify dependencies that can prevent us from delivering what we committed to deliver on schedule and without spending more than we have agreed to spend. In very practical terms, that means the difference between chronic overtime and the leisure to have a life outside the workplace and enjoy it.

Very often, effective project management also requires us to show others how their failure to manage effectively affects us and our part of the project. Much of what we perceive to be lack of planning on their part results from their failure to communicate effectively with us and our failure to communicate our needs and expectations of them. And this is true not only of our colleagues in technical communication but of those who engineer and build the products we document.

It isn’t enough to say we need to be involved in the earliest stages of a new product’s life cycle. We should insist on it, get in the engineers’ faces if need be, and show them the value we can bring to the initial phases of product development. We can help them develop the project plan (including project communication components), play user advocate, point to the need for usability testing of prototypes, and demonstrate the clear superiority of the information we can generate as a result of our increased familiarity with the products that our information supports.

We must also recognize that most products—including information products—are the efforts of collaborative teams, not individuals. We need to learn as much as we can about our own personality styles and the personality styles of others, and also learn techniques for bridging the differences so that we can be effective team members and team leaders. These aren’t touchy-feely games; they’re essential workplace strategies that ensure fruitful collaboration.

The second step in outfitting our toolbox for the next millennium, then, is to learn the skills of effective managers, even if we have no aspirations to management. Only by learning to manage our projects can we guarantee that they won’t manage us. And by learning to blend our talents with those of other team members, we prove the fundamental truth of the calculus of collaboration: one plus one equals more than two.

Master Our Media

Finally, we must be masters of the words, pictures, and other media we employ in the information products we create for our users. In other words, we must be competent craftspeople.

Anyone who has judged in STC’s chapter-level and international competitions has seen entries that are seriously flawed by carelessness or—worse yet—ignorance of the basic principles of grammar and mechanics, of information design, and of the effective use graphics and other media. Too many of us assume that because we have ready access to tools that allow us to combine words, pictures, video, and sound, the tools themselves will ensure that we use those media with precision and skill, or that we have the knowledge to use them effectively.

We’ve all chuckled at the reports produced by engineer colleagues that seemed to be products of the Ransom Note School of document design. We’ve been startled by their mangled syntax and inappropriate word choices. We’ve railed against the apparent allergic resistance of their authors to spellchecking and proofreading. But if we’re honest, we know that all too often we edit our own writing and do it poorly. Or we fail to consult with graphic designers when a document requires their expertise. Or we wait too late to obtain professional illustrations or multimedia components for our projects and rely on our own amateur efforts.

The bottom line is that we can’t afford to act like amateurs if we want to be treated as professionals. And we don’t act very professionally if our work exhibits the very shortcomings we criticize in the work of others who at least avoid the pretense of professionalism in their use of words, pictures, and other media.

The final step in outfitting our toolbox for the next millennium, then, is to honestly assess our mastery of the various media we use in information products. Some may need to brush up on the basics; others would benefit from more advanced study of one or more of those media. Virtually all of us would be well-served if we had access to expert editors not just of our words but of our design, illustration, and use of media other than words and pictures. Such roles would not only improve the documents we produce, but they would give the most experienced members of our design, illustration, and media teams a career path choice that might not have existed previously.

Embrace the Future

As we approach the year 2000, it’s appropriate that we stop and think about just how competent we are at doing our jobs. If I’ve seemed overly critical of our profession here, I don’t want to leave the impression that I find no good in what we do or in the direction we’re headed. I’m convinced we’re on the right road to a rewarding destination, and that much of what we’re doing along the way is worthy of all the pride we can muster. But I want to offer the caution that we can’t be complacent or make false assumptions about our achievements.

One thousand years ago, the approach of the millenium led to panic across Europe. Did it mean the end of the world? Did preoccupation with everyday life distract people from what was truly important? Artists and preachers warned their medieval audiences of the consequences of failing to consider what was essential about who they were and what they did.

We technical communicators face significant questions about our future roles as the year 2000 approaches, but I don’t think we should panic. We must always keep our eyes and our minds on the task at hand—communicating effectively with audiences who need to use technology to be more effective and productive. But as we operate in the pragmatic world of deadlines and product specs, we must never lose sight of what is essential in our field.

By continually honing our skills in using the essential tools of communication, we will become increasingly expert at informing the world because we have not forgotten what is most important about who we are and what we do.

-- GFH
copyright 1998 George Hayhoe