Ken Baake English 579

Bibliographic Review

Making Minimal Demands on Your Audience While Giving Maximal Assistance: An Overview of the IPCC 97 Proceedings

The technical writing industry to its credit seems to be obsessed with providing documentation that is useful to an identified audience, but is not overbearing. Issues of how to address an audience dominated the recent IEEE professional communication conference (IPCC 97) in Salt Lake City. Participants wrote about various aspects of technical writing, including topics such as Web page design, usability testing, document design, rhetorical considerations in technical writing and minimalism. All of these topics could be subsumed under a common theme: audience. Technical writing clearly is a service business, where smart people spend a lot of intellectual energy trying to figure out how better to document complex tasks to ensure greater success among users, with less wasted time. Such documentation is essential in the highly complex world of computers, where users often struggle with a myriad of functions required for word processing, data management and Worldwide Web access. But as one conference speaker noted, providing the most useful content without providing too much is a “tightrope act.” In this paper, I describe some of the ways professional technical writers have walked that tightrope and addressed audience needs. Drawing from the published IPCC proceedings and my notes from panel sessions, I will consider specifically issues of audience analysis, usability and documentation – with an emphasis on minimal documentation.

Who is the audience?

It seems obvious that technical writers must know their audience before developing documentation to help people accomplish tasks on a computer or in other technologies. Yet the question of who an audience comprises is not trivial. Technical writers are confounded with difficulties assessing audience needs in part because they are writing to so many different types of users – spanning the range from novice to expert. The goal is to serve each by providing documentation that allows him or her to get the task done with minimal amount of time spent reading the document. Hence, some kind of analysis of audience is necessary before any writer can begin telling those audience members how to do something.

Rob Houser in a panel talk and a paper titled “What is the Value of Audience to Technical Communicators?” defined audience as “the real and imagined readers (users) who use texts (products) to do something in their own environment.” (Houser 155). Houser noted that when we write, we imagine the audience in our heads. But when we evaluate what we have written in usability testing sessions, we are dealing with a real audience. “Finally, when we start a new project, our audience will include all of our previous experiences with audience – both real and imagined” (156).

Houser showed how our view of audience has changed over the past 30 years. In the 1960s, a classical view of audience dominated the field, with the audience perceived as “hearer” or receiver of information. The audience was seen as distinct from the speaker and the subject. But more recent models have cast audience into the role of “doer,” which means that the audience joins with the speaker or writer in forming meaning. Hence, the audience has evolved in the author’s mind from being a passive receiver to being an active participant in the process of determining the effectiveness of technical writing. This changes means that technical writers must work with their audience to determine what understanding will emerge from a set of instrumental instructions.

Because audience now is seen to play such an active role in determining meaning of a technical text, writers of those texts must engage in audience analysis with a view towards gathering information about the needs of readers. According to Houser, “Without exposure to audience, we cannot design effective, user-centered products” (161). Houser proposed creating new data bases about audiences that would include user and task analysis, formal data from market analysis, informal data, reports from usability testing and artifacts from user sites. But Houser concluded his talk and his journal article by noting that the technical writing community still does not know what to do with such information.

Clearly the ability to track and organize statistical data will give us more information about our audiences than we have ever had before. But this opens up serious ethical questions that Houser did not consider. Do we take that information about audience needs and use it to create better instructional documentation? Or do we use it to fine tune our marketing skills that will be directed at specific, perhaps vulnerable, consumers?

Rhetorical considerations of audience

Even if we lack a profile of each reader of our technical documents, we can make generalizations across a broad spectrum of readers. Readers respond to written text in ways that can be predicted, given some knowledge of classical rhetoric. Technical documents are indeed instrumental, meaning they are largely measured by their usability. But they are also highly rhetorical, as shown by Michael Steehouder of the University of Twente, The Netherlands. Steehouder conducted a study of 60 instructional documents in Dutch to reveal the rhetorical subtleties present. These documents gave instructions for various products: televisions, ovens, electric tooth brushes, telephones and similar equipment.

