In my role as a reviewer of department communications, I recently edited a document of brief project status reports. One project’s information contained a line like this:

Project objective: Complete the merger of A’s, B’s, C’s, and D’s operations and technology resources.

Now, the use all those possessives didn’t seem right. I checked my trusty Chicago Manual of Style. CMOS 5.27 states:

Joint and separate possessives. If two or more nouns share possession, the last noun takes the possessive ending. . . . If two or more nouns possess something separately, each noun takes its own possessive ending.

Normally, I’d say that each noun’s possessed thing is separate, so each should have the possessive after all. But then again, we’re talking about a merger of those possessed things. So are they actually separately possessed? Or do A, B, C, and D all possess the merged operations and technology resources collectively?

Dilemmas, dilemmas.

So I removed the possessives. But that resulted in a garden path sentence:

Project objective: Complete the merger of A, B, C, and D’s operations and technology resources.

When you first read the sentence this way, it sounds like A, B, and C are being merged, not things that are possessed by A, B, C, and D. Or even that A, B, and C are being merged with D’s operations and technology resources. So I put the possessive endings back in to maintain clarity over style considerations.

My manager—the second-level reviewer—ended up rewriting the sentence completely, but this little episode illustrated to me how asking what version is clearest can settle other questions.

Related entries:

• The Difference Between Grammar and Clarity
• Content Reuse Issues You May Not Have Thought About
• Ten New Year’s Resolutions for Technical Writers

Now I’ve gotten around to it.

What Influence Is

Brian Solis recently wrote about how influence has been confused with online popularity. He says:

Over the years, I’ve explored the roles of influencers in social networks and as a result, I’ve refined the definition as simply the ability to cause measurable actions and outcomes. Intentional influence then assumes that certain actions are therefore definable and as a result, desired activity and results are now designed into strategies. The execution of these plans is then dependent on the reach and conviction of the influential voices to which they’re aligned.

One of the classes in my communication minor in college focused on persuasion and social influence. (Yes, majoring in English and technical writing and minoring in communication may be redundant. But the minor gave me a perspective on how people communicate in general, not just how to communicate technical concepts to people.) In this period of the ubiquity of social media, thinking about social influence is highly relevant.

Our textbook was Persuasion, Social Influence, and Compliance Gaining, of which our professor was a coauthor. The book is based partly on the premise that the three named concepts are closely related or synonymous and that they’re aimed at changing people’s thoughts, attitudes, or behaviors.

I believe influence is different than a social circle or even than attraction. Someone may be in my circle without being influenced by me. People may be drawn to my blog through a link on Twitter and never be influenced by what they read. I agree with my college professor’s view of influence: it’s bringing about change in someone else.

How Do You Measure Influence?

Many of the 25 and the honorable mentions have posted about what it meant to them to be included on this list. After seeing those responses, I read Larry Kunz’s perspective, that of someone who (I believe) should have been included and wasn’t. The fact that he and his cohort, Julio Vazquez, were excluded turned out to be due to a computational technicality. I was already thinking about the meaning of influence in this context, but Larry’s analysis of the situation really spurred my thoughts onward.

The people on this list are hard to compare when you’re talking about influence as a general concept. I’d say many of the people in the list of 25 have different kinds of influence. RJ Jacquez may have a wide reach and help people understand how to use RoboHelp. Does that mean he’s influential? In my opinion, he’s a much different kind of blogger than Tom Johnson, for whom blogging is done entirely in spare time. I’ve been much more influenced through my association with Tom than I probably ever will be by RJ. But that has been due to associating with him in person rather than entirely through his blog. Influence is hard to measure.

This post probably sounds like I’m putting down the “influential blogger” exercise and MindTouch’s efforts. This isn’t my intention. I am pleased to have received some recognition and be named as someone that can help other people in my field. I think the list is a way to help technical communicators build their networks with each other and give newbies a place to start looking for ways to improve in the profession.

At the same time, I think perhaps the list was misnamed. Maybe it would be more accurately called “The 25 Most Visible Tech Comm Bloggers” or “The 25 Tech Comm Bloggers with the Biggest Audience.”

Any Influence Here?

