February 2011

Technical Communication and Usability: Intertwined strands and mutual influences commentary

CIDMIconNewsletter Janice (Ginny) Redish, Redish & Associates, Inc.

Abstract—Technical communication and usability (user experience, or UX) have a long, intertwined history, dating back at least to the 1970s. The author, who has been active in both fields for the last three decades, gives many examples of how technical communicators have influenced UX practice and how usability specialists have influenced technical communication. The author also explores how technical communicators can continue to contribute to future UX theory, research, and practice through collaboration, through their communication skills, dealing with the reality of ever-increasing complexity in products and processes and dealing with the need to adapt to more rapid change.

The call for papers that started this special section asked the question:

How can technical communicators contribute to

[a new approach to usability], to the evaluation of more complex systems, to the more open exchange of data and methods, to the redefinition of the usability profession?

As a person who has been active in technical communication and usability for many years, I accept the challenge to consider this multipart question.

One of the motivations for the call for papers and this special section was Arnie Lund’s essay in the Journal of Usability Studies, in which he urged usability professionals to “find a new synthesis and take the user experience to a new and better place” [1, p. 2].

In that essay, Lund looks backward and forward. In the following issue of the Journal of Usability Studies, Joe Dumas responded to Lund with an essay that takes an even deeper look at the history of usability as a profession [2].

Both of these essays are extremely valuable as history and as a basis for moving forward, but every history is told through the choices made by and perspectives of the historian. As Dumas says, the story he tells is “through my personal filter” [2, p. 54].

User experience (UX) and usability professionals have many filters for the history of the field because we come from many different origins. Figure 1, created by Whitney Quesenbery for the Usability Professionals’ Association (UPA), shows some of these different origins [3].

It is interesting to see how our different perspectives shape our narratives.

  • Lund and Dumas tell the history of usability as a human factors engineering discipline that moved from the experimental research model of academic psychology to the mostly qualitative practice-based toolbox of techniques it is today [1], [2].
  • Mayhew tells the history of usability as a journey through software development [4].
  • Much current narrative about UX and usability in the web world comes from information architects and interaction designers who were not part of the early days of the human factors story, the software development story, or the technical communication story.

There is a technical communication story: Usability, user-centered design, and UX design also came from technical communication. Part of my goal in this commentary is to remind people of that history. Before we consider how technical communicators can contribute to the future of usability, we need to understand how the fields of technical communication and usability have influenced each other in the past.

Like other historical narratives, mine is idiosyncratic. I cannot claim that this is the definitive history of how technical communication and usability have interacted. I can, however, hope that you find my reflections from three decades of active involvement in both fields to be informative and interesting.

I have organized this commentary into two major parts: (1) looking back for context and (2) looking ahead to further contributions. In looking back, I remind us of the many ways that technical communicators have helped to shape the usability profession and the many ways in which other usability professionals have helped to shape technical communication. In looking ahead to how technical communicators can continue to contribute, I have divided my comments into four discussions, taking on the topics of the original question as collaboration, communication, complexity, and change.

Looking Back for Context

Dumas puts the “birth of the usability profession” in the late 1980s when John Whiteside and colleagues at Digital Equipment Corporation and John Bennett and colleagues at IBM published papers using the words “usability engineering” [5, p. 55]. But usability goes back much further than that. We may not have been a “profession” until then, or perhaps until UPA was started in 1992, but Dumas, Lund, I, and many others—including other technical communicators—were doing usability professionally much earlier than the late 1980s.

The 1970s and Even Earlier
Quite naturally, the early focus of most technical communicators’ work in usability was the usability of all types of documents. Even before computer manuals had audiences other than system administrators, before online help systems, and before clear communication was built into software interfaces, technical communicators were concerned with the usability of documents: brochures, fact sheets, leases, regulations, utility notices, and more.

