by Geoff Hart

Myths often represent the very human attempt to explain something important but poorly understood, such as the turning of the seasons, or to provide cautionary tales to warn listeners against unsanctioned behavior, as in the myths of Prometheus and Epimetheus. The fascination inspired by myths has kept many alive across the millennia, but despite the degree of abstraction or exaggeration that makes them so fascinating, there is often a grain of truth or an insight into some fundamental aspect of the human condition at their heart. In our current enlightened age, we fancy that we've grown beyond the need for myths, yet "urban legends" abound (particularly on the Internet), and many of the things we do in our daily work are strongly influenced by "rules of thumb" that are, in a very real sense, a form of myth.

As any other profession, technical communication has accumulated its share of mythical rules of thumb, but the good news about our profession's myths is that they too contain grains of truth and insights into things that are truly important to us. The bad news is that we've also internalized some of these myths to the point that we no longer question them and have begun to let them constrain our choices rather than to help us remember and see the truth. Some communicators even overgeneralize the occasional rule to the point where it loses its validity and become dangerously misleading.

So what myths do we live by? In no particular order, this paper presents my "top 10 list" of what I consider to be the central myths in modern technical communication. There are undoubtedly others. By acting as devil's advocate, intentionally presenting these myths in a bad light, I'm hoping that I can persuade you to question these and other rules of thumb that you use daily. When you pay closer attention to the rules you obey, consciously or otherwise, and question why, you can start to recognize the disabling aspects of a myth and begin taking steps to free yourself from those constraints.

• Myth #1: Knowledge of Specific Tools Is Vitally Important [2]
  
  
• Myth #2: Sans Serif Fonts are Always More Legible Online [2]
  
  
• Myth #3: Audiences are Static [2]
  
  
• Myth #4: Minimalism Means Keeping Text as Short as Possible [2]
  
  
• Myth #5: The Optimum Number of Steps in a Procedure is 7 Plus or Minus 2 [2]
  
  
• Myth #6: You Can Make a Bad Interface Easy to Use Through Superior Documentation [2]
  
  
• Myth #7: We Can't Talk to the SMEs [2]
  
  
• Myth #8: Usability Testing is Prohibitively Expensive and Difficult [2]
  
  
• Myth #9: Single-sourcing Means Dumping Printed Documents Online [2]
  
  
• Myth #10: Documentation is a Cost Center [2]
  

Karen Schriver (1997) [2] has provided a detailed summary of the literature on typographic issues that should be mandatory reading for documentation designers concerned with issues of typography.

Even if sans serif fonts were the hands-down winners, enforcing their use ignores perhaps the greatest blessing of publishing information online, something that has thus far been impossible to achieve in print: readers get to choose the fonts and font sizes that they prefer rather than having to cope with our choices. This is particularly important for visually impaired readers, who will likely become an increasingly significant part of our audience as the average age of our readers increases. My advice, subject again to the caveat that I'm overstating my case to make a point, is that we should never deprive readers of this flexibility unless we've carefully weighed the advantages of what we're giving them in return. In my experience, there's little advantage to enforcing a typeface choice. Using specific typefaces is most important when the graphic design approaches the content in importance, but that's rarely the case for most of the work we do.

One important caution about leaving typeface choice to the reader: make sure you document how readers can make the necessary changes, since many neither know that they have a choice nor understand how to make the change once they do know. But will that change over time? I've observed that our audience is aging, and that's just the tip of the iceberg.

(Carroll and van der Meij 1996) [2]. Since I lack the space here for a full review of minimalism, I'll risk oversimplification myself by treating the subject in much less depth than it deserves.

To quote Carroll and van der Meij: "The central principle in minimalism is task orientation. But many other principles play a role in this design approach either because they support task orientation or because they follow from it." In short, the minimalist philosophy involves understanding what your audience is trying to accomplish (audience and task analysis) and focusing on those needs by providing enough information, in the right form and at the right time or in the right place, to help them accomplish their tasks.