I don’t entirely agree with Solis’s definition of online influence. Influence isn’t always measurable. I don’t have definable actions I would like people to take as a result of reading my blog or following me on Twitter. My aim is pretty vague. My hope is that by reading my blog, you think about tech comm in ways you haven’t before and even can make some improvements as I do through what I learn in my day-to-day work. My aim for Twitter followers is even more ill-defined: Converse about tech comm, get a link to something useful, have a chuckle.

What do you think? Has reading this blog changed your perspective or given you something concrete to use in your tech comm work? Have your thoughts or behavior changed somehow? I’m wondering not to boost my sense of self-importance, but to see if the blog is helpful to anyone besides me. I’d like to know if there are ways to improve how helpful this blog is. That’s my goal, whether or not you’d look at it as influence.

Related entries:

• Blogging: A Way to Give a Bit More Meaning to Life
• Two Aspects of Social Media Relevant to Tech Comm
• Stuck in Our Ways or Ready to Change?

In our ongoing department reorganization, we technical writers are experiencing some angst as we carve out a desirable place for ourselves. However, as we’ve talked about it as a community of practice (no longer as an organized team with our own manager), I think we’re coming to an agreement that now is the time to make things happen—to strike, as Tom likes to say.

After the initial, high-level reorganization, Tom and I are in the same division, so we’ve discussed a plan for taking a more prominent place in project managers’ and interaction designers’ consciousness. This is the key for us because the PMs are the ones to include us in their project plans and budgets, and we would be working with designers to decide on user education approaches and contribute to the design itself.

Finding Tech Comm’s Place in the Family

After Tom’s blog post about our meeting with an interaction design manager, I asked him about his point of view and his readers’ reactions to the post. We discussed getting involved in projects early and contributing to user interface text. We talked more about this in our community meeting this week. Again, we’re looking to make sure that the people who make the decisions give us a rightful place at the table.

We also talked about many designers’ “holy grail” of creating products so intuitive that no documentation is needed. Tom reminded me and then the group of an important point I had forgotten. An interaction designer once said something like this to me, and I had passed it on to the team: “Saying that ‘if the interaction designer does his job right, the product doesn’t need help’ is like saying ‘if the developer does his job right, the product doesn’t need QA.’”

I’ll run that by you again:

Saying “If the interaction designer does his job right, the product doesn’t need documentation” is like saying “If the developer does his job right, the product doesn’t need quality assurance.”

Not many project managers would argue the value of QA. So why should they argue the value of technical communication?

If you boil this designer’s statement down to its basic premise, you get “The technical writer provides quality assurance for the interaction designer.”

When you think about it this way, you’ll start to get a sense of why tech comm ought to have a place in every project meeting from the design phase all the way through to the end—why we ought to be sitting at the table with the other project leads.

You Provide Quality Assurance Too

Let’s take a look at what quality assurance is all about. At least in the software development world, quality assurance engineers, more simply known as testers, exercise the software once coded to make sure it meets functional requirements. Clicking a button or link brings about an expected result. Inputting certain data returns certain other data or provides specific options. The idea of all of this is to make sure that someone using the product accomplishes certain predefined objectives.

If you’re fortunate, you work in a company that places usability testing among its priorities. In the Agile environment I work in, we don’t have much time between design and development to conduct usability testing. Any testing we could do would have to be early, probably with paper prototypes and grabbing some person at home to try them out. Usability testing, as the name suggests, tests the design.

Either way, the tech writer tests the design. We do this by making sure, as we provide documentation and training materials, that the user can accomplish predefined objectives using the design that’s provided. Yes, we may log some bugs along the way. Yes, we want the product to actually work and not return errors. But what we’re mainly concerned with is how to navigate the product’s visual elements to accomplish a task.

As we document steps, we can see when terminology doesn’t make sense or when a control is hard to locate. We can see when a task takes too many steps, includes steps with too many substeps, or has an inordinate amount of permutations of the same step. We can see inconsistencies in different parts of the product. We are the first users.

People are people, and we like simple. Some business processes or other procedures are complicated, and we may not be able to do anything about that. But we can help make sure that the products that support those procedures are as simple as possible.

Wrap-Up

Quality isn’t found solely in working code. Quality is found mainly in the experience. Technical communicators are immersed in the experience of a product because we have to understand it. We have to see it as the user sees it. As a result, we can provide quality assurance for product designs beginning in the early stages of design and development.

