64.4, November 2017

Promoting User Advocacy to Shift Technical Communication Identity and Value

Sarah Martin, Texas Tech University; Nicholas Carrington, Cedarville University; and Nancy Muncie, Texas Tech University


Purpose: This study highlights key behaviors three professional technical communicators (TCs) used to enhance their professional identities and value in unique organizational contexts. It suggests that when TCs explicitly promote user advocacy to explain their work practices, it more positively represents the work that TCs do to other stakeholders.

Method: Using an ethnographic perspective, we reflect on how grounding our thinking, decisions, and actions in user advocacy during interactions with non-TCs resulted in successful outcomes.

Results: Promoting user advocacy while conducting user-centered design and user experience (UCD/UX) activities resulted in positive perceptions about our technical communication work; it broadened how non-TCs viewed our work beyond predetermined technical communication contexts.

Conclusion: Promoting user advocacy in tandem with UCD/UX methods may provide a productive avenue for TCs to connect their value to broader organizational goals and promote and preserve positive workplace identities.

Keywords: technical communication value, technical communication identity, user advocacy, user-centered design, user experience

Practitioner’s Takeaway:

  • TCs who ground arguments about their thinking, decisions, and actions in user advocacy can better demonstrate the positive impact of their work.
  • Promoting user advocacy in tandem with UCD/UX methods may help TCs construct, maintain, and preserve positive workplace identities.
  • The contributions of TCs in terms of organizational strategy and process management are clearer when TCs are explicit about how their work influences these factors.

Working as technical communicators (TCs) while also enrolled in a Technical Communication and Rhetoric doctoral program, we had the unique opportunity to consider, in real time, what technical communication scholarship tells us about technical communication practice. Regardless of our thoughts on whether scholarship or practice was “right,” one commonality emerged: Our ability to be successful in our workplaces largely depends on our ability to communicate our value to non-TCs. Non-TCs are likely the people who will hire us—in industry or academia. They are the beneficiaries of our technical communication work. Importantly, non-TCs influence our organizational and professional value. They determine which projects we work on, with whom we work, and the scope of our influence.

Reflecting on our workplace experiences, a means to communicate the TC’s value to non-TCs became clear: TCs should explicitly ground arguments about their thinking, decisions, and actions in user advocacy. This approach benefits TCs in three ways: 1) it demonstrates the positive impact of a TC’s work, 2) it helps construct, maintain, and preserve positive workplace identities, and 3) it makes the TC’s organizational strategy and process management contributions clearer.

Accordingly, this article demonstrates how promoting user advocacy in tandem with user-centered design and user experience (UCD/UX) methods enhanced our professional identities in diverse workplace contexts. By framing arguments about how our work impacts users, we positioned ourselves as vital organizational members. Our work products are now viewed less as isolated, sequential additions to existing products or processes and more as much-needed impetuses for important organizational initiatives. Importantly, our technical communication work became more visible and valued in our organizations.

Before we explain key practices used to promote user advocacy, we will review what it means to be a TC and how TCs can promote user advocacy in tandem with UCD/UX methods.

Who Is The TC?

Many scholars provide rich insights into the TC’s identity. There is thoughtful work into what TCs might do (Johnson-Eilola, 2004; Rude, 2009; Rutter, 2004; Slack, Miller, & Doak, 2004); what skills, processes, and practices they might employ (Andersen, 2014; Conklin, 2007; Hart-Davidson, 2013; Kimball, 2015; Redish, 2010; Redish & Barnum, 2011; Selzer, 2004; Winsor, 2004); and in what socio-cultural contexts they produce work (Britt, 2007; Coppola, 2012; Grabill, 2007; Henning & Bemer, 2016; Henry, 2006; Herndl, Fennell, & Miller, 1991; Knievel, 2006; Pace, 1988; Slack, 2004; Winsor, 1990). Importantly, we know that user advocacy also affords TCs (and their scholarship) valuable “interdisciplinary influence” (Jones, Moore, & Walton, 2016, p. 218). For practitioners, understanding and advocating for users is also critical to making sound content, design, delivery, and process decisions (Blakeslee & Savage, 2013; Ceraso, 2013; Dicks, 2013; Mirel, 2013; Schriver, 2013; Spinuzzi, 2013; Wysocki, 2013).

Ultimately, a TC’s identity defines his or her problem-solving approach. TCs, as symbolic-analysts (Johnson-Eilola, 2004) and user advocates, consider the full design context when they approach a problem. Wilson and Wolford (2017) remind us that TCs are “almost always located at the nexus of data, language, and meaning, trafficking in expanding economies of information within organizations” (p. 5). As such, TCs, through their user-centered approach, can add value to a variety of workplace initiatives (Dubinsky, 2004). As Johnson-Eilola (2004) reminds us, “most companies do not understand communication, information, and knowledge. Technical communicators do” (p. 188). In turn, it is the TC who applies a user-centered problem-solving approach to a variety of workplace contexts.

Suitably, TCs can apply UCD/UX approaches that place users at the center of the design or problem-solving process (Ceraso, 2013; Mirel, 2013; Redish, 2010; Redish & Barnum, 2011; Schriver, 2013). UCD/UX approaches safeguard user interests regarding all phases of problem-solving. While TCs conduct their work with a consideration of user advocacy (Hart-Davidson, 2013), UCD/UX approaches place the focus on users at the outset of a problem. Yet, the formal relationship TCs and UCD/UX professionals have to users does not trump their similarities. Redish and Barnum (2011) note important outcomes of acknowledging the shared interests and practices of TCs and UCD/UX practitioners: It can mitigate industry’s lagging adoption of broader and modern understandings of technical communication, eliminate disconnects between technical communication experience and UCD/UX knowledge, and reduce a lack of cross-publishing amongst TCs doing UCD/UX work. They also remind us 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” (p. 98). This statement, we believe, applies to all workplace project teams.

In this way, TCs must use workplace interactions (regardless of the type of project they work on) to promote their user advocacy. This article reflects on how promoting user advocacy in tandem with UCD/UX approaches prompted effective technical communication outcomes and positive perceptions about technical communication in the workplace. It articulates the practices and behaviors we used to promote user advocacy in three unique professional capacities: a departmental content strategist, a senior process writer, and a strategic communication consultant. It offers insightful reflections on how TCs can enhance their workplace identities by wearing what Carol Barnum (2011) calls “both hats” of technical communication and UCD/UX.

The next section addresses how we determined the key practices that helped us promote user advocacy when we explained our technical communication work to non-TCs.

Methods: An Ethnographic Perspective

This paper offers an ethnographically informed, participant-observer perspective (Adams, Holman-Jones, & Ellis, 2015; Chang, 2008; Ellis, Adams, & Bochner, 2011; McNealy, 1999) of the conditions and behaviors that helped us promote user advocacy in our work. It explains key practices we believe clarified, reestablished, disrupted, or pioneered new ways of understanding technical communication work.