The myth that minimalism equals brevity stems from a much more interesting and complex assertion: that you shouldn't bury readers in extraneous detail. The challenge, of course, lies in discovering what is truly extraneous. It's also a myth that minimalism is a one-size-fits-all solution for all communication problems because its task orientation does not make it directly applicable to problems such as communicating theoretical information (for example, the "why" of graphic design rather than the "how") or writing to persuade the reader (for example, marketing). Yet even for such seemingly unrelated problems, minimalism has much to say because of its emphasis on the reader, and that emphasis won't lead us far astray even when the reader's tasks are not immediately recognizable as tasks. The fact that a philosophy designed for one specific field (task-oriented documentation) can be so easily misinterpreted—yet still have broader implications for communication—leads neatly into another myth:

Miller's best-known publication (1956) [2] is also probably his least-read, and this failure to consult the source has led to one of the more pernicious misunderstandings in the field of technical communication. In effect, several generations of writers have made the assumption that (for example) lists and procedures should contain no more than five to nine steps, based solely so far as I can tell on the title of Miller's article and the myths that have grown up around it. As it happens, the article actually discusses the human ability to reliably distinguish categories (for example, distinct shades of gray, sound levels) and the related issue of "channel capacity," which represents (simplistically) how much information your audience can manage at a single time. In effect, this represents the number of cognitive tools typical readers can hold in their mind's hand (so to speak) and use to attack a problem.

I won't try to summarize 16 pages of rich, moderately dense prose by Miller in any depth, both because I want to encourage you to read the original article yourself and because an update on this subject merits its own article. Given the importance of what Miller discusses, we should begin thinking about how to test the applicability of this body of research in our own unique context so we can begin applying the new findings to our work. While we wait for those results to trickle in, two things we already know give us much to ponder:

1. We should always go to the source rather than blindly accepting someone else's report of what that source said. This takes longer and usually requires considerably more thought on our part, but it greatly reduces the number of myths and misconceptions that we'll perpetrate and perpetuate. More interestingly, revisiting an article often leads to inspiration and the discovery of new ways to build on those old thoughts.
2. Miller's study does have intriguing implications for technical communication, even if they're not the ones we've assumed for almost 50 years. For example, our audiences have very real limits on how much information they can process simultaneously, and recognizing the existence of these limits means that we need to better understand how we can help readers to process information. All else being equal, readers will always find it easier to deal with fewer items at a time than many items. As a starting point for applying Miller's findings, we need to learn to write in such a way as to let readers digest one chunk of information before we force them to begin dealing with the next one. That may mean we'll have to reconsider an interface design because we're asking users to deal with too many inputs at once, leading us neatly to the next two myths:

Carliner 1998 [2]). But corporate culture is often such that making our voices heard is difficult, and there are many barriers raised in our paths. Why don't we circumvent these barriers? Because of yet another myth:

(Nielsen 2000) [2]. The fact that so many of us have been scared away from even considering usability testing is unfortunate.