Related entries:

• A Writer’s Exercise for Critiquing Design
• An Interaction Designer Who Understands the Need for Documentation
• Four More Reasons Your Company Needs Technical Communicators

Two years ago I hadn’t heard of content curation, and you probably hadn’t either. Now it’s everywhere. The steam of content is turning into a flood. (Brett Swanson calls it the exaflood.)

As a technical communicator, if you’re not already assimilating content from all across the organization—as well as from your customers—you soon will be. In fact, your customers won’t wait to be invited to the party.

This subject fascinates me, and I like to read everything I can about it. I’m noticing something: as the flood of content increases, the flood of content about content curation is increasing too. Blog posts. Slide decks. Webinars. All with their attendant tweets, RSS feeds, and email notifications.

I’m not alone. As I was preparing this piece, I ran across an article in which Ian Greenleigh wrote that he has trouble handling all of the “shiny” new stuff being written about content curation. Like Greenleigh, I have a column in TweetDeck labeled #curation. Unlike Greenleigh, I don’t have ADD—but I still find it devilishly hard to keep up with everything.

The flood of content has forced me to develop my own curation skills. As I curate the content I receive about curation, I’m learning principles for curating the content I deliver to my customers. Call them the 4 Fs.

Find. With so much content, I’ve become impatient. If I hear about something but can’t find it quickly, I’ll give up. My customer must be able to find my content easily, through good navigation or through search. Just as writers have learned the best practices for writing for translation, we need to learn the best practices for writing for SEO.

Filter. I’ve set up Twitter to pick out tweets that are topical and relevant. In my web browser, I’ve bookmarked the blogs I trust the most. For my customer, I have to provide similar tools for filtering content about my product. I can tag topics, for example, to deliver content for a particular product version or model number.

Focus. I can’t cast my net too broadly; I have to choose the aspects of content curation that interest me most. For my customer, it’s up to me to deliver content that focuses on the specific task and leaves out irrelevant details.

Increase frequency. I count on secondary sources—links from other blogs, retweets—to ensure that I don’t miss any of the really good stuff. In the same way, my customer needs several pathways to the content they need and want. Not more content but more pathways. Linking, cross-referencing, and content reuse come into play.

What techniques have you developed for making your content easier for customers to consume?

Larry Kunz is a project manager and information architect with Systems Documentation, Inc. (SDI) Global Solutions in Durham, NC. He teaches a Managing the Information Development Process course in the Technical Communication certification program at Duke University. He is a Fellow in the Society for Technical Communication (STC) and in 2010 received the STC President’s Award for heading up the Society’s strategic planning effort. Larry blogs on the SDI website at http://www.sdicorp.com/Resources/Blog/articleType/AuthorView/authorID/24/lkunz.aspx.

Related entries:

• Weed out Irrelevant Content
• Helping the Team Broaden Their View
• Whether or Not to Read Aloud in Reviewing My Content

So, You Need a Book about Usability

A while back, I asked Karen Bachmann, a usability expert in our STC chapter, to recommend some books for our tech comm department. I was looking for a place to start with the topic. Without hesitation, she told me everyone should read Steve Krug’s Don’t Make Me Think.

So, I ordered both Krug’s books: Don’t Make Me Think and Rocket Surgery Made Easy. Rocket Surgery is an expansion on his explanation of how to do simple, cheap usability testing. It comes with great check lists and sample scripts that you can download, along with a free chapter of the book and recommendations on equipment.

Once I had read Don’t Make Me Think, I wanted to send recommendations to our developers. That seemed like an overwhelming undertaking, so instead, after reading Rocket Surgery, I decided to implement a testing schedule for our documentation, with the long-term goal of getting to test our products.

The books are light-hearted reads that make usability seem like common sense that everyone will value if you can just get them to a testing session. And I wanted a project like that. One with value that would be immediately apparent to anyone who dropped by to observe the testing. One that wouldn’t rely on my qualities to succeed, but that could sell itself.

The book was filled with step-by-step instructions for the various phases of testing: recruiting participants, writing the testing scenarios, leading the discussion afterward. Simple. The way I explained it to my manager sounded so simple, too. She approved the project.

Rocket Surgery by Proxy