My personal journey into usability began when the US government decided to fund a project about the problems people have understanding typical government documents. When colleagues and I at the American Institutes for Research (AIR) bid on what, in 1978, became the Document Design Project and then in 1979 became the Document Design Center, our proposal included our “process model” of how one would create a successful communication [6]–[8]. The model—a flowchart of the steps in the process—included predesign user research, developing drafts based on that research, and evaluation as part of development. We built our model on earlier work of AIR colleagues in instructional technology—an example of cross-fertilization between disciplines and also of what Stu Card calls “steal and modify”—one of the “most popular methods for artifact creation” [9, p. 153].

One of the requirements for the proposal was to show a before-and-after for a standard apartment lease. Following our model, we usability tested our draft revision with local inner-city apartment dwellers. It was eye-opening, as I’m sure you will remember from your first experience watching and listening to users. My colleagues and I quickly learned the most critical lessons of usability: We are not our users, and users will always surprise you.

Our process model with up-front user analysis, task analysis, context analysis, user-task matrices, and evaluation as a critical part of development was the framework for all of our projects in the Document Design Center, combining technical communication and usability. (The Document Design Center lasted from the late 1970s well into the 1990s.) We were not alone in combining technical communication and usability. Other technical communication groups were similarly performing user-centered design and usability at least 30 years ago:

  • Stephanie Rosenbaum, who has been active not only in the IEEE Professional Communication Society, but also in UPA, the Society for Technical Communication (STC), ACM Special Interest Group on Computer-Human Interaction (SIGCHI), and ACM Special Interest Group on Design of Communication (SIGDOC), started her company, Tec-Ed, in 1967.Rosenbaum has also shared her view of the history of usability in a recent book chapter [10].
  • JoAnn Hackos, former President of STC and my coauthor for the book, User and Task Analysis for Interface Design [11], started Comtech Services in 1980. Academic programs at schools such as Rensselaer Polytechnic Institute (RPI), University of Michigan, University of Washington, and others have taught user-focused technical communication for decades.
  • The federally funded Document Design Project (1978–1981) spawned not only AIR’s Document Design Center, but also graduate programs in Rhetoric and Document Design at Carnegie Mellon University (CMU) and CMU’s Communications Design Center. Karen Schriver’s book, Dynamics in Document Design, describes many of the technical communication and usability projects from the Communications Design Center [12].

The 1980s—Practice and Research
The 1980s brought many technical communicators into the world of hardware and software documentation. And this brought us into new usability techniques, usability labs, and applied usability research.

New Usability Techniques
Let me start with just two examples of how technical communicators were using and describing usability techniques in the 1980s.

Marshall Atlas may have been the first to describe the user edit as an evaluation technique for documentation (as Chauncy Wilson wrote in a 2006 retrospective) [13]. Atlas’s 1981 article in IEEE Transactions on Professisonal Communication [14] included two techniques as ways to have users involved in evaluating documentation:

  • The first was like a usability test—having the user go through the procedures in the document while using the product.
  • The second, a technique less frequently used today, was to have users mark up a draft document to indicate places where they were confused, didn’t understand, wouldn’t know what to do next, and so on.

Candace Soderston, who was an information developer at IBM and a doctoral student at RPI at the time, described her IBM group’s three usability procedures in 1985:

  • Visiting customer sites to interview users and see their environments;
  • Doing task analysis for the product “before writing a single word” [15, p. 16];
  • Testing interim drafts with people who represent the target audience [15], [16].

This was the same year that two psychologists at IBM, John Gould and Clayton Lewis, published the highly influential article in which they recommended three principles of design:

  • Early focus on users and tasks;
  • Empirical measurement (“early in the development process, intended users should actually use simulations and prototypes to carry out real work, and their performance and reactions should be observed, recorded, and analyzed”);
  • Iterative design [17, p. 300].

Usability was being advocated by both technical communicators and psychologists at IBM and elsewhere.

Usability Labs
IBM had usability labs in the early 1980s. I helped Hewlett-Packard conduct one of its first usability tests (without a lab) around 1984, and I set up AIR’s first usability lab in 1985.