Our perspectives are not contrived nor derived for the sake of research. Rather, as students of the same PhD program, common coursework afforded opportunities to study and discuss our professional experiences. These discussions invariably led to two core inquires: 1) What specific behaviors positively support our technical communication work, and 2) How do these behaviors relate to perceptions about technical communication in the workplace? Accordingly, the key practices presented here are a direct result of our personal observations, interactions, activities, dialogues, and reflections. In some cases, we reviewed individual meeting and project notes to recall what guided our interactions with non-TCs in our workplaces. Additionally, these reflections are based on recall about our interactions.

While ethnographic perspectives can be suspect in their limitations and bias (Denzin, 2003; Cross, 1994; Patton, 2002; Collings, 2009; DeWalt & DeWalt, 2010; LeCompte & Schensul, 1999), our embedded and trusted vantage point combined with UCD/UX methods afforded us ethnographic-thick description of the organizational culture, verbatim input, field notes, and contextual descriptions of our representative users (Ager, 1992; Atkinson, 2002; Emerson, Fretz, & Shaw, 1995; Fetterman, 2010). This embedded vantage point afforded us powerful casual ethnographic research (the ethnography was not the planned research design) on the inter-relationship of the stakeholders and the workplace problems (MacNealy, 1997).

Our ethnographic reflections articulate key practices that helped us conduct successful technical communication work and expand other people’s understandings of technical communication. The next section explains these key practices and the workplace contexts in which we used them.

Individual reflections and key practices to promote user advocacy

Our interactions with managers, co-workers, and clients were guided by eight key user advocacy practices. In reflecting on our experiences, we argue that TCs can benefit from interactions where they:

  1. Help stakeholders understand the benefits of good user research processes and experiences.
  2. Connect user needs to organizational goals.
  3. Articulate how content and design decisions align with known user characteristics, needs, and wants.
  4. Help stakeholders identify the root cause of perceived problems before determining and implementing a communication solution.
  5. Demonstrate how user advocacy promotes a culture of continuous improvement.
  6. Create and consistently reference a representative user identity.
  7. Discuss multiple user pathways and work processes.
  8. Frame content and design questions in a scenario- or task-based manner.

A description of the workplace contexts in which we used these key approaches and, critically, how we used them follows.

Departmental content strategist I (Nick Carrington) teach professional writing courses at a small, private, Christian university in the Midwest. Our department offers four programs of study: Communication, Broadcasting and Digital Media, Journalism, and Professional Writing and Information Design. Although there are 15 full-time faculty members in the department, only two of us teach in the professional writing program. The faculty expressed a desire to use our skills to the benefit of all four areas of study in our program. There was one problem though: They were not even sure what we did. “Don’t you write procedures?” one colleague asked. “Well, yes. But we also write lots of other workplace content,” I often explained. And, I frequently left those conversations feeling like I had spoken some indecipherable language.

One semester, our new Chair put a greater emphasis on recruiting as enrollment had dropped. The university hired an outside marketing agency to increase university enrollment. Among other conclusions, they told us that program webpages are an important part of our recruiting process. We knew this from other published scholarship already, but it was nice to confirm it through data with our intended audiences (Esrock & Leighty, 2000; Hite & Railsback, 2010; McAllister & Taylor, 2007).

As a TC, even though I was typically just viewed as a “writing teacher” by others, I knew I had the skills to upgrade our site in a meaningful, UCD/UX-informed way. I initiated an individual meeting with my Chair to discuss a complete revision of our program’s recruiting pages. Importantly, I explained the UCD/UX process that I would use to do so. The depth of user data and analysis my UCD/UX process would yield was something that had never occurred to him: information about which content and design elements would help prospective students. It seemed to compel him to give me freedom and authority to do the work I wanted. He even hoped to use the data to improve other department initiatives.

For nine months, I worked with three students to study users (Garrett, 2011), to study the problem context, and to produce a working prototype (Still & Crane, 2016). The redesign included adding visual elements for branding purposes and creating several new pages geared toward answering our user’s questions: a blog with posts written by current students about the program, alumni profiles, and a student portfolio page that displays their work. We also wrote new content for existing pages and created new pathways to link these to other valuable resources, like course descriptions in the University’s online catalog.

Three key practices that I used to promote user advocacy helped my project team, and subsequent department colleagues, understand the value of my UCD/UX-informed technical communication approach:

1. Help stakeholders understand the benefits of good user research processes and experiences: When I first explained my UCD/UX methods to non-TCs, I contrasted my proposed work with a similar project that recently failed. In a department meeting the previous spring, our Chair announced that the department had started a blog. When the faculty inquired as to why, he stated that other departments had successful blogs and as a Communication department, it “made sense” for us to have one too. It was a marketing effort geared toward external audiences, yet we had conducted zero user research and performed zero UCD/UX methods. Unsurprisingly, the blog quickly died after three posts.

When I explained my UCD/UX approach to determine what new content would go on the recruiting pages, I tactfully suggested that a lack of audience analysis and research likely led to the old blog’s failure: “We’ve only talked about implementing tactics, like the blog, without any idea as to what information our audience wants from us and how they’d like that presented.” I reiterated that UCD/UX methods would yield important information that would enable us to make effective decisions about content on the professional writing webpages. One question seemed to hit home: “We need to answer questions about purpose, topics, and a whole host of other content issues. How will we answer those without interacting with our users?”

When we launched the new recruiting pages, we did include a blog, but it was a successful one. I’ve made an effort to discuss why the new blog has thrived and the first one failed within my department. I pointed to one critical consideration: I did not start with the idea of a blog (Halvorson & Rach, 2012). That is, the blog was not a technological solution of choice simply because “other departments were doing it.” Rather, I learned through user research, observation, and testing (Garrett, 2011; Still & Crane, 2016) that prospective students desired to know what the experience was like in our program and that current students provided the best insight into that experience. This was not the case with the first blog where we had zero user information. From these conversations, our faculty grasped the importance of good user analysis and testing processes. Encouragingly, the faculty have started to consider how to implement user research approaches into other decision-making processes.

2. Connect user needs to organizational goals: From an organizational goal perspective, the department wanted to increase students. The recruiting pages were a means to this end. In conversations with faculty and the marketing and Web department, I made it a point to ask questions about user advocacy. For example, I asked: “What concerns about professional writing do prospective students have that would cause them to choose another program?”, “What information and in what forms can we present that content in order to help them make a wise decision?”, and “What made us more attractive than the other programs? What did potential students need/want to know?”

I argued that answering questions and addressing fears that students had about our programs would result in the best content to attract more students. My diligence to explicitly promote user advocacy in interactions with non-TCs offered a clearer link between the prospective students’ content needs and the goals of the communication department; if students’ information needs were met, they would not choose other programs based on misconceptions about what our major offered.