Ultimately, the testing sessions we implemented differed in some fundamental ways from the process that Krug outlines. This was partly because we were testing proxy users—co-workers who have the domain expertise of our customers. The other variable is that, rather than websites, we were testing complex, highly-customizable products. This issue of testing on co-workers was the biggest challenge to adapting Krug’s method.

Our company builds software to be used by mainly by medical personnel in clinical settings. Many of our product specialists and technical support specialists come from that background.

This was important because we would not be recruiting for participants among our external users. We’d only recently started directly contacting clients. Trying out a new testing process on them was too far outside our comfort zone.

I took an excellent short story class in college towards my Creative Writing degree, and most of the class periods involved intense workshopping of our stories. The problem was, the second time we looked at a story, it was sometimes difficult for us to appreciate the revisions because we compared it to the previous version.

We couldn’t un-know the plot twists, and so we had an insider’s view, even if the twists were better executed in the second draft. The professor called it “pregnant with knowledge.”

Our proxy users, our testing participants, had insider knowledge of the products and sometimes even the documentation. They knew workarounds to find information that real customers may or may not know.

Many times, a participant would make an observation about a frustrating experience, “I wish I could sort here,” but then follow it with either the reason why the improvement hadn’t been implemented yet, “but we did this because we already had it that way in Product X,” or a detailed recommendation on how to fix it, “I was talking with Sue about how we should sort on this page and then filter by release date on the following page.”

My attempts to improvise and make the most of these insights led me off the scripts that Krug provides. I customized the script to fit our situation, as it was. I don’t think these variations produced bad results. It just complicated things. To compensate, I would recommend allotting ample time for creating the testing scenarios.

Kristi Leach is technical writer, content strategist, and recent transplant to the Chicago area. You can read the second part of this post on her blog, Release Notes.

Related entries:

• Six Things to Remember in Your Documentation Usability Testing
• Documentation Needs Usability Testing, Too
• Some Observations from Documentation Usability Testing

I knew from the email subject line that I wasn’t going to like what was in the message.

The subject contained the name of an application, then two frightening words: “help sheets.”

I’ve found that outside the tech comm profession, people tend to throw around terms like “help” and “tips” without really thinking about what they mean. That’s why I felt a bit of dread as I opened this particular email.

The Rogue Documents

Looking for feedback, the product manager had forwarded two Word documents from an instructor who teaches this particular application as part of a week-long training for office staff. The instructor had documented a couple of end-to-end processes that weren’t strung together like that in the help.

Let’s just say that these documents weren’t done by a professional tech writer. I didn’t even get down to giving feedback on a content level; a subject-matter expert did some of that. Instead, I was concerned that by giving these documents to the class members, we were providing an inconsistent and less-than-professional experience.

I was also concerned because these documents’ pages were numbered 35 through 41. So what else was there that we didn’t know about? How much effort was being duplicated? Since it’s my full-time job to create such materials, I would have preferred if the instructors let us know about the need and asked me to fill it. Frankly, it felt a bit threatening, as if I thought my job was in danger. I considered this “rogue,” or unofficial, documentation.

The Idea

I ignored this email until the next day. Then, however, I decided to change my stance. I realized this was an opportunity, not a slap in the face.

I called the product manager and suggested that we visit the class with the purpose of seeing if we at headquarters were providing everything needed for these instructors at the training center. It had occurred to me that this was something we should have done a long time ago, back when the application was rolled out. Instead, I had focused on documentation and training materials while remaining unconscious of the actual in-person training that was going to happen.

So sleeping on it did some good. My view the day after was much different than my initial reaction.

The Opportunity and the Result

The product manager thought this visit was a great idea. He, the SME, and I spent an entire day observing the classes and even provided corrections and additional information. We also found that our training system had some bugs in it that prevented the instructors from covering some important material—and from instilling further confidence in the application in the class members. Instead of letting us know, they skipped or worked around the problems.

It was an interesting parallel: We weren’t getting much feedback from the instructors on our materials and what they needed from us; at the same time, the instructors don’t get much feedback from class members on the quality of the training once they’ve begun their assignments.

I found out that the other “help sheets” covered the basics in programs like Word, Excel, and Outlook rather than our custom application. That gave me a little less to worry about.