Most technical communicators moving into usability began by usability testing documentation, but many of us quickly moved to conducting usability tests of entire applications. When we watched users struggle with products, even if our mission was only to test the manuals, it was impossible not to see the interface problems.

This led us in two directions:

1. Many of us technical communicators pushed our teams and clients to allow us to build clearer communications into the interfaces, clarifying messages, choosing users’ words for menu items, ensuring consistency across screens and functions, and so on.

2. Many also pushed to become involved as user advocates and user researchers earlier in the process, to move from testing usability at the end to building in usability through more predesign research on users and their tasks [18].

Theory, Basic Research, and Applied Research
Theory and research relevant to UX design, user-centered design, and usability come from many fields, just as the people who practice usability do. Most usability professionals recognize the relevance of work in cognitive psychology, sociology, and anthropology. Not all realize that while technical communication is a practice, it is also a field with underlying theory and research—in rhetoric, discourse analysis, conversational analysis, Speech Act Theory, pragmatics, information design, typography, and cultural studies.

For example, as Cooke [19] points out, Boren and Ramey [20] have shown that the think-aloud method typical of contemporary usability testing is no longer the pure think aloud as promulgated by Ericsson and Simon [21], but does have a strong theoretical basis in Speech Act Theory.

In the Document Design Center, we drew on theory and research from many disciplines [22], [23]. And we conducted applied research on issues related to how people use (and don’t use) documents [24]–[27].

By the mid-1980s, technical communication graduate students were working on doctoral dissertations on usability techniques, such as these two examples, both from CMU:

Patricia Sullivan observed users with a manual and a product, finding the following:

  • No one started with the manual.
  • No one read the entire introduction.
  • People went to the manual only when they had a problem and read only enough to get back to their task [28].

Schriver studied how much writers could learn from usability tests of documents, not only for a specific document but as a way to improve their overall skills in understanding readers and readers’ typical problems.

She found that writers taught to detect and diagnose readers’ problems with the help of think-aloud protocols improved significantly in their ability to predict readers’ problems in text where no [think-aloud] protocol is available. This improvement was not found in writers taught “to consider the audience” using standard methods of audience analysis (emphasis in the original) [29, p. 168].

Technical communicators weren’t the only ones working on these issues. Charles Mauro, a human factors professional, has been doing usability testing of products and their instructions since 1975 [30]. John Carroll, now the Edward M. Frymoyer Professor of Information Sciences and Technology at Penn State, a founder of SIGCHI and the field of human-computer interaction, spent much of the 1980s at IBM conducting research on how people use information to learn and use computers. This work resulted in the concept of minimalism in documentation [31], [32].

Carroll continues his interest in the intersection of information, technology, and usability as coauthor of one of the papers in this special section [33].

Patricia Wright, now at Cardiff University in Wales, is a psychologist who has contributed enormously to our understanding of how people use information. Her seminal papers on forms, technical information, and usability, and why we need a theory of not reading greatly influenced me as I set up the research and practice agenda of the Document Design Center [34]–[36]. Wright’s work has always been applied research—with appropriate audiences from the community (not students), real materials, and realistic tasks. Unlike much other academic research, Wright’s work meets Caroline Jarrett’s criteria for findings that practitioners can use [37].

The 1990s and Beyond
In the early 1990s, technical communicators were the prime movers in creating both UPA and the usability profession’s online community. Janice James, founder and first president of the UPA, is a technical communicator turned usability professional. Among the more than 100 people at the first UPA conference, my personal estimate was that about one-third came from human factors and experimental or cognitive psychology, about one-third came from technical communication, and about one-third came from computer science and other fields.

At about the same time, Tharon Howard, Professor of Professional Communication and Rhetoric at Clemson University, opened an online community for people interested in usability research and practice. More than 18 years later, he still leads that community, which has grown to more than 1,000 usability professionals. The online community, like UPA, brings together people from all of the backgrounds in Fig. 1 (page 9) and even more. And in that same era, Janice James and I got approval from the STC for a virtual community of people interested in usability—since renamed to Usability and User Experience (STC UUX) and still among the largest of STC’s virtual communities.