3. Articulate how content and design decisions align with known user characteristics, needs, and wants: When I presented changes to the recruiting pages to the university Web and marketing department for approval, it was critical that I explained why my team made specific decisions; I grounded my arguments for each change in user advocacy. I reviewed our UCD/UX methods and connected user research data to each content and design decision. For example, I was explicit about how specific user research findings indicated what prospective students wanted to know about the program. I presented a user question structure (Redish, 2012) to connect our content areas to user needs:

1. Information about jobs

a. What job opportunities are there in the professional writing field?
b. What is the program’s job placement rate?
c. What can I do with the major when I graduate?
d. Can I find a job with this major when I graduate?

2. Information about the student experience in the program

a. How does the course schedule work (with other minors or study abroad opportunities)?
b. What do you do in the program?
c. Is knowing good grammar and spelling important?
d. Is it a dry major (will I enjoy the coursework)?
e. What type of classes will I be taking?
f. How time consuming/hard is the program?

When I presented each prototype page, I pointed out which content and design elements met which of these user questions. For example, when I presented data that suggested prospective students want to understand what their experience would be like in the program (coursework, community, class size, co-curricular activities), I showed them the prototype of our student portfolio page. These portfolios present the work that our students create in coursework, through their internships, and by way of on-campus writing jobs. I tied this page back to some of the questions our users were asking such as “What do you do in the program”? This approach helped the Web and marketing departments understand how each content and design element was connected to user data. In turn, it was a persuasive approach because it clearly highlighted how our content would address real user needs. A marketing representative even commented that the university had other program pages that needed this kind of process and connection between content and data.

Overall, the key practices I used to promote user advocacy ultimately challenged previous notions or engendered new ways of thinking about the project and our users. After the redesign, conversations about my work within the department changed. Other faculty members inquired about the UCD/UX approaches my team used. My favorite comment was eye opening: “I didn’t know you did this kind of stuff.” Department members had new insights into what technical communication work can contribute. My Chair formally recognized me in front of my colleagues, and the project played a part in a recent promotion I received.

Professionals in other fields have long dictated the value of a TC’s work (Rice-Bailey, 2016). Many times, non-TCs misunderstand the TC’s skillset. As such, TCs need to consistently find ways to create or shift their workplace identities. For me, the opportunity arose at a regular faculty meeting; I had the confidence to volunteer to lead a major UCD/UX technical communication project. While this was beyond my job description, I knew I could not idly let technology-centered design (i.e.: “we’re starting a blog”) trump the meaningful work that I, a TC, could do.

Workplace senior process writer My (Nancy Muncie’s) immersion into the corporate world began as a Senior Technical Writer in a Project Engineering department at a large aerospace company. After nearly two decades in education as an English teacher and writing specialist, I made a career change to industry in 2011. Recently, the Corporate Communications department of my employer contacted me about a “problem” with workforce email writing. Because I was the Senior Technical Writer and the group believed this to be a training issue—an opportunity to align my teaching background, writing instruction pedagogy, and technical communication skillset arose.

Tasked with designing a training module to “teach appropriate and professional email etiquette” to the workforce, I considered approaching the problem from a curriculum-by-design methodology (Wiggins & McTighe, 1998). However, as a TC embedded in the organization, I knew, and research supports (see Beer & Nohria, 2001; Kanter, 1983; Reingold & Yang, 2007; Stein, 2010), that perceived problems are a recipe for the knee-jerk “change something” reaction. Management’s quick call to implement a new training module was a prime example of this problem. Rather than develop an arbitrary set of training slides (the standard approach), I used a UCD/UX approach to ensure the training module design met the writing and communication needs of the employees for whom it was intended. My UCD/UX project utilized research tools such as a project proposal, surveys, interviews, site visits, and prototype development (Still & Crane, 2016).

I achieved buy-in to my UCD/UX methods through key practices where I promoted user advocacy to reframe the cause of poor email writing. This, in turn, resulted in an awareness of and openness to user-provided solutions. Based on the advice of Barnum (2011), the point was to “focus on the user(s), not [on] the product” (p. 10) to achieve meaningful change for all stakeholders. I had to articulate the value of this approach to non-TCs who seemingly did not care about how I was going to produce the new training module. They were only interested in what I produced. To promote my UCD/UX approach, I framed my strategy in the language of project management.

Accordingly, I negotiated management away from their predetermined approach: to design training slides addressing unprofessional tone, incorrect grammar, spelling and punctuation errors, lack of contact information, disregard for chains-of-command, misuse of Reply All, and use of individual slogans and euphemisms. To secure buy-in for my UCD/UX approach, I presented a formal project proposal that outlined these methods in terms of resource allocation, Gantt charts, milestones, and objectives to improve the bottom-line by reducing the rework and inefficiency resulting from poorly written emails. Management agreed to my UCD/UX approach, and the project ended in a successful roll-out of the training. Two key practices made the difference in this project:

1. Help stakeholders identify the root cause of perceived problems before determining and implementing a solution: For this project, management felt strongly, despite having no data or first-hand knowledge, that the cause of the email problems was a lack of training. Accordingly, I grounded my inquiries in actual user impacts when discussing the project with management. Posing questions from a representative user perspective, I asked, for example, “How will Brenda from second shift benefit from this lunchtime training format?”, “Let’s think about John in Production. Is it fair to say he has better ways to spend his time than double-checking his spelling in an email?”

Critically, I linked these user considerations to common organizational concerns: “Does that have a safety implication?”, “If John spends a little more time in proofreading, might this prevent a milestone slipping due to misunderstanding?” These conversations in turn helped change understandings of what needed to be taught, how it should be taught, and why a UCD/UX approach was the best solution.

Ultimately, I framed the need to focus on the users—the workforce—to develop the training as risk mitigation. I used my teaching experience and technical communication knowledge to advocate that expensive training initiatives designed without input from the users would likely fail. Fortunately, management trusted my judgment when I connected user considerations to the bottom line. I focused on my user analysis data during project updates with management. Site visits and user-testing (Garrett, 2011; Still & Crane, 2016), for example, revealed a very different root cause to the email problem than management perceived. Capturing the impacts of what user data showed were the real problems in terms of quantifiable time-off-task in comparison to noticed improvements post-training resulted in buy-in of my UCD/UX approach. It helped me persuade management of increased earned value and positive budget impacts that result from a training targeted to what user data shows is the root cause.

2. Demonstrate how user advocacy promotes a culture of continuous improvement: Through my work, I could demonstrate that UCD/UX methods ensures that both trainings and corresponding documents can minimize the time employees take to repeat instructions, demonstrate procedures, and explain routine work processes every time there is a new hire or restructuring.

In my work to help employees reap the benefits of user-centered documents, for example, I convinced a few subject matter experts (SMEs) to track the frequencies and types of questions they were asked about specific company documents and time needed to handle them. This tracking confirmed that new, user-centered documents reduced the time SMEs spent answering questions and training new hires by 63%. Accordingly, I could quantify the positive organizational impact of my technical communication work.