Steehouder showed that technical writers create various personae when crafting documents. The writer may assume the role of the manufacturer explaining the company’s product or assume the role of an unidentified third person who speaks of a company X which “has been known to be a very reliable manufacturer…”(Steehouder 79). The writer also carries the ethos of a teacher, tutor or advisor. This writer envisions her audience either as users, who are not technically minded, or as operators, who are more enamored of the technology. Seeing an audience as users implies a kind of documentation that dispenses with details of how the equipment works and focuses more on applications – which buttons to push. An audience of operators is afforded a more semantic support system, where the writer will explain how various operations relate to others in the overall system.

Awareness of audience is essential to avoid inadvertently insulting a user. Readers of technical manuals are highly dependent and vulnerable and, therefore, susceptible to feelings of being patronized. Steehouder cited a work by Penelope Brown and Stephen Levinson which argues that many communicative acts threaten the face of the audience members. Technical manuals can appear to “talk down” to the audience or imply that readers are stupid. A rhetorically insensitive writer, for example, might include the first instruction below for a dishwasher. A more sensitive writer would mitigate the admonition by adding the words, “by mistake,” as in example two (88):

(1) If you fill the salt reservoir with a cleaning agent, this will cause irreversible damage to the water softener.

(2) If you fill the salt reservoir with a cleaning agent by mistake, this will cause irreversible damage to the water softener.

Writers must also be aware that readers can be confused by lexical markers in a text if those markers are used in a contradictory manner. Marking words such as “caution,” “attention,” “danger” and the like can be used throughout a document, as Alfons Maes of Tilburg University, The Netherlands, showed in a paper analyzing the effect of the Dutch word “attention” on readers of computer documentation. “Attention” in one use points to a specific and serious message, such as in, “Attention, smoking can cause fatal illnesses” (Maes 253). In other cases, however, “attention” serves as a means of guiding the reader merely to consider a section of the document. Mixing strong and weak uses can cause confusion, Maes revealed.

How useful is your document to the audience?

The test of any document is in how useful it is to the audience. Does a manual describing how to develop a spread sheet really help a company administrator keep track of expenses? Does a help wizard instruction in a word processing program quickly assist a student who is trying to set margins? Can the user access this help when needed and not be bothered by it once he or she has mastered the task? Karen Tylak of Lucent Technologies in a paper considers usability to have four general components (Tylak 184):

· Availability – The information must be present when needed.

· Suitability – The information must align with the user’s tasks and interests.

· Accessibility – The user must be able to find the information quickly.

· Readability – The information must be fluent and easy to read.

Laurie Kantner, Stephanie Rosenbaum and Connie Leas recommended in their paper that companies conduct usability tests prior to completing documentation. The three authors used two case studies to reveal that usability testing of a teleconferencing hardware and software system helped technical writers spot usability flaws in the system. “This way, we could apply to the design of the documentation what we learned about our target audience and their experiences using the software” (Kantner et al. 355).

In the studies, test administrators guided participants through a series of tasks on their computers. “By observing the test and analyzing the collected data, the test observer/writer gained valuable information about the users’ responses to the software: their likes and dislikes, problems they had performing tasks, and which new concepts were difficult to grasp” (356). The tests revealed, for example, that users were stumped by a graphic user interface (GUI) for entering scheduling information. To access this interface, users had to click on a box labeled “New Meeting.” So when writers developed the documents, they made clear the need to click on that box. “Had the writer not witnessed people getting stuck at this point, its importance may have been overlooked” (358).

Rosenbaum, Kantner and Leas concluded that writers need to watch people using the product about which they hope to document. Usability research, however, is fairly new. In the past, writers frequently only got as close as the marketing department when trying to find out information about their potential audience. “Combining usability testing and documentation projects is indeed the best of both worlds. For writers to watch people use their products is enormously instructive; writers become much better equipped to prepare useful documents that speak to the intended audience” (362).

Less Is More: The Ultimate in Audience Consideration