Judy Ramey, Professor and former Chair of the Department of Technical Communication at the University of Washington (now the Department of Human Centered Design & Engineering) established her Laboratory for Usability Testing and Evaluation (LUTE) in 1990. In a collaboration between a human factors specialist and a technical communicator, both of whom had become usability profession-als, Dumas and I published A Practical Guide to Usability Testing in 1993 [38]. Similarly, Judy Ramey collaborated with Dennis Wixon, who was active in SIGCHI, on an anthology of field methods [39].

More academic programs today combine technical communication and usability, including ones at Clemson University (Tharon Howard), Southern Polytechnic State University (Carol Barnum), and the University of Baltimore (Kathryn Summers).

A Final Context Point: Individuals Intertwining the Strands
Over these decades, some technical communi-cators made the transition completely to conducting usability studies rather than writing or editing, but their background makes them ever mindful of the importance of content and communication.

This includes some of the people best known in the usability profession today, such as the following:

  • Dana Chisnell, a former board member of STC and coauthor of the second edition of The Handbook of Usability Testing [40];
  • Steve Krug, author of the most popular books in the usability field [41], [42];
  • Tamara Adlin, coauthor of a major book on personas [43] and founder of the website UX Pioneers [44].

Many of you reading this will probably chime in with “Me, too; I’m a technical communicator practicing usability,” or “I’m a technical communicator who has become a full-time usability professional,” or “Yes, I’m now a content strategist.” Or perhaps you have intertwined the strands from the opposite direction. You are saying, “I’m a usability professional who now focuses on communi-cation and content.” You would not be alone. Increasingly, usability professionals (especially those working on websites) are realizing the importance of well-crafted content and writing.

Looking Ahead to Further Contributions

Moving from the past to the present and beyond, we can ask why so many technical communicators gravitate to usability and what technical communicators can continue to contribute as the usability profession moves forward. I see reasons in all four elements of the original question:

  • Successful technical communication requires excellent collaboration skills, the ability to work well in multidisciplinary teams.
  • The particular skill that technical communicators bring to teams is their ability to communicate clearly—not only in their own work (manuals, messages, and more) but in helping others on the team make their work clear and persuasive.
  • Technical communicators have always seen their job as clarifying the complex—understanding complexity and explaining it clearly.
  • In the ever-changing world and technologies in which they work, technical communicators have to be open to change, quick to adopt and adapt new ideas and new tools.

One of the reasons why the usability profession draws people from so many fields is that creating successful user experiences requires a wide range of skills. No individual has all of the needed skills. Thus, collaboration and teamwork are essential. Technical communicators have to collaborate—with designers, developers, programmers, and subject matter experts to gather information; and with editors, reviewers, and others to verify the accuracy of their information. Therefore, technical communicators are educated in process and teamwork as well as in guidelines for specific communication products. Most technical communication programs include project-based classes in which groups work with actual clients to go through the entire analysis, design, development, and evaluation process.

Most technical communicators also see part of their role on a team as being the users’ advocates. They see themselves as the intermediary between the technology and the user, between the technologists and the users. Involving users at all stages, collaborating with users, participatory design—as exemplified in the paper by Kase, Zhang, Carroll, and Rosson—is a natural extension of this user advocacy for most technical communicators [33].

Over the last three decades, usability has moved

  • From primarily meaning usability testing (too often done only once, lab based, too late in the process);
  • To user-centered design meaning a much longer, broader, and deeper infusion of a usability philosophy and toolkit throughout the process;
  • To UX design focusing even more broadly, beyond a specific product to larger contexts of use [45].

With each step in this broadening, collaboration becomes more critical.

Of course, some of us have been advocating the longer, broader, deeper, and even total-context view of usability for a long time. And, as I explained in my 2004 keynote to the UPA conference [46], as each new community comes to the forefront of usability, that community brings its specific skills and its desire to lead the entire process. Figure 2 is a graphic depiction of this issue.