Conversations about the bottom-line impacts (easily quantified in terms of time-on-task vs. time supporting others) stemming from the workforce’s efforts to improve documentation got leadership’s attention. This resulted in my increased visibility and influence as a TC—and more importantly—the value of technical communication work within the organization. Word has traveled about my UCD/UX technical communication approach, though non-TCs do not formally call it such. Rather, they understand that my technical communication work places their work, input, and professional interests at the center of the problem-solving approach. User considerations now inform their process improvement strategies. Overall, the key practices I used to promote user advocacy shifted my identity from being “an effective partner” (Rice-Bailey, 2016) to an essential one when solving problems at work.

My technical communication work, once considered “nice-to-have,” is now viewed as necessary. Leadership began seeing how a TC can improve bottom-line savings through standardized, transparent documentation, more productive meetings and trainings that are well-attended, and meaningful exchanges of information that do not require management attendance or oversight. I have also been asked to develop more training due to management’s endorsement of my technical communication approach. Now, I am viewed as a different and more influential asset than before. My interactions and negotiations with non-TCs during this project did not just result in a successful deliverable; they resulted in a greater appreciation of how I, a TC, am integral to researching and designing the right solutions for the right problems.

Strategic communication consultant My (Sarah Martin’s) reflection draws from a consulting role I held as the Assistant Director of Strategic Communication for a large government organization. I reported to the Director of Strategic Communication, also a consultant, and we represented the only TCs in the organization. The organization’s lack of experience with TCs was both a gift and a challenge.

As a gift, non-TCs had few preconceived notions about what we should do, and why or how we did it. As a challenge, non-TCs had few preconceived notions about what we should do, and why or how we did it. In other words, nobody seemed to care what the TCs were doing; they did not see how a TC directly added value to what they did. From their perspective, non-TCs managed the work processes and products of the organization; TCs managed the resulting derivative communication of these activities.

It was clear that overtly attempting to alter non-TC perceptions either about technical communication being “one of those soft skills” or the responsibility of “people who write manuals in China” (real statements from non-TCs in the organization) would not be fruitful. Luckily, something better happened. As my team worked on different communication initiatives—content strategy, document development, and website design—non-TCs began to see clear connections to how our technical communication work positively impacted employees and external stakeholders. They started to reframe technical communication from an afterthought exercise to fix, clarify, or transmit information (Slack, Miller, & Doak, 2004) to a means to better manage the organization itself (Longo, 2000).

For example, non-TCs credited our technical communication work with three primary achievements: decreases in policy inquiries from both employees and stakeholders, enhanced work practices due to more user-centered internal work documents, and an improved understanding about the organization’s mission from user-centered public documents.

The shift in the organization’s perception of technical communication work was, in part, I believe, due to specific key practices that I used to promote user advocacy during non-TC interactions. Promoting user advocacy in these three ways allowed me to successfully conduct technical communication work and foster support from non-TCs:

1. Create and consistently reference a representative user identity: A core UCD/UX practice is to develop a representative user identity that establishes a user’s needs, values, and behaviors (Barnum, 2011; Dumas & Redish, 1999; Krug, 2014; Rubin, Chisnell, & Spool, 2008; Still & Crane, 2016). This practice provides a system of checks and balances for content, feature, and process decisions; decisions are grounded in user benefits, rather than a TC’s or non-TC’s preferences as the user profile is consulted.

Cooper (2004) notes how referencing user profiles during design discussions can in turn lessen tensions among group members when making content and design decisions. It helps TCs tie their rationale for content and design decisions back to user needs. For example, if a TC suspects that content or a process may be confusing, he or she may simply inquire, “What if Sally accidentally clicked here?” or “What if Sally calls this term that instead?” This approach of referencing a representative user identity detaches the issue from a TC misunderstanding or not “getting it” and recasts the issue to be resolved for the user’s benefit. One example of how I used this approach was during a contentious meeting with a SME about technical terminology in a congressional document meant for public access. I simply asked, “How would you explain that to your neighbor?” By referencing a particular user group, the general public framed as a neighbor, the SME better grasped the need to adapt the terminology for fear of the user missing the point of the paragraph. This approach positioned me as a user advocate rather than a bothersome “translator” (Slack, Miller, & Doak, 2004) there to make sense of technical terminology. Importantly, the SME noted that framing content in ways that non-experts could understand would help him with other workplace projects. He specifically told me that he was going to use this approach to prepare a report for an upcoming congressional meeting.

2. Discuss multiple user pathways and work processes: Regardless of who the representatives users are, TCs must also consider how users work. This means observing and analyzing user pathways and work processes (Barnum, 2011; Dumas & Redish, 1999; Krug, 2014; Rubin, Chisnell, & Spool, 2008; Still & Crane, 2016). In my discussions with SMEs or non-TC managers, I consistently talked about how someone might access certain content. So, instead of simply personally asking, “Which button do I click to find that?”, I asked a series of questions such as: “If Joe were on the Homepage, how would he locate that?”, “How many times must Joe click to find it?”, or “Can someone new or external to the organization locate this?” Framing these questions in ways that placed users, not myself, as the inquiring party kept potential accusations of “You’re not doing it right; engineers do it this way” at bay. If there was a problem accessing information, the non-TCs could tie it into something related to a specific user profile rather than me, the TC, simply not understanding their domain.

When possible, I worked with the SME to observe users directly. Having the SME in the room during this process kept the focus on the users and their work patterns; I was not a TC “mimicking” other’s work, which might result in a SME retort of, “Well that’s not how they do it anyway.” Having the SME present during user observations also led to rich discussions about the user’s work patterns. The SME was often surprised by how differently or with what difficulty or ease users accessed information. Discussing our findings about multiple user pathways and work processes together was very effective. In short, while I was not required to have the SME present, inviting him to user observation sessions yielded positive outcomes—both for the project and our TC/non-TC interactions.

3. Frame content and design questions in a scenario or task-based manner: Scenario or task-based user observations are a core UCD/UX practice (Barnum, 2011; Dumas & Redish, 1999; Garrett, 2011; Krug, 2014; Rubin, Chisnell, & Spool, 2008; Norman, 2013; Still & Crane, 2016). As such, I always provided a specific scenario or use-context when I presented my work to non-TCs. For example, I explained the conditions and process by which a regional manager, headquarters employee, congressional representative, and customer might access and use the same information differently under various circumstances. By discussing multiple user tasks and scenarios, the management team saw a greater need to consider how employees and stakeholders accessed information differently and for which purposes. They were motivated to provide information that met different user needs and was easily accessible to employees so they could properly conduct their work.

Importantly, framing my content and design recommendations in a scenario or task-based manner helped articulate how user needs impacted broader organizational processes and outcomes. By promoting user advocacy, management became aware of how a particular set of policy content impacted internal and external stakeholders differently. The same content, with different use and access challenges, created tension between internal and external stakeholders. Internal stakeholders were frustrated that external stakeholders were not providing correct information. External stakeholders were frustrated that the organization seemed indifferent about getting them accurate information to correctly do their work. The result of this tension was a formal congressional inquiry and government review of the organization’s work, which impacted morale and their broader organizational processes and achievements.