As the three of us visitors discussed our findings later, the product manager pointed out that the class members were essentially being overloaded with information. They would forget much of what was taught in class and have to relearn it once they began their assignments. But at least they would remember having been exposed to it before.

At this point, I won’t be developing any standardized materials for the classes. But we decided, along with the instructors’ supervisor, that semi-annual visits would be beneficial so that our efforts will be coordinated. For now, the “help sheets” will probably stay as they are. But I took their existence as a cue to improve the help material on that subject to be more comprehensive.

I learned that when I encounter rogue documentation, instead of feeling threatened or replaceable, I should take it as an opportunity to analyze what I’m doing and where the holes are. It’s an opportunity to do my job better.

Art credit: Drawn and colored by Daniel Minson.

Related entries:

• A Little Thing Called Documentation Sprawl
• Follow-up: A Skill for the Extroverted Technical Communicator
• Where Usability and Documentation Meet

In today’s world of technology changing in the blink of an eye, ongoing professional development isn’t an option for technical communicators, it’s a requirement. Over the past decade the field of technical communication has grown and gained more respect as a legitimate profession, and the complexities of the job and skill base required of technical communicators have also increased. Some of what’s new we can learn on the job—if we have a job—but sometimes we need to obtain the skills to stay vital in other ways.

When it comes to professional development in tech comm there are a lot of options. If you’re gainfully employed, enjoying what you do, and just need to brush up on the latest tool, then probably just a training seminar or a short online class is all you need. But if you’re not employed, or employed in a different capacity than you’d like to be, then you might want to consider a bigger educational commitment to make yourself more marketable as a technical communicator in today’s world.

In 2008 I stepped out of the working world to go back to school to earn my master’s degree in technical communication. While I’d started my career as a technical writer in a software development environment, I’d changed roles along the way, and by 2008 I was wondering how I’d gotten on the train I was on and, more importantly, how I could get off of it. I decided earning an advanced degree was the right decision for me, so in January, 2009, I took the plunge and started graduate school as a full-time student.

Making the Decision

If you’re thinking about going back to school to earn an advanced degree a few things you should consider are:

• What is my financial situation? If you’ll be paying for your education yourself this is obviously one of the first things to consider. Even at a state school, graduate school is expensive (trust me). If you do like I did and go full-time you’ll need to make sure you can do without an income during that time.
• Why do I want to go back to school? Or, put another way, what do I want the end result to be? In May, 2008, when I was first looking into my program, I sat in my advisor-to-be’s office and told him I wanted “to catch up with the field of tech comm.” Throughout the program I never lost sight of that goal. (Along with the goal of wanting to get not just any job, but a good job as a technical communicator when I was done.)
• Do I have the determination it will take? Whether you’re going full-time or part-time and taking a class or two at a time while you work, graduate school is no small commitment. Make sure you understand that before you start—and it will still probably be different than you think.

Getting the Most Out of School

Once you’ve decided to go back to school I highly recommend you make the most out of your time as a student. Keep in mind that an academic program is just that: academic. Academic programs are good at teaching you how to think but they don’t always provide all of the practical skills technical communicators need, such as tools knowledge or authoring techniques. Augmenting your education with practical opportunities will make you a more well-rounded technical communicator (and better job candidate) in the long run.

Here are some ways I’ve made the most of my experience as a tech comm student:

• Get what you want out of the program—don’t let it define you. When I had to select a book to review in a theory class I chose Anne Gentle’s Conversation and Community: The Social Web for Documentation rather than something more theoretical. For my final project in the same class I explored the idea of user-generated content and highlighted Adobe Community Help. For my capstone project, I put together a Help system for a product that didn’t have one. Selecting practical project topics whenever the opportunity presented itself made my academic program much more meaningful to me.
• Take advantage of student discounts. No, I don’t mean movie tickets and Disneyland (although those are good, too), I mean discounts to professional societies. Most professional organizations, including STC, SIGDOC, and UPA, offer membership discounts to students. While you can, take advantage of the opportunity to join organizations like STC at the discounted rate.
• Get involved in student or local professional chapters. If you have a student STC chapter at your school, seek out the faculty advisor and be a part of it. Or get involved with the local professional chapter. My local STC chapter welcomed my input and was glad to have me at meetings. We now have two student members on our Administrative Council.
• Participate in professional events. Over the course of my program I attended a conference on DITA that was held on my school’s campus; listened to webinars on FrameMaker and SEO put on by my local STC chapter; and attended the 2010 STC Summit in Dallas (taking advantage of the discounted student registration rate).
• Network, network, network. Start networking early, before you really need to. Saying you’re a student is a lot less threatening to people than when your focus is on finding a job. Start building relationships at the beginning; later, when you are looking for a job, you’ll be amazed at what the fruits of your labors may bring.