Minimalism is a fairly recent innovation in technical writing that is based on the rather self-evident premise that users are busy people who engage in technology to make it perform some desired task. Therefore, documentation should do no more than is necessary to make it possible for users to perform that task. Many of the papers and talks at the IPCC directly mentioned the concept of minimal documentation. Or at least those papers operated from the minimalist assumptions that are now common currency in the technical writing profession. If this conference was representative of the technical writing world, it is probably safe to say that minimalism is the dominant paradigm.

It was not always so. Minimalism as a formal system of technical writing gained currency in this decade, following the 1990 publication of John Carroll’s seminal text, The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill. Carroll spoke at one IPCC session and it is worth considering his thoughts on minimalism seven years after his book was published. But before doing so, it is necessary to look at the principles of minimalism and at the institutional tradition from which it emerged.

Carroll’s book takes its title from what he saw as the predominant paradigm in the early years of computer documentation. The Funnel of Nurnberg was an old metaphor for the way in which people were said to gain knowledge. Knowledge could be poured into their heads through a funnel. In the technical documentation field, the goal of writers was to develop systematic and thorough manuals that would fill the user’s head with every bit of information available about the technology being documented. The assumption was that users would carefully digest these systematic manuals one page after another before attempting to operate the technology.

The systems approach and earlier versions worked well when the use of computer technology was restricted primarily to computer scientists. But computers moved into the hands of novices in the 1980s, creating an audience that cared little for the detailed systematic approach toward documentation. These users wanted to make applications work. Carroll in The Nurnberg Funnel showed how novice users tended to bypass thick systematic manuals and, instead, would place calls to software companies, overwhelming their sparsely staffed help centers (Carroll 5).

Users had all kinds of difficulties with software manuals, as Carroll showed in case studies of participants attempting to learn office computer systems like the IBM Displaywriter or Apple Lisa. In one study, he found that after 12 hours of self-instruction based on printed manuals and help menus built into the software, not a single user could successfully complete the task of creating a letter (22). Users complained that the documentation made them feel stupid. They did not read the manuals in a systematic manual. Users were put off by language that had become common currency in the computer science world – phrases such as “accepting defaults,” which sounded like the user was being asked to renege on a contract. Furthermore, the manuals made no provisions for assisting users when they had made errors. Ironically, the most successful users in one case study that Carroll documented were those who incorrectly inserted the tutorial diskette and were unable to use it (61).

The systems approach failed because technical writers ignored a fundamental paradox about their audiences, a phenomenon Carroll refers to as “the paradox of sense making.” This paradox states that users are “too busy learning to make much use of the instruction” (74). Hence, they need meaningful documentation that will help them immediately produce something useful on the computer. This paradox creates the tightrope challenge for technical writers who must recognize that in order to interact meaningfully with technology, users must acquire basic skills and understanding. But in order to acquire those skills and understanding, they must interact with the technology.

Minimalist documentation attempts to satisfy this paradox by presenting the smallest possible obstacle to a user’s learning effort. The goal is to get users started quickly on doing something useful (185). The theory suggests that:

(1) All learning tasks should be real -- ones that users understand and want to work on.

(2) Users should be allowed to get started quickly and to rely on their own reasoning.

(3) The amount of text in instructions should be reduced.

(4) Instructional material should be organized to permit skipping around.

(5) Instructional material should help users recognize and recover from their errors.

Carroll in Chapters 5 and 6 of The Nurnberg Funnel made a strong case for minimalist documentation by offering the results of various case studies in which some participants used systems manuals and others used some form of minimalist documentation or online support. In these studies, learners using minimalist documentation learned how to accomplish tasks faster and had a greater success rate with those tasks. Minimalist learners also made fewer errors and were able to recover from those errors faster than were systems learners

Challenges for minimalism

Any time a new concept takes over an industry as minimalism has in technical writing, there are bound to be misconceptions. John Carroll was the first speaker at a panel on minimalism at the IPCC conference, and he used his time to consider some misconceptions. These all seem to relate to one large misconception – that minimalism is like some light foods, less filling because it is less nutritious. A lazy writer’s way to minimalist documentation would be to simply cut stuff out of the text, use a lot of bullets and other graphical markers or rearrange the text into smaller chunks of material to create the illusion that it is less dense. Other speakers revealed that some technical writers have tried these tricks, but that such poorly conceived minimalist documentation is a disservice to the audience. Here is Carroll’s list of misconceptions about minimalism:

· Minimalism just means brevity and incomplete instructional analysis.

· It means trial and error learning, with an over-emphasis on error.

· It does not incorporate any learning by reading, merely by problem solving.

· It is just another word for job aids.

· It caters to user preconceptions, in essence, giving the user what she thinks she needs. It has no theoretical foundation, except some vague notion of pragmatism as derived from Dewey or Piaget.

In the same panel discussion, David Farkas from the University of Washington noted that minimalist documents are difficult to write because users come in various stages of proficiency. Like clothing, “one size fits all doesn’t work for everyone,” he said. Writers risk alienating high-end users by creating documents that are not minimalist enough and they risk alienating low-end users who need more instruction. “This is the tightrope that minimalism tends to walk,” he said. A solution is to create multiple levels of documentation – a type of layering – that creates primary channel information for mainstream users and deep-level supplemental information for those who are less proficient.

Minimalism’s value is that it accepts the unpredictability inherent in the way users attempt complex tasks, according to panel comments by Barbara Mirel of DePaul University. It is difficult for a writer to formalize a system by which every user will approach the same complex task, she said. Minimalism allows for this unpredictability by focusing on learning by doing and by creating useful but not comprehensive documentation. “Meaning and knowledge reside in use and experience,” Mirel said. “Words aren’t delivering content, but drawing attention to what will be meaningful to them (users) in daily situations."

But minimalist writers must avoid the temptation to merely chop up long texts into small, discrete tasks. Users cannot just assemble a series of discrete tasks and expect to create a unified whole, according to Mirel. “Learning discrete tasks and putting them together does not work for complex learning,” she said. “It’s more then the sum of the parts. Cognitive disequilibrium is necessary. You have to be thrown into your errors and misconceptions.”

Hans van der Meij of the University of Twente in the minimalist panel discussion noted that a study at his university showed minimalist manuals to be 30 percent less thick than standard systematic manuals, but also 30 percent more effective at fostering retention of knowledge. But one problem he has identified is that users often have trouble switching back and forth from a manual to a computer screen. They tend to look at one or the other, which means that even minimal documentation can be distracting from the task. “The real problem is how to shield us from all the information we don’t need,” Van der Meij said.

During the question and answer session after the minimalism panel, one member of the audience brought up the nagging problem of how to produce meaningful documentation for a specialized audience. This issue of field dependency is an ever-nagging one for those of us in rhetoric and professional communication. The only person who could write a minimalist document for a brain surgeon is a brain surgeon, the audience member said.

Panelists suggested that writers must become very familiar with the subject (domain) area. This is especially true in minimalist documentation because the writer cannot compensate for his lack of expertise by simply throwing into the document everything he can about a subject. He must selectively choose what is important and what is not – an editing skill that requires a good deal of facility with the specialized material. One panelist said some subject areas are so complex that they go beyond the documentation skills of ordinary technical writers.

One of the most interesting speakers on a panel dealing with audience and technical communication was Karen Tylak, a technical writer with Lucent Technologies. She showed a specific example of how minimalism has been incorporated into a large corporation, with some degree of success. Tylak’s paper in the IPCC Proceedings asked, “Minimalism – Can You Have Too Much of a Good Thing?” In the paper and during her talk, she walked through a narrative of how Lucent developed a form of minimalist documentation called “InfoWare.” She described this as a task-based documentation package. InfoWare was designed to help large corporate users such as Southwestern Bell set up electronic switching systems with the Lucent equipment.