To address this content issue with management, I framed my problem-solving approach in user advocacy. Management was very receptive to questions such as: “What are the different circumstances where people might use this information?”, “Why will certain people access this information?”, “What will they use it for?”, and “How will they access it?” Managers were eager to share their personal knowledge about these scenario or task-based questions. Once they reflected on different use contexts, it sparked lively conversations and many managers jumped in to share their experiences; it also helped them think through situations—seemingly obvious ones—that they hadn’t even considered before. The scenario or task-based questions were a departure from general and transactive planning questions such as: “Who will revise this document?”, “How long will it take?”, and “Who will notify people that the document is revised?”

Overall, the key practices I used to promote user advocacy lessened tensions and built rapport and mutual respect among our two-person technical communication team, management, and SMEs. Importantly, promoting user advocacy took the attention off me as the TC trying to understand their sacred technical knowledge. Rather, it positioned me as an advocate for both users and management. Non-TCs saw that my questions and methods were always grounded in helping someone other than myself understand their technical knowledge. In turn, non-TCs also saw me as advocating for them because I actively mined more than their technical expertise: I treated them as user-experts and probed their knowledge of user values and behaviors. They became most animated when I engaged in conversations about scenario or task-based behaviors—it represented their technical knowledge at work, after all.

Promoting user advocacy when I explained my work helped demonstrate how technical communication work practices result in organizational value (Dubinsky, 2004; Halvorson & Rach, 2012; Johnson-Eilola, 2004). Perceptions of my work shifted. It was not about me as a TC doing work for an organization; it was about what a TC could do for the organization. This was possible through the three key practices described above.

Promoting User Advocacy to Shift Technical Communication Identity

While it can be bothersome when non-TCs are unsure about what we do, it is also opportune. We, as TCs, have the opportunity to reimagine and articulate what TCs are capable of through our workplace interactions. In our situations, promoting user advocacy through eight key practices helped us do so. These practices offered rationales to defend the content, design, and process decisions that govern our technical communication work. In turn, these practices helped alter pedestrian understandings of TCs as simply people who “fix” or “add to” existing work products.

Table 1 summarizes the key practices and associated application strategies that we used to promote user advocacy.

Table 1. Key Practices and strategic application to promote user advocacy

Key Practice
Strategic Application Prompting Questions/Statements
1. Help stakeholders understand the benefits of good user research processes and experiences.
  • Look for opportunities to lead unconventional technical communication projects; demonstrate how they are a technical communication issue.
  • Explain the UCD/UX problem-solving approach you will use with management rather than solely present recommendations.
  • “Because of the UX/UCD process I intend to use, I believe we will achieve better results than past attempts to accomplish similar goals.”
  • “I believe my skills in user advocacy will be an asset to the organization on this new project.”
2. Connect user needs to organizational goals.
  • Ask other stakeholders questions that will connect user advocacy to measurable objectives, such as increased student enrollment or a rise in newsletter subscriptions.
  • Articulate the connections between user testing results and conclusions with clear benefits to the organization.
  • “What information helps a prospective student decide on a major?”
  • “Because of our user tests and training, users suggested they have a better understanding of the company’s writing expectations, and they can more effectively communicate with internal and external stakeholders.”
3. Articulate how content and design decisions directly align with known user characteristics, needs, and wants.
  • Explicitly connect product features or recommendations to strategy formed through user testing.
  • When you make a specific recommendation, explain which user need it addresses.
  • “Prospective students want to know what their coursework will look like. To address this, we created a student portfolio page that showed current students classroom work.”
  • “We wanted to effectively communicate the special community within our program, so we have current students writing blog posts about that topic.”
4. Help stakeholders identify the root cause of perceived problems before determining and implementing a communication solution.
  • Explain the conditions and processes by which various users will access and use different information.
  • Before embarking on a solution, discuss the problem with other stakeholders in terms of user impacts.
  • Tie user information to organizational concerns, such as safety measures or financial goals.
  • “How will Brenda from second shift benefit from this lunchtime training format?”
  • “Let’s think about John in Production. Is it fair to say he has better ways to spend his time than double-checking his spelling in an email?”
  • “By figuring out and addressing the root of the problem through UX/UCD methods, we can help our employees work more efficiently.”
5. Demonstrate how user advocacy promotes a culture of continuous improvement.
  • Use quantifiable data to connect technical communication work to the organization’s bottom line.
  • Invite stakeholder groups to measure and reflect on how specific communication changes impact their work; use this information to make iterative enhancements.
  • “We can use metrics like time-on-task data to show how workers are remaining effective while being more efficient.”
  • “If we continually collect user data, we can make appropriate changes more often to improve our productivity and effectiveness.”
6. Create and consistently reference a representative user identity.
  • Present user profiles to stakeholders so they are familiar with the user group you are trying to help.
  • Reference user profiles when explaining or recommending design decisions.
  • “How would you explain that to a public customer?”
  • “How would a government representative handle the same information?”
7. Discuss multiple user pathways and work processes.
  • When discussing project decisions with SMEs, frame questions in ways that place users as the inquiring party.
  • Invite SMEs and other stakeholders to observe user testing and discuss findings directly with them.
  • “If Joe were on the homepage, how would he locate that?”
  • “We could use your expertise in watching and analyzing our user testing.”
8. rame content and design questions in a scenario- or task-based manner.
  • Provide specific scenarios of use contexts that give stakeholders a clearer picture of the larger situation.
  • Ask questions about how different users might interact with a feature or piece of content under different circumstances.
  • “If Chris needed to access this information via her mobile phone, what menu item should she look for?”
  • “What about if she (Chris) needed to edit the information and encrypt it before sending it to a client?”

Our reflections suggest TCs must not rely solely on what they do to prove their value. Their value also depends on how they communicate their work to non-TCs and situate that work within larger organizational contexts. If we expect our work to “speak for itself,” we run the risk of non-TCs continuing to devalue and misunderstand our contributions and cast us into support roles (Johnson-Eilola, 2004; Slack, Miller, & Doak, 2004). While individual TCs may communicate the value of their work differently, the practices described in this article offer perspectives to those struggling to make their value known to their non-TC colleagues.

This study contributes to scholarship on and can help TCs think about new ways to promote their identity and value (Baehr, 2015; Bloch, 2011; Brady & Schreiber, 2013; Dannels, 2000; Redish, 2003; Rice-Bailey, 2016; Savage, 2003; St.Amant & Meloncon, 2016; Walton, 2013; Wilson & Ford, 2003). For example, TCs may often spend their persuasive energies touting the benefits of various principles: clear language, omission of technical jargon, proper information design, or appropriate content strategy. While these approaches may sometimes work, they are not always clearly linked to user advocacy. That is, stating that “information design tells us not to use white text on a blue background” is different from presenting user testing results that show zero users could read an important paragraph.

