Note: In the first part of this essay, Ginny Redish extracts highlights from and builds on her recently-published commentary (Redish, 2010) about the intertwined history of technical communication and user experience. In the second part, Carol Barnum asks deep questions about roles that people with technical communication training have—and could have—within user experience (UX).
Part 1. Technical Communication and User Experience Have Grown Up Together
By Ginny Redish
UX practitioners come from many disciplines, as Whitney Quesenbery shows in Figure 1. I hope you are represented by at least one of the arrows in this picture. If not, let me (Ginny) know. I’m interested in how broad the backgrounds of UX specialists are and how many disciplines contribute to UX.
Figure 1 User experience professionals come from many backgrounds (Quesenbery, 2011) © UPA, found on UPA website at http://www.usabilityprofessionals.org/usability_resources/organizations/
Arnie Lund (Lund, 2006) and Joe Dumas (Dumas, 2007) tell the history of usability as a human factors engineering discipline that moved from the experimental model of academic psychology to the mostly qualitative, practice-based toolkit it is today.
Deborah Mayhew (Mayhew, 2008) tells the history as a journey through software development.
Much current narrative about UX and usability, especially related to websites, comes from information architects, interaction designers, content strategists, and others who were not part of the early days of human factors or software engineering.
Another discipline that has had a deeply intertwined history with usability and UX is technical communication. It’s the path that brought me, a linguist by training, into usability testing, and then field studies, and then the entire rich toolkit of UX techniques that I practice today.
Many UX Community Members Come From Technical Communication
You may be surprised how many people you think of as usability specialists started out as technical communicators. In fact, UPA was started by a technical communicator who had become a usability specialist—Janice James, our organization’s founder and first president!
In addition to Janice James and the two of us (Ginny Redish and Carol Barnum), we can include
- Tamara Adlin, co-author of the book on The Persona Lifecycle and interviewer of the UX Pioneers;
- Dana Chisnell, co-author of the second edition of The Handbook of Usability Testing;
- JoAnn Hackos, my co-author on the book about User and Task Analysis for Interface Design;
- Tharon Howard, founder and still leader of the UX community’s online community and author of the recent book, Design to Thrive: Creating Social Networks and Online Communities that Last;
- Steve Krug, author of two best-selling books on UX;
- Whitney Quesenbery, former president of UPA, leader of the UPA project on Usability in Civic Life, and co-author of Storytelling for User Experience;
- Judy Ramey, former chair of the Department of Technical Communication at the University of Washington (now the Department of Human Centered Design & Engineering) and co-editor of the anthology, Field Methods Casebook for Software Design;
- Stephanie Rosenbaum, whose firm, Tec-Ed, has combined technical communication and usability since 1967;
- and many others.
Why and How—Technical Communication as a Logical Path to Usability
Technical communicators are by training and necessity user-centered. Their focus is always the audience, the people who will use whatever they are creating. Their goal is to make even complex interactions understandable and usable.
My personal journey into usability began in the late 1970s when the U.S. government decided to fund a project about the problems people have understanding typical government documents. At that time, I was a research scientist at the American Institutes for Research (AIR). AIR bid on the project with Carnegie-Mellon University and a private design firm—and won.
Even in our proposal, we included a "process model" of how to develop a successful document. The model included pre-design user research, developing drafts (prototypes) based on that research, and evaluation with users (usability testing, although we didn’t call it that). Our pre-design research included user analysis, task analysis, context analysis, user-task matrices, and user profiles. This was 1978!
We built the process model on earlier work of AIR colleagues in instructional technology—an example of what Stu Card of Xerox PARC calls "steal and modify"—one of the "most popular methods for artifact creation" (Card, 1996, p. 153).
Of course, in the early days, technical communicators focused mostly on the usability of documents. In the 1980s, that focus was largely on computer documentation, online help, and other ancillary materials.
But it was not long into the era of personal computer software that many technical communicators realized they could be even more helpful to the final product by making the interface communicate better. Why struggle to explain a difficult interaction when we could help more with user-centered changes to the underlying architecture and wording?
How Technical Communication Led to UPA and More
From the 1980s on, many technical communicators made the transition from writing as a user advocate to usability specialist—helping to build usability into products, doing user research and analysis, assuring usability through usability testing and other evaluation techniques. By 1991, for example, while still a member of the Society for Technical Communication (STC), Janice James was leading a usability team with a fabulous lab setup at American Airlines’ Sabre Travel Information Network.
That year, at Janice’s instigation, a group of practitioners met at a Birds of a Feather (BOF) session at the SIGCHI conference and decided that the time had come to convene a new association focusing on usability practice. UPA was born.
And, at the same time, Janice James and I convinced the STC Board to start a virtual community of STC members interested in usability. Twenty years later, now called Usability and User Experience, it remains one of the largest of STC’s 22 virtual communities.
From the beginning, UPA has been a place for people from different backgrounds to feel comfortable together—to meet, to share, to collaborate. Joe Dumas, now editor of JUS, and I, for example, have both been part of UPA from the beginning.
When UPA started, Joe (a human factors specialist) and I (then managing a large team of technical writers) were already collaborating with each other and with Janice James. The training classes that we developed for Janice led to the first edition of A Practical Guide to Usability Testing, as far as I know the first "how-to" book on the topic (Dumas & Redish, 1993).
An Aside on the Continuing Issue of the Usability of Documents
Most technical communicators today bring their user-centered approach and communication skills to teams developing software, hardware, web applications, and other websites. However, stand-alone documents or documents that are major parts of systems are also user experiences. They require user-centered approaches and all the techniques of the usability specialist’s toolkit.
A critical case in point is the voting experience and the ballot that is the key element of that experience. UPA has an active project on Voting and Usability, about which many of us who combine our backgrounds in technical communication and usability are passionate: Dana Chisnell, Whitney Quesenbery, and me, among others.
Technical communicators and usability specialists have improved the voting experience in several projects, including the following:
- working with and training election officials to do usability testing of ballots, using a set of materials specifically designed to test ballots
- contributing to research and advocacy, such as the Better Ballots report
- collaborating with AIGA’s Design for Democracy to use templates for election materials, including ballots and instructions for voters and for poll workers
Similarly, Dana Chisnell and I, both technical communicators and usability specialists, have conducted usability research for the National Institute of Standards and Technology, using typical usability techniques to show the importance of language (as well as design) in ballots and other voting materials.
Technical Communication Also Brings Theory and Research to UX
Most usability specialists recognize the relevance of theory and research in fields such as anthropology and cognitive psychology. Not all realize that while technical communication is a practice, it is also a field with underlying research and theory in discourse analysis, conversational analysis, cultural studies, information design, pragmatics, reading research, rhetoric, speech act theory, typography, and academic studies of writing.
For example, Ted Boren, a student of Judy Ramey’s, studied the practice of usability specialists conducting usability tests. He found that our contemporary practice is not the think aloud of Ericsson and Simon, but it does have a strong basis in speech act theory (Boren & Ramey, 2000).
My own research in information design, reading (and not reading), in how people use documents and websites is grounded in discourse analysis, conversational analysis, and pragmatics. I see communication and user experience as so intertwined that my definition of usability and my definition of plain language are identical:
Usability and plain language both mean that the people who use (or should use) what you develop can find what they need, understand what they find, and use what they find to meet their needs.
This behavioral (usability) definition of plain language has been officially adopted by both the Norwegian government and the U.S. government as well as by the U.S. Center for Plain Language. (For the U.S. government, see the Federal Plain Language Guidelines at www.plainlanguage.gov.)
Technical Communication Continues to Intertwine With UX
The commentary I am drawing on for this essay was part of a special issue of the IEEE journal, Transactions on Professional Communication. Three of the four themes of that special issue were collaboration, communication, and change. In each of these three topics, technical communicators bring expertise to UX teams.
Collaboration
UX requires teamwork. Technical communicators are trained in teamwork. They must collaborate: to gather information from engineers, programmers, and subject matter specialists; to negotiate reviews with these and other team members; and to combine content and design to get to final products.
Over the last three decades, "usability" has moved
- from a primary focus on usability testing
- to user-centered design—a longer, broader, and deeper infusion of a usability approach and toolkit throughout design and development
- to UX—focusing even more broadly on the larger context of use.
With each step in this change, collaboration has become more critical. Technical communicators’ background as user advocates within a collaboration is one reason that many of us coming to UX through the TC path have been so helpful to our teams.
Communication
UX requires clear, usable, and useful communication—in many directions. Technical communicators help teams communicate clearly within the team; with clients; up through management and executive chains; and, of course, to the users. Just think how much successful communication a UX project requires: the results of user research, the design, the results of iterative testing, and more.
The web—internet, extranet, intranet—inextricably intertwines communication and usability. People come to websites for the site’s content. They come for communication. As I propose in my book on writing for the web, successful websites come from realizing that every use of your website is a conversation started by your site visitor.
Adaptability is a trait that technical communicators and usability professionals share. Many of us, no matter which of the rays in Whitney’s starburst we come from, have transformed ourselves—possibly several times—over our careers. We have coped with changes in media, methods, technology, and tools. We know that the future holds more changes for us. 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 overlapped, influenced each other, and intertwined will increase mutual respect for all of us coming from our different backgrounds. By Carol Barnum When Ginny Redish wrote her commentary for IEEE Transactions on Professional Communication (2010), I was struck by the clarity and comprehensiveness of her presentation of the history of the usability profession and the role that technical communicators have played in its development. I was also struck by the fact that the strong message of her commentary—“we are family” (to quote Sister Sledge)—would be heard and read by those who already knew and understood this relationship. But not by those who did not. I suggested that she was “preaching to the choir.” Ginny did not merely acknowledge my comment: She contacted the editors of JUS to see whether there would be any interest in crafting a similar piece for the readers of JUS. When the response from Joe Dumas was positive, she invited me to join her in the commentary. I accepted, because I am one of those converts she refers to: someone who started out in technical communication and found a perfect match in usability and user experience. I also teach usability testing in a technical communication program, so I understand the role and relationship of technical communicators in a UX world, as well as the challenges my students face in proving their worth in the marketplace. While some of my students have had enormous success in UX, others have longed to be included but have not been able to make progress in the companies they work for or in the companies that seek to hire UX professionals. My part in this commentary is to reflect on three challenges as I see them: My goal is to provide food for thought on how to widen the net to embrace the skills and talents of technical communicators in the job hiring process and to stimulate technical communicators to join with UX specialists in contributing to conference sessions and publications. First, by way of a little background, I should begin with “why?” The basic tenet of technical communication is user analysis. Everything starts with the end user. Frequently, the technical communicator is the person in the development process who focuses on the end user. Technical communicators see themselves as the user’s advocate. And, traditionally, it is the technical communicator who shoulders the responsibility of making sense of a confusing or complex feature or interface. The oft-heard refrain from developers—“They can fix that in the documentation”—is the solution to addressing unusable aspects of a product, especially when usability research is not conducted until late in the development cycle, if at all. User focus has always been a central tenet of technical communication education and training. Most technical communication programs are grounded in the principles of rhetoric, especially when the program is housed in a university’s English department. Aristotle’s rhetorical principles focus on audience, purpose, and context of use. Loosely interpreted, this manifests itself as getting the answers to the following questions: However, technical communication has grown and expanded beyond the basic tenets of rhetoric and become a discipline, as well as a profession. The traditional role of technical writers as documentation authors has long since expanded to include ownership of content in any medium. Technical communicators today not only write user assistance and related documentation, but they also work as information architects, website creators and content specialists, instructional designers, and marketing communication specialists, just to list a few of the sub-specialties within the field of technical communication. When I started teaching, very few academic programs focused on technical writing. Most faculty held advanced degrees in English. Technical writing was a service course on report writing to support engineering-related programs. In those days, the debate at academic meetings was whether and why we should start calling the field technical communication instead of technical writing, reflecting the fact that our students were not just writing, but also creating graphics and designing products in multiple media. Now, as a result of the continuing expansion of the roles and responsibilities of technical communicators, some academic programs have moved away from the label of technical communication to embrace the broader categories of information design, instructional technology, new media, digital literacy, and other names reflective of the new courses and new jobs available for technical communicators. My program is one of these. We changed the name of our graduate program from Technical and Professional Communication to Information Design and Communication, reflecting our broader course offerings in multimedia, information architecture, instructional technology, web design, visual thinking, and, of course, usability testing. A few programs have moved even farther from technical communication to align with user experience. The most recent example is the change at the University of Washington from the Technical Communication Department to the Human-Centered Design & Engineering Department, and the corresponding change in the name of the degrees offered. Bentley University has been offering its MS in Human Factors in Information Design for a number of years. Other programs, while keeping to more traditional names such as Technical or Professional Communication, have expanded their offerings and facilities, building usability labs and teaching courses in user research and usability testing. These include Texas Tech University, the University of Baltimore, Rensselaer Polytechnic, and Clemson University, to name a few. Not only are instructors with the education and experience to teach these courses in high demand, but so are the graduates of these programs and the technical communicators who have this type of work experience. The Occupational Outlook Handbook for 2010-11 (Bureau of Labor Statistics [BLS], 2010-11), which still refers to the job as “technical writer” (but cites “technical communicator” as an alternate job title), describes the job as being in higher demand than the average, particularly “for those with Web or multimedia experience.” For more information, they cite the Society for Technical Communication, which has made it a major goal to promote changing the job title from technical writer to technical communicator. STC’s effort has resulted in a potential review of the title for the possible addition of technical communicator, which would allow the BLS to track this category as distinct from the category of technical writer. Change is already in evidence, as its current description of the work of the technical writer shows a marked improvement in understanding the work that technical communicators do. An editorial by Susan Burton, Executive Director of STC, highlighted the reason for STC’s push for the proposed name change and definition of the technical communicator: "The new definition clarifies that technical communicators assure the ‘safe, easy, proper and complete use’ of products and services and refers to increased usability and accessibility. In other words, it focuses on the timeless value we provide, not the medium we are using” (Burton, 2007, p. 56). Given these evolving changes in work definition and education for technical communicators, the connections between technical communicators’ interests and UX professionals’ interests should be obvious. Not only does this shared interest in the user make for a mutually compatible set of goals by both the technical communicator and the UX practitioner; but in cases where the team or the product does not have a UX practitioner, the technical communicator can and often does take on this role. Yet, the challenges for technical communicators to be recognized, recruited, and represented in UX work remain. I outline three of these challenges. The Bureau of Labor Statistics Occupational Handbook, even in its current restricted definition of “technical writer” puts these professionals within UX teams, as evidenced by the following statement in the 2010-11 description: “Applying their knowledge of the user of the product, technical writers may serve as part of a team conducting usability studies to help improve the design of a product that is in the prototype stage.” The problem often arises when the product developers either do not acknowledge the important role technical communicators can play in providing a user-centered focus on audience, purpose, and context of use, or they think that they “own” this part of development. In either case, the potential contribution of the technical communicator is not sought or not accepted, when offered. As far back as 1998, Donald Norman, one of the early and strong advocates for usability testing as part of product development, stressed the importance of putting together a multi-disciplinary team to develop “human-centered” products. Among the six skills he listed as critical to the team was the understanding of audience and the user’s activity, which he attributed as the strength of the technical writer. He went on to assert that “technical writers should be the key to the entire operation” (Norman, 1998, p. 191). Yet, anecdotal evidence from my former students and gleaned at technical communication conferences suggests that technical communicators have not generally been invited to take a seat on the development team or as part of a user research team. This tendency to exclude or ignore the technical communicator manifests itself in one of two ways: In both cases, the problem may stem from misplaced attitudes or impressions. On the one hand, development teams, including UX specialists, often hold the stereotyped view that technical communicators are merely the ones who write the manuals and sometimes the online help. On the other hand, technical communicators can be complacent about their defined role as doc writers or lack the confidence to fight the stereotype of the box that they are perceived to be in. The technical communicator is not part of the development team, but discovers when it comes time to document the product that lots of usability issues surface. At this late stage in development, however, it is not feasible to change the product; so the technical writer must “explain” the problem/solution in the documentation or context-sensitive help or embedded assistance. The technical communicator’s manager might support informal—or even formal—testing to find usability problems so that the technical communicator can write the appropriate documentation or user assistance. While this helps the technical communicator understand what needs to be explained to users, it does not improve the design of the product. And the word does not get out that the technical communication group has conducted usability testing. The technical communicator seeks to implement usability testing within product design because it is not currently a part of the design process. Here’s an example of what can happen: A former student in my usability testing course became passionate about usability testing and wanted to find a job that allowed her to do testing and use other UX tools for user research. She was hired as a technical writer for a company that develops web applications. She took the job because the company was interested in doing usability testing and felt that it could use her experience to help them get started. However, the UX program did not get underway as promised. So, to help educate the company about the benefits of user testing, my former student convinced the company to become a sponsor for my usability testing course, in which the students set up and conduct usability testing of the sponsored project and report the results to the sponsor. The sponsor was enthusiastic about this opportunity to learn about the users’ experience with the web application, but the findings report and presentation to the company did not translate into starting an internal UX program. Almost two years after the sponsored project, the company is interested in being a sponsor again. To me, this suggests the interest is there, the results are informative, but the commitment for UX research in house has not materialized. The technical communicator is disappointed in the lack of opportunity to do user testing at the company and yet is unable to secure a job doing UX work elsewhere because of a lack of work experience in the field. For UX specialists: Recognize, as Donald Norman did in his description of the important role that technical communicators play on human-centered design teams, that technical communicators know a lot about user experience, either through education, experience, or both. They are the user’s and the UX practitioner’s ally on design teams. For technical communicators: Be more aggressive at joining development teams early in the product development process and spreading the word about the skills and experience you can bring to the team. When the UX profession became highly marketable in the 1990s, as noted by Joe Dumas (2007), the field opened up to include technical communicators and trainers and others. Joe comments that “some people with psychology and human factors backgrounds saw this as a watering down of the skills of the profession” (p. 56). Joe does not hold this view, seeing the expansion as “a democratization of the profession” (p. 56). UX professionals with backgrounds in human factors and psychology sometimes emphasize their skills in statistics and experimental design, and the lack of those skills in technical communicators. The reality is that those skills are rarely needed in either product design or evaluation and can be obtained easily in the few cases in which they are required. An interesting question to ponder is how a degree in disciplines such as human factors or psychology equips those professionals to be UX specialists over the training received in a modern technical communication degree program. Perhaps those who favor exclusivity have held sway, particularly with the shrinking of the job market because of current economic conditions. But the commonalities between these two overlapping professions suggest that an opportunity is being lost to strengthen the bonds between us rather than focusing on our differences. The new and growing interest in content management strategy has potential to serve as the natural bridge. As well, information architecture offers a strong bridge, and a number of technical communication programs now offer a course or courses in one or both of these areas. The two separate and distinct efforts at defining a body of knowledge, first undertaken by UPA and now by STC, also suggest and reveal shared knowledge as the basis of defining the professions. These developments—academic, professional, and knowledge-defining—suggest ways of bringing together or exposing the overlapping disciplines of the two professions, which share a common goal of user advocacy. However, when it comes to job openings, the overlap is not as frequently seen as it might be. A review of recent job postings listed on the UPA website suggests some provocative questions. Do the job openings for UX professionals reflect an understanding of the potential for technical communicators to fill these positions? Do technical communicators who apply for UX jobs get serious consideration? Are internships available for technical communicators to gain UX experience while still in school? Here is what my review shows: The inclusion of technical communication in the last listed job posting, which is mentioned within the long list of applicable degrees, is an encouraging sign, but the only one I saw on review of several months of postings. As it happens, this last listing is from a company in Atlanta, which has hired several of our technical communication graduates, as well as provided internships to our undergraduate students. Perhaps the inclusion of technical communication in the list of eligible degrees is an indication of this particular company’s good experience resulting from hiring technical communicators for this type of position. As for the other positions, which do not list technical communication among the degrees required or preferred, will it be likely that they would interview or hire a technical communicator? Would it perhaps be more likely that applicants with the stated degrees would get greater consideration? A technical communicator could perhaps persuade the company to give him or her a chance to prove the qualifications for the position, but the challenge is to be appropriately persuasive when the job does not identify the degree held by the technical communicator. For UX professionals: Don’t assume that an advanced degree in human factors or psychology is the only good route to becoming a UX professional. When you are hiring, broaden the job descriptions so that degrees listed include technical communication or related fields. Encourage your Human Resources department to advertise for openings in technical communication circles at the local and broader level. Participate in job fairs associated with appropriate programs at universities. Set up internships that include technical communicators with an interest and related course work in UX. For technical communicators: Emphasize your user research, information architecture, and content management skills in your résumé and learn to counter arguments that statistics and experimental design are necessary UX skills. Join UPA. Volunteer for usability work at the local level in your STC or UPA chapter or through your community involvement. Expand your portfolio to show the UX experience you have gained. With so much common background and focus, shouldn’t these two communities be able to share research and case studies at the conferences that UX practitioners and technical communicators attend? For the practitioner, that common ground is UPA, both at its annual conference and in its publications. Although I am a regular attendee at UPA conferences and also a speaker at some, I don’t see a lot of technical communication-centered sessions at the conference by or for technical communicators. Not only do I not see technical communicators presenting at many UPA conferences, but I also don’t see many UX practitioners presenting at STC conferences, with the exception of a handful of technical communicators doing UX work. A review of the programs for the past several UPA conferences reveals only a handful of presentations by and about technical communication and UX, mostly in 2008. The same dearth or limited number of topics by and about technical communication and UX is also the case for articles in UX Magazine and JUS. A recent issue of UX Magazine provides a rare exception with the inclusion of one potential article of interest: “Writing Tutorials that Actually Help Users” (Vogel, 2010). The author identifies himself as a software developer, interface designer, and technical writer. However, the author does not identify himself as a UX practitioner and he addresses his UX audience from the technical writer’s “outside” perspective, writing: “As you probably know from your own experience, error happens. You’re not a professional writer, so it’s to be expected that some of your steps (however much sense they make to you) won’t make sense to your readers” (p. 15). While this likely resonates with those UX practitioners who are not professional writers, it leaves out those professional writers who are also UX professionals. Prior to this issue of JUS, there have not been any peer-reviewed papers published that overlap the UX and technical communications areas. There are papers in technical communications journals that could be published in UX journals but that seldom happens. Why? Are technical communicators more comfortable publishing in their own community? Do they fear rejection? Is that fear justified? At this point, we have only questions without answers. We need to hear more from the insiders who wear both hats. Conference reviewers for the UPA conference who recommend sessions to accept or reject can broaden their understanding of who our users are as they review proposals for acceptance at the conference. Reviewers of JUS and UX Magazine who read manuscripts for the journal and magazine can solicit, review, and accept more articles that focus on the connection between technical communication and UX. Not only should UX practitioners embrace the work and experience of technical communicators and make room for them on design and UX teams, but technical communicators can also take action to be heard and recognized for the skills we bring to UX work. We can translate this into action by To come back to my theme song, “We are family.” But at this point, even with the historical record to prove how much we are related, we often view our family members as distant cousins, whom we occasionally see at family reunions (like this one), but then return to our separate and distinct homes and continue on with our work as before. Ginny started this discussion of why we should see ourselves as from the same family tree, and I concur with her concluding remarks in this commentary that adaptability is required not only to survive in these changing times, but also to thrive. If we believe the predictions by the job prognosticators, both user experience and technical communication are projected to grow substantially and provide solid career opportunities. There should be room at the family table for all, and I’ve suggested some ways to move our chairs just a bit to allow for some of that room.Part 2. Raising Some Questions About TC and UX
Why Should Technical Communicators Claim a Seat at the UX Table?
Challenge 1: Technical Communication Has Changed, but Industry Does Not Reflect This Change.
Case in point for tendency #1
Case in point for tendency #2
Call to action
Challenge 2: Technical Communication Is Often Not Recognized as Good Background for UX Job Openings.
Call to action
Challenge 3: The UX Community Doesn’t Present or Publish Much By or About the Work That Technical Communicators Are Doing in the UX Arena.
Call to action
References