Peggy Harvey is currently wrapping up her M.S. in Technical Communication at North Carolina State University, graduating from the program in December. She serves as Treasurer and Membership Manager for the STC Carolina Chapter and is an active member of the technical communication community. After a two-year hiatus from corporate America she has begun her post-education job search and expects to re-enter the working world as a practicing technical communicator soon. You can reach her at peggy(at)connectingtocontent.com or follow her on Twitter.

Flickr photo credit: bruinshorty, http://www.flickr.com/photos/bruinshorty/3873037675/.

Related entries:

• Get Passionate about Tech Comm
• My Personal Debate about Going Back to College
• Suggestive Selling for a Tech Comm Storefront

As we talked, Ann decided to open a new Word document to work in. I watched as she went into her file system and located a document with the file name “blank page.docx.” She double-clicked it to begin a new document.

I was somewhat surprised and even a little amused.

But watching Ann do this reinforced for me that even those tasks that some of us see as easy and routine aren’t that way in other people’s heads. To her, opening a document called “blank page” and then saving it as something else made sense.

I thought about telling her about Ctrl+N, which is my method of choice. There’s also using a desktop or quick launch shortcut or going to the Office button and then clicking New. But I decided to leave it alone. I had more important things to teach her that day, and she already had a method that worked for her.

What does this mean for user experience design and technical communication? A few things, I think.

• Left to themselves, users of our products may or may not figure out some way to accomplish a task. If they figure it out, their method may or may not be optimal. It’s our job to provide the optimal path to success.
• Addressing the most important concepts first is essential. While I could have diverted my conversation with Ann to talk about opening a new Word document, she probably wouldn’t have remembered without some repetition later. Word was off topic. I needed to keep her focused on the specific task she was trying to accomplish. A reminder to not divert users’ attention from the task at hand when it’s not needed.
• Usability has to do with giving people familiar patterns and few steps, not designing things and expecting training—or worse, the so-called intuitive design—to get the users through. They won’t do what we expect, and it’s better to design things to fit people’s mental schemes than to get them to learn something new.
• Because of the previous point, we’ve got to take time to watch users try out our products. An example: In another of our applications, a check-printing wizard includes a step where the user must indicate if each check “Needs Reprinting?” and they select Yes or No. But we’ve found that people are doing it backwards; they’re not looking closely, and they think they’re being asked if each check printed correctly. So we’re changing the text and swapping the code so that it conforms to what people expect to see. Having some users try it early in the process would have saved a lot of support calls when people found their payments kept going back into the queue to be printed (they thought they were saying “Yes, they printed correctly”!).

Remember that the unexpected will grab your lapels and give you a shake in circumstances like this. Over six billion people inhabit this planet, and they don’t all think alike. Plan ahead for the fact that at least some of your customers and users won’t do what you think they will with your product. And if you don’t know your audience, it’s even possible that most of them won’t do what you expect.

Related entries:

• Fight User Frustration: Give Users What They Expect
• The Result of Ignoring Users While Designing
• Consider Users’ Environment as Part of User Experience

The Users

1. What will users’ objectives be with this software?
2. How many users will there be?
3. How often will new users need to learn how to use the software?
4. How can I get in touch with users?
5. How many user roles?
6. How much overlap is there between user roles?
7. How do the users prefer to get assistance?
8. What environment(s) will users be using the software in?

The Process

9. Who are the subject matter experts and the product manager?
10. How are development and documentation tasks created and tracked?
11. How can I access development or test builds of the software?
12. How do I suggest improvements (particularly regarding UI text) and report bugs?
13. Where are project documents stored, and can I have access to them?
14. What usability testing will the team be conducting on the product?
15. Can I deploy my products on the fly, or do I need to follow a release process?
16. How will the content be coordinated with and used by support and marketing?