For example, at the Document Design Center, people sometimes assumed that our focus was on design that equals layout and typography—a narrow definition of design. But, in fact, our focus was always on design that creates a product that works for people—a very broad definition of design that might today be seen as equaling the entire UX.

I call this the problem of little and big: Little usability equals usability testing; big usability equals UX. Little information architecture (IA) equals organizing the content of a website; big IA means creating the site that works for its users. Little plain language equals plain language seen as only about short sentences and small words; big plain language is plain language as UX where people can (1) find what they need, (2) understand what they find, and (3) act appropriately on that understanding [47]. When the disciplines compete to lead the entire effort, it creates tensions among individuals and the focus each of them brings. It also creates tensions between groups—each seeing their credentials (from academia or practice), their community, and their professional society as being more important than others.

The future for everyone involved in creating successful user experiences must include greater mutual respect for each other’s backgrounds, skills, and possibilities. Valuing one academic degree over another is harmful and tears the profession apart. So does valuing academic degrees over relevant practical experience. Also harmful is dismissing history as irrelevant and theory and research as unimportant.

We need to learn to collaborate among ourselves (bringing together all of the arrows in Fig. 1 and all of the arrows that would be similar to Fig. 1 in older and younger professional communities than UPA). Some of this occurs in our online communities and through individuals who belong to multiple communities.

We also need to be humble about our own skills and spheres of influence. For example, most technical communicators are highly skilled verbally, but often not visually; we need to partner with graphic designers. And, of course, the converse is true, too. In my web work, I sometimes meet graphic designers who could be more humble and who don’t yet see the critical importance of content and writing.

And we need to expand our notion of team. As many usability professionals have recognized, we need to understand not only our users and their goals and needs. We also need to understand the executives and managers who fund our work. We collaborate not only in the small (our specific product team); we collaborate in the large (the businesses we support either as an employee or a consultant). We need to understand business goals and speak the language of executives and managers—which leads me to the topic of how technical communicators can help with communication.

Whatever you are creating (hardware, software, web application, information website, e-commerce website, stand-alone document), the product would have no reason to exist without users. The interaction and interface of your product are the ways that the product “affords” itself to its users [48, p. 9]. We might also say that’s the way the product communicates with its users.

Many technical communicators become usability specialists because they get tired of writing ancillary documentation (user assistance, such as manuals and help systems) when the product itself communicates poorly. They want to make the interaction and interface communicate better and reduce the need for other user assistance.

Sometimes, technical communicators have provided the greatest usability support by not writing. For example, one of the case studies in the project that Judy Ramey and I led in the 1990s on the value that technical communicators add to their companies and clients [49] was from Al Blackwell at American Airlines Sabre Travel Information Network. Blackwell tells how his team saved money by convincing developers they did not need an extensive user manual: A short installation guide would be enough. And they were right. The short guide was used where the longer manual might not have been. Installation rates went up. Help calls went down. Here were technical communicators acting not as writers but as strategic planners and thinkers concerned with the larger user experience [50].

Where hardware and software were the major products in the early days of usability, today most usability professionals focus on websites. For websites, the two strands of technical communication and usability are inextricably intertwined. People come to websites for the site’s content. They come for communication. As I explain in my book, Letting Go of the Words—Writing Web Content That Works, every use of every website is a conversation started by the site visitor [51].

Communicators—technical commun-icators, marketing specialists, copy writers—are critical to successful websites. Plain language and information design are critical to successful websites. Technical communicators, information architects, and web usability specialists are coming together over the need for content strategy (new words for the concept that content must be planned, coordinated, and managed strategically) [52]. In April 2010, the France chapter of the Society for Technical Communication hosted the first Content Strategy Forum, a gathering of people from all perspectives in UX who focus on content strategy.

Usability specialists have adopted personas as a way of representing users, especially users of the websites they are helping to develop. But a decade ago, technical communication professors Mary Coney and Michaël Steehouder explained that a website also projects a personality—through the decisions web teams make about content, tone, color scheme, and more [53]. Technical communicators join brand specialists and usability specialists to understand the importance of websites that communicate well.