In fact, just about any thoughtfully designed usability test is better than no usability testing whatsoever. As Nielsen trenchantly observed, "The most striking truth ... is that zero users give zero insights." In the worst-case scenario (if, for example, you have virtually no resources and you're the only person available to do the work), you can find at least one person to test a product or a publication as stand-in for your users. Even though one or two users don't truly represent your audience, many things that these few users find problematic will pose exactly the same problem for the larger audience. If the current interface takes 12 clicks to accomplish a task and you can describe a way to do the task in 3 clicks, with equal or greater clarity, then you've discovered a more usable alternative. If the software uses six different words to describe the same concept, and only one of the words exists in a standard office dictionary, then that one common word is often the best word for your audience.

A few simple guidelines can let you gather important, helpful, reasonably reliable data from even a small subset of your audience:

• Test your questions and the tests themselves with a colleague, then determine whether you can analyze the user's answers efficiently and extract useful information. The answers must be easy to understand and summarize, and must let you identify and determine how to resolve the problems.
• Examine your questions or test designs for signs of bias (Hughes 1999 [2]). Biased questions or designs collect biased answers and can mislead you in your subsequent efforts to improve usability. For example, asking "just how bad is this interface?" gets a very different answer from "how highly do you rate this interface?" because of the way that the questions focus the respondent's attention. Similarly, testing only a group of experienced users will provide data that doesn't adequately represent the needs of neophytes.
• Collect data separately for each distinct group in the audience (for example, new and experienced users). Programmers who will install and maintain software have distinctly different needs from the people who'll use the installed software, and if you combine the data for these two groups, you may fail to see results that reflect their different needs.
• Collect data from several people within each distinct group to reduce the chance of focusing on the one person who is completely different from everyone else in that group. The mathematics of statistics suggests that larger samples are more representative of the overall population, but as Nielsen (2000) [2] suggests, "larger" need not inevitably mean "prohibitively large."
• Avoid conditions in the test or the test environment that could influence the results (for example, the test documentation is written in English but is given to someone with a different birth language, the phone in the participant's office is constantly ringing, the computer is too slow to run the software efficiently). Each factor you control introduces some measure of bias because you'd get different results for situations in which that factor differs. When you try to control a test factor, don't blind yourself to its implications; for example, "localized" documentation may be required for different linguistic audiences, voice-assisted navigation or spoken online help may prove useless in a noisy environment, and the computer configuration the developers recommended may be unrealistic.
• Confirm that you've understood the answers or results by asking for clarification from the test participant (for example, "why did you say this product is so bad?").
• Never focus so narrowly on your own objectives or preconceptions that you blind yourself to unforeseen revelations from the test participants.

This brief summary is intended solely to get you thinking about testing. For additional information, I recommend reading more about designing test questions (for example, Rojek and Kanerva 1994 [2]), organizing and managing the test (for example, Kantner 1994 [2]), and evaluating the results (for example, Hubbard 1989 [2]). Craig (1991) [2] provides an annotated bibliography that can help you expand your research.

Zubak 2000 [2]). Complicating matters—as any working professional knows—is the fact that resources are always limiting in the real world, and you may not have sufficient resources to develop information tailored specifically for use in different printed and online information.

The conflict between the ideal of providing information customized for use in a single medium or context and the very real inability to create such information as often as we'd like has generated a tremendous need for single-sourcing: creating one set of information that can be reused for both online and printed documentation. There are lots of compelling reasons to adopt this compromise because, even when resources aren't limited, it makes little sense to duplicate effort by writing the same text twice. Apart from the inefficiency of creating information twice, the risk of introducing discrepancies between the online and print versions of documentation by creating them independently is hard to accept.

Unfortunately, many companies have been misled into simply producing a single set of documentation and dumping it online. (This approach is encouraged by an attitude that documentation is a cost center, not a benefit to the company and the users of its products. I'll discuss that myth next.) Much of the potential of technologies such as Adobe Acrobat has been wasted by communicators who can't or won't even take the time to reformat a vertically oriented document designed for paper to fit on a horizontally oriented computer screen. At its most innocent, this practice simply shifts the cost of printed documentation to the users of the documents, who give up trying to read the information online and resentfully print their own copies. At its worst, this form of documentation can be a serious productivity drain. Endlessly scrolling from the top of a page to the bottom or squinting to view a full page displayed in a miniscule font is inefficient and outright annoying to many readers. Indeed, the very word "scrolling" speaks eloquently about how badly this design serves our audience, for if scrolls were such a good communication medium, why did we abandon them in favor of bound books?

Even when designers have the time to reformat printed documentation for proper display onscreen, this approach generally fails to take advantage of the respective strengths of each medium. STC members have been writing about this compellingly subject for more than a decade (see Brockmann 1990 [2] and Horton 1994 [2]), yet I continue to see online documentation that is unusable or difficult to use online simply because of how it's presented.

There are valid approaches to producing single-source documentation, of which SGML is perhaps the best known. But these approaches require a fundamental shift in the way we look at producing information, both in the initial stages (information creation) and in the final stages (information presentation or delivery). The failure to understand the distinction between these two phases and the often-forgotten third phase, information use by our audience, is one of the main factors behind the current sad state of much online documentation. Yes, you can go a long way toward single-sourcing with appropriate planning and tools; no, you cannot generally pour information from one medium into another without some reworking of the information's content or structure.

Mead 1998 [2]). The kinds of value we add include, but are not limited to:

• Reducing internal corporate communication costs through improved communication
• Improving the organization's return on investment
• Reducing technical support and other "post-sale" costs
• Reducing development costs by freeing developers from the painful task of writing
• Producing saleable materials (for example, Adobe's "classroom in a book" series)
• Reducing the frequency of lawsuits, product recalls, and product returns

It pays to think creatively when you're trying to demonstrate your value. For example, documentation can conceivably generate a sizeable return on investment even in situations where that doesn't seem likely. If documentation is sold as an optional extra for the product, the profits generated by selling it are obvious, but even when the documentation is part of the sale price, there can be tangible profits.

Consider, for example, a company with tight accounting controls that sets a target for an overall 20% return on their gross investment. This means that for each $1 the company spends to produce a product (software), including all expenses incurred by the company, they would earn $0.20 in net revenue. In such situations, it's easy to overlook the fact that documentation generates part of that $0.20 profit. Each $1 the company spends on our salaries and benefits, and on printing manuals, also generates $0.20 in profit for the company!

This logic depends on many assumptions, including the assumption that profits are calculated based on total expenses rather than purely on development costs, as might be the case in a startup company. It also assumes that the company is well enough run to generate a profit, let alone a profit as healthy as 20%. But the logic applies to any profitable company, and it should be possible to obtain the data you need to determine whether it applies to your own company and generate some real numbers that demonstrate your net worth to your employer. If not, have a look at Redish and Ramey (1995) and Mead (1998) [2] to see what other methods you could use to demonstrate your value.

I find this myth particularly interesting because it's both something that others believe about us and something that we believe about ourselves. We each intuitively understand the value we add, even if we're not able to easily articulate that value, but because we haven't taken the time to demonstrate that value to others, we begin to doubt our own worth. It's past time we began changing management perceptions so that they understand our true value, whether we measure that value in tangible or intangible ways. Do some of the work necessary to define this value, and management will begin taking you more seriously. That's a good first step toward feeling more secure about yourself, your value to your employer, and your job security.

Myths Aren't Always Invalid

Myths endure because no matter how much they simplify or exaggerate reality, they are nonetheless based on something truthful, something important to us, or something that sheds a bright light on an aspect of our lives. Two of the things that fascinate me most about mythology are just how universal the themes can be and how creatively each person or culture can be in reinventing a myth by recasting it in their own unique context. Folklorist Josepha Sherman has observed that "Myths are attempts to explain the cosmic truths ... . All peoples have the same questions, and so all peoples have the same basic type of myths."

Each of the ten myths I've presented in this guest editorial passes this test for that idiosyncratic group of people known as technical communicators. My hope is that each of us will find ways to answer those universal questions for ourselves by seeking out the underlying truths and building on them to create something more useful and fascinating still. By making the myths more relevant to ourselves, we reinvigorate them and ourselves. One obvious way to do this is to re-examine our current rules of thumb and see how they can be refined. After all, the thing to remember about "rules of thumb" is that thumbs bend when necessary.

References

Brockmann, R. J. 1990. Writing better computer
documentation: From paper to hypertext. New York, NY: John Wiley & Sons.
Carliner, S. 1998. "Future travels of the infowrangler." Intercom (September/October):20-24.
Carroll, J. M., and H. van der Meij. 1996. "Ten misconceptions about minimalism." IEEE transactions on professional communication 39, no. 2:72-86.
Craig, J. S. 1991. "Approaches to usability testing and design strategies: An annotated bibliography." Technical communication 38, no. 2:190-194.
Horton, W. 1994. Designing and writing online documentation. Hypermedia for self-supporting products. New York, NY: John Wiley & Sons.
Hubbard, S. E. 1989. "A practical approach to evaluating test results." IEEE transactions on professional communication 32, no. 4:283-288.
Hughes, M. 1999. "Rigor in usability testing." Technical communication 4:488-494.
Kantner, L. 1994. "Techniques for managing a usability test." IEEE transactions on professional communication 37, no. 3:143-148.
Mead, J. 1998. "Measuring the value added by technical communication: A review of research and practice." Technical communication 45, no. 3:353-379.
Miller, G. A. 1956. "The magical number seven, plus or minus two: Some limits on our capacity for processing information." Psychological review 63, no. 2:81-97.
Nielsen, J. 2000. "Why you only need to test with 5 users." Alertbox (March).
www.useit.com/alertbox/20000319.html
Rojek, J., and A. Kanerva. 1994. "A data-collection strategy for usability tests." IEEE transactions on professional communication 37, no. 3:149-156.
Schriver, K. A. 1997. Dynamics in document design. New York, NY: Wiley Computer Publishing.
Zubak, C. Lockett. 2000. "What is embedded help?." Intercom (March):18-21.