The Product

17. What are the most important and the most outstanding features?
18. What are the most common tasks users do or will perform?
19. Does the project have a dictionary of product terms?
20. Is the software installed locally, used over the network or Web, or some other way?

The Documents

21. What document technologies are supported by the organization?
22. Who will maintain the documentation after the software is released?

No related posts.

A Narrow View of Tech Comm

When I graduated from Utah State University two months before starting as an intern, I thought technical communication consisted mainly of writing manuals, help systems, and the occasional tutorial. I thought the main activities were writing and creating images for print or Web.

My definition of a technical writer didn’t differ much from most people’s if at all.

I hadn’t heard the terms CSS, single sourcing, structured authoring, DITA, social media, Agile, RSS, SEO, or content strategy. Some of these things were either relatively new or not dreamed of at that point.

I belonged to the student chapter of the Society for Technical Communication, but the chapter members mainly learned from each other. There was only so far we could go that way.

A Widening View

My horizons definitely broadened after graduating. The program I graduated from taught me things like collaboration, audience analysis, and project planning. But the focus tended to be on delivering a final document.

Through the projects I worked on, I learned some help authoring, CSS, and JavaScript. I was a team of one for a while, so I had to find opportunities to improve my skills. Later, as people joined the user education team, I discovered tools and techniques I hadn’t guessed existed. I also rejoined STC, started attending conferences, and served in chapter leadership positions. I learned to subscribe to tech comm blogs to find out what other people in my field were up to.

An important lesson I picked up is that I don’t have to be stuck in user guides or online help. The technology available these days has opened many methods of communication.

A Realization

Perhaps the most important thing I’ve learned is what I’m really doing as a technical communicator.

My first documents were indeed online help and a small set of manuals, so I can credit my education with getting the job because that’s what my supervisor was looking for. But the other things I’ve done have altered my view of what a technical writer or technical communicator is.

If someone were to ask what I do for a living, for much of the last five years, I would have said something like “I’m a technical writer. I document software.” I still say things like that. So some of the lessons from my time in the field haven’t sunk in to the core of my brain yet.

What I should be saying is, “I provide documentation and training to make people successful in using software.”

That is the goal of all technical communication as far as I’m concerned: making the audience successful at whatever their goals are, whether it be obtaining a certain piece of information or completing some task.

A Look Forward

I’ve been anticipating new projects so that I could bring to bear everything I’ve learned over the last five years. That chance has come with a couple of new software projects, and I expect good results of myself. I’m trying to think outside the manual and the traditional help system. I’m considering the audiences, their environments, and their needs.

With a look back over the last five years, you may think I’m going to wave my fingers over a crystal ball and predict where tech comm is going in the next five years.

I don’t do that sort of thing because I don’t find a lot of value in it.

I can sit here and tell you where I think tech comm should go, and that has come out in my blog. At this point, that’s the only effect I can have on what changes happen in the profession. Sure, the practice of tech comm has its core functions that haven’t changed in the last five years, which means they won’t change in the next five. Everything that has changed has done so at a quick enough pace that I don’t think we can predict what tech comm will look like five years from now.

In many ways, it probably won’t look much different. Most of the changes that have come about have to do with how we produce documents, not with how we deliver or how the audience experiences them. Social media have changed that to some degree, but things like structured authoring and single sourcing affect the writer much more than the audience.

If anything will change in the next five years, it needs to continue to be how we perceive ourselves and how the organizations we work for perceive us and our contribution. That won’t happen unless we think strategically (yes, an allusion to content strategy) and point out that we help make customers successful, rather than thinking tactically (“I create software documentation”).

A Few Final Words

I think I’m smarter now than I was five years ago. I’m recognized by the managers and development teams in the project portfolio I work in. Many of them understand how I work and how to work with me. Equally important, I understand how to work with them. I understand how necessary good audience analysis and project planning are in technical communication.

The last five years have been good to me. I’ve gone from being a just-out-of-college, entry-level newbie to a professional with confidence in my work, an online presence, connections with numerous other professionals, and leadership experience.

Let’s make the next five at least as good.

Related entries:

• Technical Communicator = Perfectionist?
• Suggestions for Survival in an Agile Environment as a Technical Communicator
• A Team Member with the Heart of a Technical Communicator