Our reflections can also help TCs become more comfortable explaining their work. As Rice-Bailey (2016) notes:

Being asked to describe their roles and competencies can leave the TC with feelings of uncertainty and anxiety. Frequently, the term technical communicator is not well understood in the workplace, and it is difficult for many TCs to fully expound upon their roles and the competencies they bring to the workplace. (p. 231)

While other scholars have explored the challenges TCs have in articulating their work and value (Anschultz & Rosenberg, 2002; Bias & Mayhew, 2005; Dicks, 2010; Faber & Johnson-Eilola, 2003; Redish, 2003; Savage, 2003), we suggest that grounding technical communication approaches and decisions in user advocacy relieves some of these pressures. These key practices can help TCs who might feel like they consistently must find the “right” way to “explain” or “convince” (Brady & Schreiber, 2013) others that their work adds value.

Additionally, this study addresses practitioner concerns that technical communication theories and principles be communicated in non-academic terminology. As one example, a TC in St.Amant and Meloncon’s (2016) study remarked that, “Research must be reported in terms that practitioners, not familiar with the esoterica of the academic field, can nonetheless glean useful principles and guidelines” (sec. 3, para. 14). Our reflections demonstrate how TCs can promote user advocacy in plain terms: what, when, where, why, and how will user X do Y or Z?

Lastly, this study suggests ways for TCs to have more positive interactions with non-TCs. Positive interactions between TCs and SMEs matter greatly. As Rice-Bailey (2016) notes:

When TCs and SMEs are seen as effective partners, there is an increased likelihood that TCs will be regarded as valuable team members and will be increasingly called upon to assist with project work, thus raising the overall station of TCs within the organization. (p. 230)

In reflecting on her corporate technical communication work, Rice-Bailey (2016) also notes that SMEs, or non-TCs, determined the “ease or difficulty” (p. 230) with which she could complete her work. In this way, a TC’s relationship to non-TCs can be both enabling and constraining. We suggest that the eight key practices to promote user advocacy presented here have much to do with reaching an enabling relationship.


The eight key practices we used to promote user advocacy resulted in three critical outcomes: 1) new understandings of technical communication work, 2) clearer links between our work and broader organizational value, and 3) more positive professional identities. We improved our workplace identities and value not solely because we did our jobs well. It was, we believe, because we effectively communicated how our problem-solving approach impacts users. Critically, promoting user advocacy brought us into larger and broader management conversations and activities well beyond our standard job descriptions (Hart & Conklin, 2006; Rice-Bailey, 2016). Using these eight key practices helped us raise the visibility and value of our technical communication work (Brady & Schreiber, 2013; Rice-Bailey, 2016).

Part of understanding the TC’s identity is to explore his or her role and value as perceived by both the TC and those with whom the TC interacts. Slack (2004) suggests we tell stories about our individual contexts. The purpose of these stories (including ours) has less to do with defining what TCs ought to be. In these stories, we describe what methods and processes help individual TCs create a positive identity and enhance their workplace influence. While our study offers three ethnographic perspectives, it is limited, as is all experience, by our own perceptions and workplace cultural knowledge. From a social constructionist perspective, our study is based on our individual attempts to account from our own experiences (Gergen, 1985; 1999) of how to promote user advocacy when conducting technical communication work. Additionally, our perceptions about how non-TCs more positively viewed us and our work were not quantitatively measured. They were based on observed behavioral implications and personal experience: public recognition, promotions, requests for additional work and work on broader organizational problems, and adoption of UCD/UX approaches or data to inform non-technical communication problems.

Future studies might formally measure how certain attributes, professionalization, for example, impact perceptions of TCs. Professionalization—the process by which worker groups achieve professional status (Evetts, 2013)—broadens understandings of particular workers’ professionalism. For example, historically female-dominated occupational groups, such as midwifery, have benefitted from professionalization (Bourgeault, Benoit, & Davis-Floyd, 2004). Yet, professionalization is not terminal; it is dynamic. Formal (or perceived) loss of control, or “jurisdiction” (Abbott, 2014), over technical expertise or responsibilities associated with power can result in de-professionalization. For example, Andrews and Wærness (2011) found that public health nurses experienced de-professionalization as their roles became more circumscribed by higher authorities. In turn, their community influence waned as their duties became less influential and respectable. More so, Evetts (2013) explains how professionalism, particularly its ideology, has power:

The ideology of professionalism that is so appealing to occupational groups and their practitioners includes aspects such as exclusive ownership of an area of expertise and knowledge, and the power to define the nature of problems in that area as well as the control of access to potential solutions. It also includes an image of collegial work relations of mutual assistance and support rather than hierarchical, competitive or managerialist control. (p. 788)

Accordingly, technical communication scholarship can benefit from future studies that measure how TCs (and non-TCs) perceive, for example, a TC’s power in defining the nature of current work problems or his or her access to solutions and resources.

As professional practices and occupations change (Abbott, 2014; Drucker, 1992, 1969; Evetts, 2013, 2003), it’s important to consider the structural, economic, and demographic forces that influence these changes (Abbott, 2014). Accordingly, it would also be useful to explore how TCs create shared professional values as new technologies and work patterns take shape. As Abbott (2014) notes, professional jurisdictions are “determined by both [workers’] own activity defining the jurisdiction and by the social and cultural context within which they work” (p. 217). As far as defining professional jurisdictions, shared professional values—common experiences, expertise, and problem-solving approaches—can strengthen the construction and perception of professional identities and workplace value (Boussard, 2008; Dubar & Tripier, 1998; Evetts, 2013). As such, technical communication scholarship can benefit from more formal studies of professionalization in shifting workplace contexts.

We hope this study and future similar studies motivate TCs to adopt these key practices or promote user advocacy in new ways. As Rice-Bailey (2016) warns:

If TCs do not or cannot articulate their value, there is a likelihood they will be seen as a nuisance to the SMEs, unnecessary to the product development and implementation process, or simply expendable “overhead” to the department and organization. (p. 240)

TCs should view every workplace interaction where they do not explicitly promote user advocacy as “lost opportunities…to prove their value and be seen as leaders in organizations” (Rice-Bailey, 2016, p. 241). As such, our primary conclusion is this: A TC’s value is reciprocal to his or her explicit promotion of user advocacy. This study offers eight key practices to help TCs achieve just that.


Abbott, A. (2014). The system of professions: An essay on the division of expert labor. Chicago, IL: University of Chicago Press.

Adams, T., Holman-Jones, S., & Ellis, C. (2015). Autoethnography: Understanding qualitative research. New York, NY: Oxford.

Andersen, R. (2014). Rhetorical work in the age of content management: Implications for the field of technical communication. Journal of Business and Technical Communication, 28, 115–157.