Rather than attempt to fit everything on one page the way old systems manuals would do, the InfoWare manuals moved all the background reference materials away from the task-oriented section of the documents. The task books were segmented into a hierarchy of tasks, including general task descriptions (GTs) such as “Setting Up the Machine.” These contained documentation for a variety of sub tasks necessary to accomplish the broad goal. Nested within this documentation were a series of detailed procedures (DPs) that outlined specific steps. InfoWare writers faced self-imposed constraints, such as a rule that allowed no more than three sequential GT steps in order to accomplish a task.

But InfoWare suffered from writers perhaps taking the minimalism concept too far. The GTs and DPs were not in a logical order, making it easy for the user to get lost. Also, the table of contents was missing, depriving readers of a familiar tool. “By creating artificial names and groupings for tasks, InfoWare has forced the user into unfamiliar territory and again taken control away from the user” (Tylak 187).

InfoWare’s biggest flaw, as outlined by Tylak, is a flaw common to many documents developed to allow for non-linear use. The documents give the novice user no sense of which path makes the most sense to follow. From Tylak:

The users can do many things – set up a system, run a report because it’s Tuesday and a full moon, add a data center. But what will the users most likely do? What are the user tasks that are performed by 80 percent of the users? There will be a slight variation, but a thorough task and user analysis will reveal what the user actually does. This is what the materials should focus on – not what the users might or can do (188).

Tylak also revealed in her talk that inertia continues to permeate large organizations, even when they aspire to be au courant by doing such things as minimalist documentation. At Lucent, she recalled, someone in one department could not get information to print properly. That frustrated worker asked for help from the technical support department. The technical support people, however, told the worker something to the effect that, “It doesn’t matter whether you can make it print. Our concern is the user.” Tylak, noting the obvious irony, asked rhetorically: “If the people in house cannot do it, how can the user possibly do it?”

Conclusions – Audience, audience, audience

The most powerful message to emerge from IPCC 97 and from the journal articles written to support the conference can be summarized by borrowing from the old real-estate agents’ joke that the three most important things to consider for a property are “location, location, location.” In the case of technical documentation, substitute the word “audience.” Technical documentation has one purpose – to help people perform a complex task. Hence, there is no room for flowery language or excessive verbiage.

Writers first must determine who is in their audience and what they need. If writers have access to detailed audience analysis research, they will be better able to serve that audience. Knowing their audience, writers then must ask how their documentation will meet the standards of usability – that is, in helping the user to accomplish a task successfully with the least amount of background reading. Technical documentation, unlike traditional forms of writing, is not about words. It is about tasks.

Minimalist documentation is effective in helping users do things successfully. Users benefit from increased retention and a shorter learning curve with minimalist documentation. But such documentation must be done thoughtfully. Otherwise, it merely feigns usefulness through excessive brevity, but leaves the user no better off than he was with the longer systems approach.

Works Cited

Carroll, John, M. et. al. “Minimalism.” Panel discussion, 1997 IEEE International Professional Communication Conference, Salt Lake City, 23 October 1997.

Carroll, John. M. The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill. Cambridge, MA: The MIT Press, 1990.

Houser, Rob, et. al. “Audience and Technical Communication.” Panel discussion, 1997 IEEE International Professional Communication Conference, Salt Lake City, 22 October, 1997.

Houser, Rob. “What is the Value of Audience to Technical Communicators? A Survey of Audience Research. ”Crossroads in Communication: IPCC 97 Proceedings, Salt Lake City, 22-25 October 1997.

Kantner, Laurie, Stephanie Rosenbaum and Connie Leas. “The Best of both Worlds: Combining Usability Testing and Documentation Projects” Crossroads in Communication: IPCC Proceedings, Salt Lake City, 22-25 October 1997.

Maes, Alfons. “Marking Information in Computer Documentation: Why and When? Crossroads in Communication: IPCC Proceedings, Salt Lake City, 22-25 October 1997.

Steehouder, Michael. “Author and Reader in Instructions for Use.” Crossroads in Communication: IPCC Proceedings, Salt Lake City, 22-25 October 1997.

Tylak, Karen. “Minimalism – Can You Have Too Much of a Good Thing?” Crossroads in Communication: IPCC Proceedings, Salt Lake City, 22-25 October 1997.