Technical communicators also help teams communicate within the team and up through the management and executive chains. All of the elements of UX design, user-centered design, and usability apply to communicating results of user research and of usability testing. Technical communicators’ skills in audience analysis, task analysis, context-of-use analysis, organizing information, and writing are critically important in the future of usability.

We are overloaded with possibilities, technologies, social media, and information in multiple media. Many of us and many of the people for whom we create products and processes are overwhelmed. Understanding complexity—how to create products and processes for complex situations as well as how to build usability in and assess the usability of complex systems—is becoming a major topic for technical communicators and usability professionals. (See, for example, the 2003 book edited by Michael Albers and Beth Mazur [54], as well as the case studies in Usability of Complex Information Systems: Evaluation of User Interaction, edited by Albers and Brian Still, the editors of this special section [55].) This may be especially important in light of research showing that people are very poor at multitasking [56].

Barbara Mirel, another technical communicator turned usability professional, was among the first to bring complex knowledge work to our attention [57]. Real-life situations in hospitals, inventory management, resource management, compiling covert intelligence information, and many other fields involve complex problem solving. Many of these situations involve users integrating information and visualizations from different products and dealing with incomplete information, with no single right answer to the initial question. As Mirel says, these types of “complex tasks and problem solving are different in kind not just degree from well-structured tasks” [58, p. 233].

Mirel anticipates the current focus on UX design when she explains that many systems fail because the designers and developers did not take into account the realities of the users’ work. Mirel’s example that I find most compelling is one from health information technology—the field that will perhaps be the most significant growth area for UX in the near future [57].

The task-oriented procedural manuals and help systems that are the mainstay of modern technical communication aren’t sufficient for these complex situations. Hackos gives us some ideas on how to write for these situations [59], but specific situations will require new ways to communicate. For usability professionals, these situations also require us to rethink our usability testing methods, as I discuss in a 2007 essay [60].

Complexity itself is a very complex issue. Yes, some systems are obviously complex. But systems that were thought to be simple often turn out not to be. Muller and his colleagues found that telephone operators who answer calls for information are knowledge workers—not just doing look-up tasks that could be automated but solving problems through knowledge accumulated over time [61].

Three articles in a special issue of the Journal of Usability Studies all found that support for knowledge work is distinctly challenging. As Mirel points out in her introduction to the issue: The authors of all three articles find that work typically considered well structured is, in fact, not well structured. Moreover, supporting it as such has the following adverse effects:

  • Users are confident in work that is inaccurate.
  • Users misapply tool capabilities that result in suboptimal results.
  • Users do not deem a system valuable and, therefore, stop using it [62, p. 149].

Complexity is not so much an attribute of a product or process itself as it is an attribute of the interaction between that product or process and its users. Thus, complexity is audience specific. This works both ways. What we may think is complex is not to the audience. What we may think is simple is complex for the audience. The most effective and efficient interface for experts may be different than one for novices, and experts may be very specific in their expertise.

Adaptability is a trait that technical communicators and usability professionals share. Most technical communicators and usability professionals have transformed themselves—possibly several times—over the course of their careers. Some of us have moved quite far from our origins and the expectations of our formal education.

We have coped with the changes in media, technology, tools, and methods, and we know that the future holds more of these changes. UX is about being part of that future, helping to shape the future in ways that make it work well for people. Perhaps being reminded of how deeply and how long technical communication and usability have been intertwined will increase mutual respect and collaboration in future work on the entire UX—interfaces, architecture, content, and more. CIDMIconNewsletter


The author appreciates the invitation from the editors of the special section, Brian Still and Mike Albers, and the editor of IEEE Transactions on Professional Communication, Jo Mackiewicz, to contribute the commentary. The author would also like to thank Caroline Jarrett and Whitney Quesenbery for comments on an earlier draft.

To view the full list of references, please click here.