Andrews, T., & Wærness, K. (2011). Deprofessionalization of a female occupation: Challenges for the sociology of professions. Current Sociology, 59(1), ٤٢–٥٨.

Anschultz, L., & Rosenberg, S. (2002). Expanding roles for technical communicators. In B. Mirel & R. Spilka (Eds.), Reshaping technical communication: New directions and challenges for the 21st century (pp. 149–163). Mahwah, NJ: Lawrence Erlbaum.

Baehr, C. (2015). Complexities in hybridization: Professional identities and relationships in technical communication. Technical Communication, 62, 104–117.

Barnum, C. (2011). Usability testing essentials: Ready, set…test! Burlington, MA: Morgan Kaufmann.

Beer, M., & Nohria, N. (2001). Resolving the tension between theories E and O of Change. In M. Beer & N. Nohria (Eds.), Breaking the code of change (pp. 1–34). Boston, MA: Harvard Business School Press.

Bias, R., & Mayhew, D. (2005). Cost-justifying usability: An update for the internet age. San Francisco, CA: Morgan Kaufmann.

Blakeslee, A., & Savage, G. (2013). What do technical communicators need to know about writing? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 362–385). Chicago, IL: University of Chicago Press.

Bloch, J. (2011). Glorified grammarian or versatile value adder? What internship reports reveal about the professionalization of technical communication. Technical Communication, 58, 307–327.

Bourgeault, I., Benoit, C., & Davis-Floyd, R. (2004). Reconceiving midwifery. Quebec: McGill-Queen’s Press.

Boussard, V. (2008). Sociologie de la gestion: Les faiseurs de performance. Paris: Belin.

Brady, M., & Schreiber, J. (2013). Static to dynamic: Professional identity as inventory, invention, and performance in classrooms and workplaces. Technical Communication Quarterly, 22, 343–362.

Britt, E. (2007). The rhetorical work of institutions. In. J. Scot, B. Longo, & W. Wills (Eds.), Critical power tools: Technical communication and cultural studies (pp. 133–150). Albany, NY: SUNY Press.

Ceraso, A. (2013). How can technical communicators plan for users? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 237–261). Chicago, IL: University of Chicago Press.

Conklin, J. (2007). From the structure of text to the dynamic of teams: The changing nature of

technical communication practice. Technical Communication, 54, 210–231.

Cooper, A. (2004). The inmates are running the asylum. Indianapolis: Sams.

Coppola, N. (2012). Professionalization of technical communication: Zeitgeist for our age introduction to this special issue (Part 2). Technical Communication, 59, 1–7.

Dannels, D. (2000). Learning to be professional: Technical classroom discourse, practice, and professional identity construction. Journal of Business and Technical Communication, 14, 5–37.

DeWalt, K., & DeWalt, B. (2010). Participant observation: A guide for fieldworkers. Walnut Creek, CA and New York, NY: AltaMira.

Dicks, R. (2013). How can technical communicators manage projects? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 310–332). Chicago, IL: University of Chicago Press.

Dicks, R. (2010). The effects of digital literacy on the nature of technical communication work. In R. Spilka (Ed.), Digital literacy for technical communication (pp. 51–81). New York, NY: Routledge.

Drucker, P. (1992). The new society of organizations. Harvard Business Review, September-October, 95–104.

Drucker, P. (1969). The age of discontinuity: Guidelines to our changing society. New York: Harper’s.

Dubar C., & Tripier, P. (1998). Sociologie des professions. Paris: Armand Colin.

Dubinsky, J. (2004). Teaching technical communication: Critical issues for the classroom. Boston, MA: Bedford St. Martin’s.

Dumas, J., & Redish, J. (1999). A practical guide to usability testing. Portland: Intellect Books.

Ellis, C., Adams, T., & Bochner, A. (2011). Autoethnography: An overview. Forum: Qualitative Social Research, 12(1).

Esrock, S., & Leighty, G. (2000). Organization of corporate web pages: Publics and functions. Public Relations Review, 327–344.

Evetts, J. (2013). Professionalism: Value and ideology. Current Sociology, 61(5–6), 778–796.

Evetts, J. (2003). The sociological analysis of professionalism: Occupational change in the modern world. International Sociology, 18(2), 395–415.

Faber, B., & Johnson-Eilola, J. (2003). Universities, corporate universities, and the new professionals: Professionalism and the knowledge economy. In T. Kynell-Hunt & G. J. Savage (Eds.), Power and legitimacy in technical communication series: Vol. I. The historical and contemporary struggle for professional status (pp. 209–234). Amityville, NY: Baywood.

Garrett, J. (2011). The elements of user experience: User-centered design for the web and beyond. Berkeley, CA: New Riders.

Gergen, K. (1999). An invitation to social construction. London, UK: Sage.

Gergen, K. (1985). The social constructionist movement in modern psychology. American Psychologist, 40, 266–275.

Grabill, J. (2007). The study of writing in the social factory: Methodology and rhetorical agency. In. J. Scot, B. Longo, & W. Wills (Eds.), Critical power tools: Technical communication and cultural studies (pp. 151–170). Albany, NY: SUNY Press.

Halvorson, K., & Rach, M. (2012). Content strategy for the web. Berkeley: New Riders.

Hart, H., & Conklin, J. (2006). Toward a meaningful model of technical communication. Technical Communication, 53, 395–415.

Hart-Davidson, W. (2013). What are the work patterns of technical communication? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 50–74). Chicago, IL: University of Chicago Press.

Henning, T., & Bemer, A. (2016). Reconsidering power and legitimacy in technical communication: A case for enlarging the definition of technical communicator. Journal of Technical Writing and Communication, 46, 311–341.

Henry, J. (2006). Writing workplace cultures—technically speaking. In. J. Scot, B. Longo, & W. Wills (Eds.), Critical power tools: Technical communication and cultural studies (pp. 199–218). Albany, NY: SUNY Press.

Herndl, C., Fennell, B., & Miller, C. (1991). Understanding failures in organizational discourse: The accident at Three Mile Island and the shuttle Challenger disaster. In C. Bazerman and J. Paradis (Eds.), Textual dynamics of the professions (pp. 279–305). Madison, WI: University of Wisconsin Press.

Hite, N., & Railsback, B. (2010). Analysis of the content and characteristics of university websites with implications for web designers and educators. Journal of Computer Information Systems, 107–113.

Johnson-Eilola, J. (2004). Relocating the value of work: Technical communication in a post-industrial age. In J. Johnson-Eilola & S. Selber (Eds.), Central works in technical communication (pp. 175–192). New York, NY: Oxford University Press.

Johnson-Eilola, J., & Selber, S. (2013). Solving problems in technical communication. Chicago, IL: University of Chicago Press.

Jones, N., Moore, K., & Walton, R. (2016). Disrupting the past to disrupt the future: An antenarrative of technical communication. Technical Communication Quarterly, 25, 211–229.

Kanter, R. (1983). The change masters. New York, NY: Simon & Schuster.

Kimball, M. (2015). Training and education: Technical communication managers speak out. Technical Communication, 62, 135–145.

Knievel, M. (2006). Technology artifacts, instrumentalism, and the humanist manifestos: Toward an integrated humanistic profile for technical communication. Journal of Business and Technical Communication, 20, 65–86.

Krug, S. (2014). Don’t make me think, revisited: A common sense approach to web usability. San Francisco, CA: New Riders.

LeCompte, M. D., & Schensul, J. J. (1999). Designing and conducting ethnographic research, Vol. 1 Ethnographer’s Toolkit. Walnut Creek, CA: AltaMira.

Longo, B. (2000). Spurious Coin: A history of science, management, and technical writing. Albany, NY: SUNY Press.

MacNealy, M. S. (1997). Toward better case study research. IEEE Transactions on Professional Communication, 40, 182–196.

McAllister, S., & Taylor, M. (2007). Community college web sites as tools for fostering dialogue. Public Relations Review, 33, 230–232.

McNealy, M. (1999). Strategies for empirical research in writing. New York, NY: Longman.

Mirel, B. (2013). How can technical communicators evaluate the usability of artifacts? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 285–309). Chicago, IL: University of Chicago Press.

Norman, D. (2013). The design of everyday things. New York, NY: Basic Books.

Pace, R. (1988). Technical communication, group differentiation, and the decision to launch the space shuttle Challenger. Journal of Technical Writing and Communication, 18, 207–220.

Patton, M. Q. (2002). Qualitative research and evaluation methods. 3rd edition. Thousand Oaks, CA: Sage.

Redish, J. (2012). Letting go of the words: Writing web content that works. Waltham, MA: Morgan Kaufmann.

Redish, J. (2010). Technical communication and usability: Intertwined strands and mutual influences. IEEE Transactions on Professional Communication, 53, 191–200.

Redish, J. 2003). Adding value as a professional technical communicator. Technical Communication, 50, 505–518.

Redish, G., & Barnum, C. (2011). Overlap, influence, intertwining: The interplay of UX and technical communication. Journal of Usability Studies, 6(3), 90–101.

Reingold, J., & Yang, J. (2007). The hidden workplace. Fortune. Retrieved from http://archive.fortune.com/magazines/fortune/fortune_archive/2007/07/23/100135706/index.htm

Rice-Bailey, T. (2016). The role and value of technical communicators: Technical communicators and subject matter experts weigh in. Technical Communication Quarterly, 25, 230–243.

Rubin, J., Chisnell, D, & Spool, J. (2008). Handbook of usability testing: How to plan, design,) and conduct effective tests. Indianapolis, IN: Wiley.

Rude, C. (2009). Mapping the research questions in technical communication. Journal of Business and Technical Communication, 23, 174–215.

Rutter, R. (2004). History, rhetoric, and humanism: Towards a more comprehensive definition of technical communication. In. J. Johnson-Eilola & S. Selber (Eds.), Central works in technical communication (pp. 20–34). New York, NY: Oxford University Press.

Savage, G. (2003). Toward professional status in technical communication. In T. Kynell-Hunt & G. Savage (Eds.), Power and legitimacy in technical communication series: Vol. I: The historical and contemporary struggle for professional status (1–14). Amityville, NY: Baywood.

Schriver, K. (2013). What do technical communicators need to know about information design? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 386–427). Chicago, IL: University of Chicago Press.

Selzer, J. (2004). The composing process of an engineer. In. J. Johnson-Eilola & S. Selber (Eds.), Central works in technical communication (pp. 317–324). New York, NY: Oxford University Press.

Slack, D. (2004). The technical communicator as author? A critical postscript. In T. Kynell-Hunt & G. Savage (Eds.), Power and legitimacy in technical communication series: Vol. I: The historical and contemporary struggle for professional status (pp. 193–207). Amityville, NY: Baywood.

Slack, J., Miller, D., & Doak, J. (2004). The technical communicator as author: Meaning, power, and authority. In. J. Johnson-Eilola & S. Selber (Eds.), Central works in technical communication (pp. 160–174). New York, NY: Oxford University Press.

Spinuzzi, C. (2013). How can technical communicators study work contexts? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 262–284). Chicago, IL: University of Chicago Press.

St.Amant, K., & Meloncon, L. (2016). Reflections on research: Examining practitioner perspectives on the state of research in technical communication. Technical Communication, 63, 346–364.

Stein, N. (2000). Winning the war to keep top talent. Fortune. Retrieved from http://archive.fortune.com/magazines/fortune/fortune_archive/2000/05/29/280655/index.htm

Still, B., & Crane, K. (2016). Fundamentals of user-centered design. Boca Raton, FL: CRC Press.

Walton, R. (2013). How trust and credibility affect technology-based development projects. Technical Communication Quarterly, 22, 85–102.

Wiggins, G., & McTighe, J. (1998). Understanding by design. Columbus, OH: Prentice Hall.

Wilson, G., & Ford, J. (2003). The big chill: Seven technical communicators talk ten years after their master’s program. Technical Communication, 50, 145–159.

Wilson, G., & Wolford, R. (2017). The technical communicator as (post-postmodern) discourse worker. Journal of Business and Technical Communication, 31, 3–29.

Winsor, D. (2004). Engineering writing/writing engineering. In. J. Johnson-Eilola & S. Selber (Eds.), Central works in technical communication (pp. 341–350). New York, NY: Oxford University Press.

Winsor, D. (1990). The construction of knowledge in organizations: Asking the right questions about the Challenger. Journal of Business and Technical Communication, 4, 7–20.

Wysocki, A. (2013). What do technical communicators need to know about new media? In J. Johnson-Eilola & S. Selber (Eds.), Solving problems in technical communication (pp. 428–453). Chicago, IL: University of Chicago Press.

About the Authors

Sarah Martin is a Research Assistant and PhD candidate in the Technical Communication and Rhetoric program at Texas Tech University. Her research interests include user-centered design, business and technical communication, and strategic management. She has an MBA from the Naval Postgraduate School. Contact: Sarah.E.Martin@TTU.edu

Nick Carrington is an Assistant Professor at Cedarville University where he teaches professional writing courses. He is also completing his PhD at Texas Tech University in Technical Communication and Rhetoric. His main research interests include professional writing pedagogy, content strategy, and user experience. Contact: ncarrington@cedarville.edu

Nancy L. Muncie, a PhD candidate at Texas Tech, works as a Technical Communicator/Analyst in the aerospace industry. After teaching English and composition for 20 years, Nancy shifted her pedagogical focus to the workplace, where she continues to explore the ways UCD writing and writing instruction can help manage information and knowledge. Her research examines the influence and value technical communicators may offer the workplace when their skillset includes pedagogical knowledge. Contact: Nancy.L.Muncie@TTU.edu

Manuscript received 15 January 2017, revised 29 March 2017; accepted 10 April 2017.