I'd Rather Be Writing » tools

Graduate Research Findings about Technical Communication and Blogs in the Workplace

Tom Johnson — Sun, 22 Jan 2012 19:07:30 +0000

The following is a guest post by Michelle Tompkins. Earlier this year she asked me to post a survey about technical communication and blogging. I posted it here, and then asked if she would follow up to share her findings. This guest post shares her findings.

Earlier in December, Tom Johnson was nice enough to help me with my graduate research on how blogs are used with the workplace of a technical communicator. I received great feedback from all of the respondents on my survey, and I would like to thank everyone who participated.

Not only did my study look at blog use, but also how social media tools are changing the nature of work for technical communicators. As social media continues to change the way we write and communicate with audiences, it is important to understand the functions, uses, and impacts of these technologies on our work as technical communicators. My short survey helped determine if and how blogs are being used as a professional tool within our field.

After collecting and analyzing the data from my survey, I found that approximately 88 percent of respondents use social media tools at work. When respondents were asked specifically about the type of social media tools used, wikis, social networking sites, and micro-blogging technologies such as Twitter were the most popular.

However, only 69 percent reported using blogs as part of their work. The most common uses of blogs within the workplace were sharing internal company news, communicating with external stakeholders, reviewing products and services, and knowledge management and sharing.

Another common use of blogs by technical communicators was professional development. Many respondents reported blogs as a replacement for the company newsletter, which has created a more dynamic forum for internal information dissemination.

While the focus of my research was specifically on the use of blogs, I was also interested in learning more about how social media tools have affected the nature of our daily work. Surprisingly, only 55 percent of respondents felt that social media tools have had a significant impact their daily work.

Some technical communicators felt that social media tools have opened a new channel of communication, which allows instant feedback from internal and external stakeholders. Another impact of social media tools reported was a more efficient way to store, organize, and share information.

Through my survey and other research endeavors, I believe the most significant impact of social media tools on our field as a whole has been the ability to have a direct connection or conversation with our users, customers, and document audiences. This direct connection with the end user will enable technical communicators to develop deliverables that are more accessible and usable for their specificied audiences.

With all of this said, I believe that social media tools have had a significant impact on the field of technical communication. However, I do not believe that it is inevitable that all technical communicators will embrace these technologies. Not all of technical communication jobs will change, but as evident from my research, a large portion of job descriptions may change as a result of the daily emergence of new technologies.

The most important aspect that I have taken from my research is that blogs and social media cannot be ignored. Even if technical communicators are not using the tools themselves, their users, audiences, and customers are, which forces us as technical communicators to at least be cognizant of these new tools of communication.

Once again, thank you to all who participated in my survey. If you have any further questions about my research, you can reach me at MET7189@gmail.com.

Michelle is a graduate student studying technical communication at the University of North Carolina at Wilmington. You can follow her blog at http://mshelltompkins.wordpress.com.

Blog Sponsors

What Tools Do Technical Writers Use

Tom Johnson — Mon, 19 Dec 2011 16:33:14 +0000

Students and others trying to break into technical writing are always wondering what tools they should use. The latest tools survey from WritersUA seems helpful in answering this question.

The survey concludes that some of the most popular tools for technical writers are Adobe Acrobat, Camtasia Studio, Adobe Captivate, Dreamweaver, Madcap Flare, Framemaker, Photoshop, Robohelp, Snagit, and Visio.

Of these tools, Flare scores highest as a tool that participants can’t live without. They ranked it as a 5, meaning “very important.” Presumably this is because Flare does an excellent job in single sourcing to other formats, such as print and mobile. It’s an all-in-one solution, so it by definition it’s important or you’re not using the tool correctly.

The WritersUA survey is a little frustrating because these tools aren’t grouped by category. Some are screen capture tools, others are PDF conversion tools, others are image editing tools, others are video recording tools. I use Photoshop and Snagit, but ranking these along with Robohelp and Flare is to compare apples to oranges. Similarly, Camtasia Studio and Captivate are in another category. It would be helpful to sort the tools by category. (Still, it’s nice to see someone doing a tools survey in the first place.)

Of the help authoring tools, it’s interesting to see Flare rank so high. Flare is an excellent help authoring tool, and with a knowledge of CSS you can completely customize the webhelp and print output to look professional. However, its main failure is the lack of collaborative authoring. If you have 15 writers all contributing to the same help project, you have to import the content from other authors. They can use supporting tools such as Madcap Contribute, or Word templates. You can also try hosting Flare on SharePoint and enabling collaboration this way.

But I’m guessing that Flare is popular because most technical writers are solo sailors on their own ship, without the need for collaboration from other writers. In my career, the number of collaborative projects has been very small. I am usually the only writer for the project, which means collaborative authoring is unimportant. I don’t need a central repository installed on a server that numerous authors can access and pull content from. Content is also not reused between projects, since each documentation project covers a different product.

Sarah O’Keefe also has some comments on the WritersUA tools survey. See her post, The passion quotient. She notes that the survey highlights “the tool for which the importance is ranked the highest.” Despite this criteria in evaluation, I am not sure how I would design the tools survey differently.

Blog Sponsors

The Proximity Problem for Technical Writers

Tom Johnson — Fri, 23 Sep 2011 14:33:59 +0000

Last year I wrote a series of posts about moving from the sidelines to center stage. In the series I described how I transitioned from a low-key, hardly-speaking project member to a key player on the project team, someone with a voice that mattered in project decisions. But recently, with some projects, I’ve come full circle, moving back to that initial position of a fly on the wall.

The changes had a lot to do with location. Previously, each technical writer was embedded in a specific group. Most of us were stationed on different floors, in proximity to the developers, interaction designers, quality assurance engineers, and project managers for each project.

This proximity was useful for staying in the loop with project information, but it did nothing for our technical writing team. We used different tools, didn’t follow a common style guide, and came up with our own processes and content models.

Because we wanted to try to build some momentum towards standards, we decided to consolidate our group, sitting together in the same row of cubes. We were no longer embedded within specific project teams, but rather centralized as technical writers in a common location and shared throughout the organization.

In the previous embedded-writer model, I looked longingly towards our once-a-week meeting with technical writers, holding it as the highlight meeting of the week. But now that we were sitting together, it was like a team meeting all day long. Coordination and morale skyrocketed.

As the weeks passed, we started to form some standards. We decided to standardize our toolset, first of all, so that in case one writer won the lottery and left the organization, another writer could seamlessly fill the gap. After weeks of research, and through the luck of another group that already purchased the solution, we adopted and implemented a new help authoring system. We then attacked our style discrepancies, and quickly adopted a 42-page guide of stylistic decisions.

We were gaining momentum fast, and acquired our own servers to run help, injected a documentation template into the project manager process, formulated a content model for help, designated a team member to be the tools administrator, and more. We were flying as a team. We even stopped holding team meetings because anytime we needed to meet, we could just swivel our chairs and raise an issue. Our close proximity led to a brilliant flow of communication.

In the back of my mind, I knew that we had lost some rapport with the project teams that we no longer sat next to. But it didn’t hit me how detached I had become until, about a year later, I attended a two-hour meeting with one of my projects and found that I had nothing to say at all. All the momentum I had previously accrued as a key project voice seemed to slip out from under me.

Proximity and Communication

Sitting silently in the project meeting, not contributing towards interface text, nor quality assurance, nor jumping in on broken functionality, nor even on training strategies, I realized that my sacrifice of proximity with the project team had resulted in my impotence on the project team. I no longer had the same voice, nor was I someone anyone paid attention to. I had become that quiet fly-on-the-wall technical writer, the one whom no one expects anything from except a help file.

I’ve learned that proximity to any team makes an incalculable difference in the role you play with that team. Grouped together with other writers, we actually formed standards for the first time in years. We felt like a team. And separated from project teams, I fell off their radar, and they off mine.

This, then, is what I’m calling The Proximity Problem. The closer you are to a group, the more you interact with that group. But you can’t be everywhere at once, so you have to choose the group that gets priority. Given these dynamics, is it better to be embedded within project teams or within a technical writing team?

Comparing and Contrasting Benefits

Embedded within project teams, I did much more than technical writing. I logged bugs, critiqued designs, guided project managers with feedback from users, and was generally go-to guy for new team members who want to ramp up on the project. I became a subject matter expert on the app itself, which led to my being a key member with a voice at the table.

Embedded within the technical writing team, I didn’t get sucked into all of these secondary roles. I could focus on my primary contribution: the help material. But not having involvement in other aspects of the project, such as the design, testing, interface, planning, and so on, made it harder to write help. I was often a latecomer to information, finding out at the last minute about upcoming releases and stumbling into new pages with changed functionality.

Sitting with my colleagues is heavenly. We understand our kind. We engage in heated debates about style controversies, and sometimes crack jokes about how bad interface text is. We ask each other questions about Author-it and Camtasia. One of my colleagues even brings in peaches to share, and has his own candy store. It’s comfortable to sit with them, and share in the camaraderie.

But in the larger scope of agile development, this isolation from the project conversations that are happening on an ongoing basis seems to have negative consequences. The isolation away from other writers, as I sit near developers and other IT members, might be worth it for the end result. The problem is that projects are often short durations, so I would need to be nomadic for the model to work, moving from one project group to another as my project load shifted.

Perhaps nomadism would be ideal for help authors. When working on project X, sit next to project X. When working on project Y, sit next to project Y. And yet, even despite the improbability of such an open seating model, it seems archaic in a day of virtual collaboration and remotely located workforces. Why insist that maximum productivity is only gained by rubbing elbows with your team all day long? Surely asynchronous methods of communication, real-time online interactions, and regular meetings using VoIP or the telephone can compete with the benefits of nearby seating.

Alternatives to the Dilemma

Despite the logic of embedding myself with a project team, where very likely I’m the only technical writer present, I’m not ready to give up our new-found team momentum. We’re making a lot of progress towards standards and tools, processes and styles. Once the dust settles, we may return to our former model in which we’re embedded in project teams.

Still, perhaps I’m holding out for another reason: I’m not convinced that proximity is essential to keeping up with project information. I’m not persuaded that there aren’t equally viable ways to gather the same data and interact, because if nothing else, the Internet has shown us how remotely distributed people can be closely connected with each other. The Internet has pulled us loose from our physical relationships, distancing us from those immediately around us and drawing us closer to others whom we never see or speak with. Email, instant messaging, Internet Relay Chat, webinars, podcasts, blogs, websites, text messages — all of this enables communication to take place despite physical boundaries. Theoretically, proximity shouldn’t be a problem. But teams who already enjoy proximity have no need for virtual communication tools, so outsiders often feel the need to participate in close proximity model to keep in loop.

It’s true that proximity does lend itself to more immediate updates. When you’re sitting next to a developer and he makes a shout of joy when he gets something to work, you’re updated. When you’re sitting next to a tester who groans each time she finds another bug, you’re updated (that is, if you ask what the commotion is about).

But it’s still possible to stay updated sitting remotely, away from project teams. And this is precisely because nearly every team in most IT groups uses some form of bug tracking tool, such as JIRA, Team Foundation Server, Fogbugz, or something else. Nearly everything gets logged somewhere, and if we take the time to stay close to it, to follow it as carefully as we might read a novel, tracking comment threads, attending meetings, reviewing sprint plans and roadmaps, checking IRC logs, design and requirements documents, listening each day to scrums — if we did all this, we could circumvent the proximity problem and perhaps even stay more aware than team members in the same cube aisle. That is, as long as distance doesn’t deafen our ears, make us forget our priorities and workloads, and lull us into a false belief that nothing much is going on.

Blog Sponsors

Formalizing My Help Strategy

Tom Johnson — Tue, 08 Feb 2011 06:52:42 +0000

In this post I'm putting together a more formal help strategy.

In a previous post, I started to explain my approach to help authoring. I’m trying to flesh this out into a more developed and detailed — but not too long — statement about how I do help. This information would be useful both to project managers as well as other writers I work with. I would appreciate any feedback.

Help Strategies

Because users have different skill levels and learning styles, help material needs to be multimodal in its approach, providing content not only in written format, but also through videos, illustrations, and the interface. With this approach, learning materials for a software application typically include the following:

Videos. Videos are usually brief screencasts that focus on a specific task. As screencasts, the videos are voice-narrated and focus only on the screen, without actors or scenes. The screencasts are short, such as 1-2 minutes, and are created almost entirely by the technical writer. This keeps production costs down while allowing for updates as the application changes. New users, especially visual learners, will typically view a series of videos to become familiar with an application. Videos aren’t meant to address advanced topics or edge cases, but are targeted at new users who prefer to learn by having someone show them how to do tasks.

Quick reference guides. Quick reference guides are usually two to eight page guides containing brief instructions in a visual way. These guides often contain screenshots with callouts and other explanations. The quick reference guides can also include concept diagrams, workflows, and other illustrations to help users understand the application quickly. Text in quick reference guides is brief and compressed, providing more of an overview than specific how-to detail. The basic idea of a quick reference guide is to give the user just enough information to get started in the application. This type of help material appeals to users who prefer some information in a brief, easy-to-digest way as they first jump into an application. Like videos, quick reference guides are targeted to new users.

How-to guides. How-to guides are lengthier printed guides that expand on the application in a more elaborate — but not comprehensive — way. A how-to guide is meant to be read, not merely referenced, and will focus on many concepts and capabilities within the application. These guides are a subset of the total documentation, with topics selected and integrated in such a way as to produce a readable booklet about the software application. These guides are usually single sourced from the online help and crafted in a way to make them pleasing in a print-reading experience. How-to guides are intended for users who want a more in-depth grounding in an application.

Online help. Online help is a browser-based HTML format for help content. Online help is the most comprehensive collection of topics, intended for reference and searching more than anything else. Online help is meant for users who have specific questions or need to search specific how-to’s (often advanced topics) about the application. Online help isn’t intended for people first learning about an application, because the topics aren’t necessarily grouped in a sequential or linear way. Each topic is modular and can be accessed and interpreted independently of other topics.

Interface text. Interface text includes all the language within the interface, from button names, page titles, and error messages to other instructive and navigational text the user interprets to use application. These interface tips and guides are important for users as they explore the interface and learn by doing. Interface text can also take the form of on-screen help text (often shown in hover tips) or as context-sensitive help, which shows a topic relevant to the current page. Interface text accommodates users who prefer to learn by doing.

Help Content

Access to users. Apart from the format, the content of the help material needs to be relevant and useful. In order to produce relevant content in a language and organization that makes sense to users, technical writers need to understand the user’s environment, vocabulary, and tasks. As such, technical writers need access to users. The access could come through phone calls, observations of users, or other interactions. Based on interactions with users, the technical writer may create personas and scenarios to create better help. Personas and scenarios can expand the perspectives from which a technical writer sees an application.

Multiple perspectives. The paradigm of a single author working from a single perspective, usually as an outsider to the actual business context of the application, is a paradigm that typically fails, since no one person can know all the information needed to help users. Contributions from multiple perspectives — from project stakeholders, project team members, community volunteers, and end-users — will help the content reach relevance and usefulness for a larger number of people. The importance of collaboration requires an approach that facilitates multiple authors and distributed ownership.

Editorial roles. Because of the need for distributed authoring, subject matter experts may often be content contributors. In these cases, the technical writer acts as an editor to help style and review the subject matter expert’s content. Other times, end-users themselves may contribute toward the content. User contributions should not be discouraged, nor should it be difficult for users to contribute or provide feedback. Heavy content collaboration may be facilitated through a wiki platform, but not necessarily. Other methods for interacting and content sharing can also be employed, such as with forums or comments below topics. In each case, the technical writer either edits or facilitates the content rather than creating it from scratch.

Perpetual beta. When the application is released, content is not finished. Even though content may be in a semi-complete state, we can never anticipate all the gaps, needs, quirks, and issues that users will encounter pre-release. For this reason, content needs to be published in a perpetual beta state, that is, with the ability to continually update the content even after release. As such, the help content should be stored separate from the application code to avoid release-window-only time frames. Technical writers should be able to update any help content on the fly as needs arise. Because help is usually stored on another server, applications requiring login should employ single-sign-on to reduce a secondary login windows.

Agile feedback loops. Just as the agile process often results in better software development, the same agile process applied to help material can be beneficial as well. To be agile, technical writers need to actively gather feedback about help material to improve it. Feedback from documentation doesn’t always need to be expressed as comments. Technical writers can gather feedback through metrics and other automated processes. Each help topic should contain tracking code to measure hits. Attending live training (or providing live training) and observing users can also be a means of gathering feedback. Technical writers need to be attuned to bug logging systems so they can connect with project team’s tracking of issues, and with the support center so they can monitor incident logs. Communication with product managers is also key to gathering verbal feedback. Where possible, technical writers should automate reports and other feedback on a regular basis and update the help accordingly.

Scope of information. Despite the attempt to provide business relevant content to every user, documentation does not need to provide instructions about everything. Too much information can make it difficult for users to find what they need. An over-abundance of information can dilute core task content and need-to-know topics. However, the technical writer does attempt to provide instructions for at least 80 percent of the typical user’s needs. Efforts to document the remaining 20 percent often fall prey to the law of diminishing returns; that is, for the effort required (tracking down hard-to-find solutions for unlikely scenarios), the payoff is little.

Help Plans and Processes

Prototype language. Technical writers should be involved in projects as soon as prototypes have been created. This early integration is necessary for technical writers to address interface language while there’s still time to make changes. Interface language is a component within the technical writer’s domain of expertise and should be treated as such. Technical writers should work closely with interaction designers in refining prototype language to avoid ambiguity — particularly in global contexts. Projects in which interaction designers are employed at the beginning, and technical writers at the end, often end up with broken interfaces.

Project plans. Technical writers should complete a project plan that provides project managers with a general estimate of the anticipated work and other details for the project. As an industry standard, it takes approximately four hours per application screen to create a help topic. This estimate of time for help topics only, and does not include time for creating videos, quick reference guides, or interface language. The project plan should also address the deliverables, expectations, risks, scope, timeline, and other details for the documentation. Failure to produce a project plan can result in a misalignment of expectations between project managers and writers.

Dual roles. Many times the technical writer becomes a subject matter expert on the application, having explored and examined it at length. The technical writer may become aware of bugs, usability issues, and support requests for an application. However, given the limited technical writing resources available, technical writers should only play these additional roles briefly. Technical writers may log or report bugs, but not necessarily flesh out the exact steps for reproducing bugs in every browser, nor conduct extensive usability testing, nor play support roles on the phone with end-users. If technical writers do play multiple roles on a project team, as is sometimes necessary in agile environments, project managers need to factor in this additional work into the project plan and estimated hours.

Approval processes. Before help materials can be considered complete, they must undergo review by several parties. The project manager should designate someone from the project team to review the accuracy of the help material. (Many times project managers themselves review this material, or assign quality assurance leads.) Other reviews may also be necessary if distributing the content externally. These reviews will add additional weeks into the completion of the help material. The reviews serve several purposes: to ensure consistency of style, to mitigate legal risks with content, and to provide another perspective on the coherence and accuracy of the content.

Tools and Technologies

Tools. Technical writing teams should use the same general set of tools so they can collaborate on files, share tips and how-to knowledge, and be interchangeable on projects. If one writer’s load becomes too heavy, he or she can re-allocate the load to other writers as long as the others can pick up and use the same tools. In most cases, use industry standards rather than open-source tools. Team members should also have the latest versions of each tool to facilitate collaboration.

Collaboration and content re-use. If external collaboration (such as with the community) is important on a project, a wiki works well. In fact, collaborating with large numbers of people in real-time is probably only feasible through a wiki, but the wiki doesn’t need to be the end product (the material can be exported). If only internal collaboration is important, other strategies may make more sense, such as a help authoring tool that stores content in a content management system. Ideally, if all internal collaborators can access and author from a central content management system, and render the outputs in a standard way without resorting to individual formatting, this can help with consistency and reduce the technical burden on content producers.

Corporate constraints. In a large organization, requiring every employee to standardize on the same toolset is difficult. Additionally, many times corporations limit certain tools and technologies from being installed. One must always work within a given environment while at the same time making strides to obtain approvals for more appropriate tools and technologies. Making appeals to industry standards can provide some leverage. Regardless, one can often accomplish the same results using many different tools and technologies.

Constant learning. Because technical writers often handle all aspects of content production, from creation to design to publishing to distribution in a variety of formats, including text, illustrations, video, and e-learning, the technical writer must constantly be engaged in learning tools and technologies. It’s not strategic to wait until the tool knowledge is required and a pressing deadline looms near. Rather the technical writer should schedule regular learning time, perhaps accessing sites like Lynda.com, into his or her daily schedule. When opportunities arise, the technical writer can leverage this knowledge to quickly design, illustrate, record, compile, call, style, or configure help content as needed. This learning is part of the technical writer’s job, and is an element that separates technical writing from many other types of writing.

Blog Sponsors

Answers About the Field of Technical Writing for Students

Tom Johnson — Mon, 06 Sep 2010 16:15:51 +0000

Download MP3
Length: 27 min.

In this monologue podcast, I answer a student’s questions about the field of technical writing, including how I fell into it, what kinds of projects I work on, and other details. Her questions are as follows:

What did you study in college and where did you attend?
What degrees/certificates do you have?
Did you know what you wanted to do before you graduated? If so, what was it? Is it what you’re doing now? If not, why did it change and are you glad it did?
What is your current job title and description?
How did you come across your current job?
What did you go through to get this job? Applying, interview, training, etc…
How long have you held this position?
What activities, responsibilities, duties, knowledge, etc. does your position require?
What have you done to maintain your success in this field/position?
Have your position and/or responsibilities changed over your time with this company?
What past jobs have you had? Were they helpful when starting your current job?
Did you study technical writing in school or was this learned/gained through the employment that you sought and obtained?
What tools (including computer software) do you most frequently use? And what tools do you most highly recommend to other technical writers?
When you were younger, what was your dream job? What’s your dream job now (if it’s not your current job) and do you plan on trying to pursue it anytime in the future? How will you do that if you plan on it?
Had you heard of technical writing before your jobs that were in the field? If so, what did you think of it and when you got involved with it in your past/current employment how was it different/similar from your previous expectations?
Can you ever see yourself working in a position that doesn’t require writing or some form of technical communication? Why/why not?
How would you describe your personal writing style? Do you think that at work this style is stifled because of the nature of your work or restraints/company policy?
Why did you start your blog? Where do you get the ideas for your posts and topics from?
Have you ever considered quitting your current job to work solely on your blog? Why/why not?
Is there anything that you’ve ever had the urge to write about to include on your blog but you haven’t actually done it? Why/why not?
What advice, if any, do you have for me, a soon to be college graduate wishing to enter the field in the next year or two?

Blog Sponsors

An Interview About Technical Writing

Tom Johnson — Fri, 09 Oct 2009 14:43:04 +0000

Download MP3
Length: 30 min.

This is a special podcast for Carly Finseth at Clemson University who is thinking about entering the field of technical writing and wanted to ask me a few questions. After I recorded the podcast, she was kind enough to transcribe it. I polished up the transcription a bit so that it would be more readable.

How did you make the career transition from academia and teaching to technical writing?

I taught basic writing courses to university students at The American University in Cairo for a couple of years. I also taught composition as a graduate student at Columbia for two years. Teaching writing is okay, but grading student essays was never fun. It was something I really hated. And at times it was okay — but by and large I felt like I was just justifying Bs and C, having to explain why these essays were poor, how to improve them, and so on. But that wasn’t what I wanted to do. I wanted to actually be the writer, not just teach others how to write. So I transitioned into professional writing.

For a while I did copywriting, which was all right, but it didn’t make a whole lot of money. And there’s a certain truth element that’s often missing in the copywriting role. Finally I decided to go into technical writing because it paid better and I thought, well, alright, I’ll try it. And it turned out to be a great fit.

Are you happy with your decision to work in technical communication? Why or why not?

By and large I think I’m pretty happy. Technical writing combines my love of writing and technology. I also enjoy working on projects in IT settings with other people engaged in the same work. That aspect of it that can be really rewarding.

It’s not entirely satisfying, though. It can be a little boring and can lack a little bit of excitement. I mean, you’re not out there saving somebody’s life in an emergency room. You’re not winning a case for some poor person being evicted. You basically sit at a computer all day writing instructions or figuring out how something works, and you occasionally interact with people. It depends on your role, it depends on the project. Some projects are a lot more fun than others, but by and large it is a good choice and I’m happy with it.

Could you tell me a bit about the first technical writing project you ever worked on? What were a few of the challenges – or successes – you faced when first starting out?

I started my tech writing career at a financial institution and, of course, one of the first applications I documented was a financial application. I remember the senior writer who was training me coming over and telling me that I needed to explain individual steps for printing a document. I was blown away by the level of detail I had to include. I couldn’t just assume people could figure things out from a few basic notes (e.g, To print the document, click the Print button). It really had to be detailed instruction (this is something I challenged later).

The other thing she told me is that subject matter experts are somewhat busy and that I needed to save up my questions. That’s something I also challenged later — you can’t have that passive, timid mindset all the time. Sure it’s good idea to save your questions when you’ve got a bunch, but never be afraid of approaching somebody for the information you need.

What advice would you give –- if any -– to those looking to start, or transition into, a career in technical writing?

I wrote a post about this, called 7 Steps to Getting a Job in Technical Writing. The first step is to get a degree in something related to technical writing, usually a degree in English with an emphasis in technical writing. If you have a writing degree, great. But you need to ground yourself in the basics so you know what you’re doing.

After that, get some real experience doing technical writing, because you’re not going to find a job unless you have actual samples of projects you’ve completed. Learn some of the tools. Put together a portfolio. Start a blog. Move to where the jobs are. And volunteer in the STC.

I elaborated on each of those steps in the post. I’m giving a talk about these points later, on October 8th, and I’ll definitely record that. But basically, those are the steps I would suggest. And of course it depends where you are in your career. If you already have a career, the steps to transition into technical writing may be different. My seven steps are intended for students still in the university.

How would you describe your duties on the job? What might a typical day at work for you “look” like?

The typical day thing is hard because days aren’t typical. You do a lot of different things at different points in a project. You may go through like a writing phase, a learning phase, a design phase, a configuration phase (especially with context-sensitive help). I don’t chunk out my days at one-hour intervals doing all these different things. I get in the mode of doing something and spend half the day on it.

For example, here’s how I spent yesterday. First I had to review a handful of presentations for an internal conference. (Sometimes you have to review materials others create.) Then I spent the latter part of the day configuring a relationship table, which is a set of related links for topics. I made sure each page on the user interface had context-sensitive help. I realized that some of the pages I configured weren’t the right pages that I wanted to show up in the context-sensitive help, so I had to add some help topics.

I also spent some time troubleshooting a technical glitch. Whenever somebody clicked the help button, it opened a new window, which is what I wanted, but if they didn’t close the help window and instead clicked the help button again, a new window appeared on top of the previous window, resulting in multiple help windows. So if they clicked the button five times, they would get five different windows open. I tried to figure out how to fix that. Since I don’t really know much JavaScript, it was a little hard. I can code a JavaScript link, but to try to sit there and troubleshoot an advanced JavaScript problem is over my head.

That kind of troubleshooting is typical — trying to get your help to look right, whether it’s troubleshooting something in your help authoring tool or your page layout tool, or whatever — is common. You can spend a lot of time troubleshooting various problems.

What software programs or other technology do you use on a regular basis?

Tools are always a hot topic, but I have decided on MadCap Flare as my help authoring tool, Adobe InDesign as my page layout tool (which I use for shorter documents), and Snagit for screenshots. When I create video tutorials, I use Camtasia studio. I also work with SharePoint. Sometimes I’ll use Photoshop if I’m doing something advanced with graphics. I’ll use Visio if I’m trying to illustrate a workflow or something. On my blog I of course use WordPress. I use most of those tools quite frequently. (I don’t have WordPress at work, but I’m hoping to get an installation going and try to do something there.)

Could you describe a recent challenge you’ve been presented with at work and how (if possible) you were able to overcome it?

I recently discovered that somebody was planning to send out a guide for working with Joomla to build a country website. The guide was just written by a non-writer, somebody who was more of a coordinator. The guide wasn’t very good, and I basically said that. I said, Look, this isn’t good. The guide needs to be rewritten. The instructions aren’t in numbered steps. A lot of details are missing. It doesn’t look very professional. And so of course I ended up having to rewrite it myself, and it took about three weeks. But I felt pretty good about the end result, and I think overall the people using those instructions will be grateful.

It can be a constant challenge to get people in your organization in the mindset that technical writing needs to be done by the technical writing team rather than the project manager or intern. When you have a large organization, it’s easy for people to be unaware of your team, unaware of what you do. They don’t want to be burdened by your process. They sometimes want to just write it themselves in Microsoft Word and get it done — and they don’t realize that it’s terrible. It’s a constant challenge trying to get people in the mindset that the documentation — the manuals, the instruction, the video tutorials, quick reference guides — need to be done by the tech comm department.

What is one of your favorite success stories from working in technical communication? Anything substantial or particularly rewarding that you’ve been able to work on thus far?

I think the way you determine whether something is successful is if you release an application and it takes off. You may just be the technical writer on a team, but you’re also contributing other things. You’re contributing towards usability, you’re interfacing with customers, you’re making sure that things work right. You’re part of an entire team that is building and producing software. If the software is successful, you’re part of that success. We had an internal application at my work that was really successful and it did take off and lots of people started to use it. If you’re not bombarded with a bunch of questions by users, if they’re able to search and find the answers and learn for themselves, that’s also a success.

Do you pursue any continuing education opportunities – either required or optional – for your job? If so, what type(s)?

I do try to keep up with blogs, articles, conferences, and other types of published information. I definitely try and keep up. But official courses? No. There’s a sense of distrust that a lot of people in the industry have about people in the academia. Whether academics are out of touch or not, I don’t know. I’ve seen studies debunking that myth. I’ve also heard academics say they feel out of touch with the current issues in the workplace. So going back to the university to learn how to improve in the workplace isn’t always an idea that’s appealing.

How do you feel that your education did – or perhaps did not – prepare you for your current job? Are there any courses you wish you would have taken or skills that you should have mastered but didn’t? Any regrets?

I have a degree in English and a degree in creative writing. The second one is a Masters degree, the first a Bachelors. Neither prepares you a whole lot in terms of what you’re going to do. You could say that the analytical abilities to assess and comprehend larger structures of text and manipulate them is helpful to you as you organize help topics in a large project. So sure, there’s crossover. In an English degree, you definitely learn grammar and how to write. In fact, just having the love of writing is helpful. But really, as a technical writer, you’re not writing essays, you’re not doing creative writing. You’re not doing literary analysis.

Are these activities truly helpful in preparing you for technical instructions? A little. You need a basic command of the language and good common sense. But if I were doing it again, I would have probably double-majored in English and graphic design or computer science.

Blog Sponsors

How to Get a Job in Technical Writing — A 7-Step Guide for Students

Tom Johnson — Tue, 22 Sep 2009 12:39:55 +0000

If you’re a college student looking to become a technical writer after you graduate, you face a formidable challenge: you can’t get a job without experience, and you can’t get experience without a job. Especially in a competitive job market, getting a job as a technical writer directly after you graduate — without a foundation of previous jobs, experience with a handful of tools, and an impressive portfolio — can be especially difficult. However, if you follow these seven steps, which are not easy, not something you can do overnight, you will find a job.

Note: In a couple of weeks I’m giving a presentation to Brigham Young University Idaho students with this post’s topic (getting a job as a technical writer). My presentation is part of their annual professional writing conference. Oct 09 update: Here’s a recording of the presentation.

Last week on Twitter I asked my followers what advice they would give to students on finding a job in technical writing. Here are the responses:

plaindocs: Show that you are interested in learning about everything!

seeb: don’t know if i would advise students on a job on technical writing – would be technical communication..more encompassing!

floldun: Advice: emphasize what you can do for the company, and know what they need (read and ask around), instead of what you want.

AndreaJWenger: Students: identify your one greatest strength (writing, tools, tech, or whatever) and promote yourself as an expert. #techcomm

mleeuw: Networking gives job seekers the best chance of finding jobs with the proviso that one needs to be in the right location.

kirstyt: Network. Meet tech comm managers. Got both my gigs through meeting the mgr elsewhere/knowing other tech comm staff.

FeliciaRenee: Do as many internships as you can before graduating.

heidilhansen: A tip for students is to apply at Tyler Technologies, but seriously online portfolios w/samples is best & knowledge of TC field.

larry_kunz: One piece of advice for #techcommstudents: Always be curious, like a reporter or a detective.

altmilan: start by asking yourself “how do people get hired?”, and then asking yourself how one goes about finding this out.

jaycie622: Advice to students: Persevere! Keep putting out resumes and don’t give up hope.

Wordtree: Take an existing guide and rewrite it so you have something for your portfolio.

skry: I began tech writing via science journalism. Built a writing portfolio there. Offered to write software doc for coders.

All good advice on how to get a job. Some of the advice is reflected in my recommendations below. Here are my seven steps for college students to get a job in technical writing.

Step 1. Learn the Basics of Technical Writing

Before you can create a stunning portfolio or market yourself to companies as a technical writing intern, you need some grounding in the basics. If you’re in a college that offers a degree in technical writing (usually a degree in English with an emphasis in technical writing), by all means do it. If I were doing it over, I would actually double-major in English and graphic design, or English and computer science. Some students prefer to get domain knowledge, such as in accounting or engineering, and then supplement that knowledge with writing skills.

Whatever your situation, learn the basics of technical communication. For starters, learn how to write well. Learn grammar. Learn to analyze an audience, create personas, approach documentation from a task-oriented perspective. Learn to number your steps, keep your topic titles parallel, and be brief and concise. Learn to write useful instructions rather than obvious statements. Learn when to use screenshots and when to omit them. Learn the strengths and weaknesses of different help formats, such as wikis versus quick reference guides versus video tutorials. You can’t do anything without first grounding yourself in the fundamentals.

You may not learn all of these concepts in your program. If not, you can supplement your program with some instruction from professionals in the field. The Society for Technical Communication (STC) has an excellent certification course from well-known professionals. You can also read the Intercom and Technical Communication Journal. If you don’t have money to join the STC, connect with someone who is a member and ask to borrow back issues. Read blogs and books published by professionals in the field (here’s a list of foundation books). However you do it, get a solid education. This is critical before you can move forward.

Step 2. Get Real Experience Doing Technical Writing

The second step in getting a job in technical writing is to acquire some real world experience by actually doing technical writing. At many companies, employers want someone with experience because the employer plans to point you in the right direction and then let you work independently, rather than providing training. They want to be sure you can manage any situation, and if you don’t have experience in a corporate environment or know what you’re doing, employers may not trust your ability to get the job done.

During your summers as a student, volunteer as an intern at an IT company. Many times positions may not be advertised, but you can join your local STC chapter and ask other writers if they would accept some free labor from a volunteer for a few months.

If your professor assigns you to do documentation projects, see if you can find real projects at actual companies. Again, through your STC network or other contacts (such as through listservs or local companies), you can connect with professionals who can open opportunities for you to do real documentation.

Connecting with someone you know (or a chapter mentor) is the best route, because he or she can give you direction and feedback. However, you can also get real experience on your own. Many open source or community-based projects have need for documentation. Here are a few:

When you work on one of these projects, you may find that it’s not a typical essay assignment. It will require several weeks of time before you can understand the application, determine an approach that will work with the audience, figure out the tools you’re using, and create a finished product.

Step # 3. Learn Some Tools

Tools are a major part of a technical writer’s world. You’re in charge of designing, laying out, and publishing all your content. Most employers want to you to know certain core tools, or at least to be tool savvy enough to learn their tools. Here are the four types of tools I recommend that you learn.

Learn a help authoring tool, such as Madcap Flare, Adobe RoboHelp, or Author-it. When you document a complex software application, you usually need a powerful help authoring tool to create an online help file. Of the three, RoboHelp is probably the easiest to learn, but there is no industry standard now.

Second, learn a page layout tool, such as Adobe InDesign, Microsoft Word, or Adobe Framemaker. I use page layout tools when I’m creating quick reference guides. Depending on your technical writing role, you may be creating pamphlets, brochures, newsletters, or short guides with a lot of design elements. The page layout tools give you a lot of control over the display, position, and layout of your text and images. (Okay, maybe not Microsoft Word, but you can do some page layout with it.)

Third, learn a graphics tool, such as SnagIt, Photoshop, or Illustrator. You’ll need a graphics tool to capture and modify screenshots, add arrows, or create diagrams showing concepts. SnagIt is the easiest to learn and will probably work for most situations. Try to learn SnagIt’s quick styles.

Finally, learn a video capture tool, such as Camtasia Studio or Adobe Captivate. Although video tutorials aren’t always common help deliverables, when you add this to your mix, you significantly expand what you can offer. Video tutorials are also how a large number of people learn software.

Technical writing positions aren’t always the same. You may be in a company that uses DITA, or one that has a content management system in which you author content, or a company that has some other method for authoring (perhaps they use Visio heavily). Even if you don’t know the exact tools the employer wants, if you have technical aptitude with a variety of tools, such as the ones I listed above, that aptitude may be enough to convince the employer you’re qualified.

To learn tools, go at a slow pace. Try learning them an hour a day over the course of several months. You don’t need to master the tools; just be somewhat familiar with them and be able to produce something using them.

Some students have asked whether they should substitute open source tools for the commercial tools (for example, Gimp instead of Photoshop) because open source tools are the only ones they can afford. I do not recommend this substitution. First of all, it takes a huge investment of time to learn some tools. Second, some employers are so bent on you knowing a particular tool, it’s not worth the risk to put so much effort into a tool they probably don’t use.

Step 4. Put Together a Portfolio

The portfolio is the most important work you can put together when looking for a job. A good portfolio can make up for years of experience. You can have 20 years of experience as a technical writer, but if your portfolio is uninteresting or doesn’t sell yourself, you won’t get the job. Conversely, if you have just 1 year of experience but have an impressive portfolio, you might have a better chance of getting the job.

There’s a reason that putting together a portfolio is step four. You can’t put together a good portfolio until you know a bit about technical writing. For example, if you just jump right into the portfolio and start creating samples that show a full screenshot with each step in a generic Microsoft Word document, your portfolio will be poor and will work against you. You need some theoretical grounding before you can create worthwhile documentation. You need real projects before they are convincing. And you need some knowledge of industry tools before you can create an attractive-looking design.

When putting together your portfolio, keep the following best practices in mind:

Include 10-15 samples, covering a variety of formats and writing situations. For example, include quick reference guide, a user guide, online help file, video tutorial, newsletter article, release note, magazine article, and any other format you can think of (including some college essays, perhaps).
Provide a web-based version of your portfolio. Employers may want you to leave the portfolio with them, and some may require you to submit the portfolio through email, so you’ll need a link to a website with a digital portfolio. I recommend a self-hosted WordPress site for this. See “Developing a Web-Based Portfolio” by Steven Kendus for more tips.
Provide a brief paragraph introducing each work, the situation, purpose, and tool you used to create it.
Make sure your portfolio samples are free of typos or grammar errors. The employer won’t be able to review the accuracy of your steps (which is probably the most important component of help). What’s left is to focus on the way it looks and reads. Make the layout professional. Clean up the writing so that it’s flawless and graceful.
Include your transcript in your portfolio. Employers will be curious to learn what courses you’ve taken that qualify you to be a technical writer. Additionally, if you’ve done well in these courses, it will show your aptitude.

Most likely you won’t have a ton of writing samples. If you completed step 2 (“Get Real Experience Doing Technical Writing”), you’ll have a few samples you can show. But you probably need more. Here’s a great tip from Barbara Block in “Finding That First Job.” Can you document how to do your job? (You have a job, right? ) Are there concepts and tasks to master? Steps to perform for each of the tasks? Your current employer might appreciate this little handbook you create, and it can be a perfect addition to your portfolio.

When you go to an interview, always bring a portfolio of your work to leave with an employer. (Don’t expect to really get these back, by the way.) The employer will want to peruse your writing both before and after the interview. Know also that a portfolio provides perfect talking points during an interview.

When I was looking to break into technical writing, I brought a portfolio with about 15 samples to the interview. I later learned that it was an article I wrote about protein that impressed one of the interviewers (who had a PhD in biology). I also had a sample online help file that I created with RoboHelp as well. I beat out 5 other candidates without having any actual technical writing experience. Trust me — the portfolio is key.

Step 5. Start a Blog

Next to a strong portfolio, an engaging blog can also win over the hearts of your employers and get you a job. I cannot restrain my enthusiasm here when I talk about blogs, because in my experience, having a good blog can be your ace card that wins the game for you.

A few weeks ago, a friend of mine at another company interviewed several candidates for a position. He searched for information about the candidates online and was startled to find that almost none had an Internet presence. Zilch. It’s somewhat creepy, in this day and age, with Twitter, Facebook, blogs, and dozens of other social media sites, to find that someone is isolated from all of them, a stranger to the world wide web.

While there are various social media options, a constantly updated blog is the key one. Twitter can just be chatter, but your blog shows depth and engagement. A blog – focused on your profession – can showcase your creativity and knowledge. A blog brands you as an industry expert and reveals your awareness about the latest trends and topics in the field. Employers love to review blogs because it allows them to get to know you better. You’re no longer a piece of paper sitting in a stack of other pieces of paper. You’re a lively writer with an engaging mind and a bit of style.

Penelope Trunk, one of my favorite bloggers, writes a blog called the Brazen Careerist, centered on career advice. In her post, “Blogging essential for a good career,” she explains,

A blogger puts himself out in the world as someone who is interesting and engaging — just the type of person everyone wants to meet.

In another post, she writes,

The reason that people who blog have great careers is that bloggers are always thinking about issues in their industry.

She’s right. When I meet people at conferences, bloggers are always interesting. For example, I remember meeting Darren Barefoot, a prolific Canadian blogger, at Doc Train West a couple of years ago and thinking how smart and approachable he seemed.

Your blog will portray you as one always thinking about issues in the industry, one who keeps up with the latest trends. If your style is friendly and conversational, employers may also perceive you to be a good fit. These are key qualities that you want a company to think about you, and it rarely comes across in a resume.

Robert Scoble, practically a public figure on the web, explains:

Your blog is your resume. You need one and it needs to have 100 posts on it about what you want to be known for. (“If you are laid off, here’s how to socially network“)

Scoble recommends that you only blog about what you want to be known for, or the direction you hope to go. For example, if you want to drive cabs, let cabs be the dominant focus on your blog:

If you want to drive a cab, you better go out and take pictures of cabs. Think about cabs. Put suggestions for cabbies up. Interview cabbies. You better have a blog that is nothing but cabs. Cabs. Cabs. Cabs all the time.

There are about 20 reasons why blogs can help you in your job search. Recently a student in college wrote me to ask for advice on finding a job. Motivated by my blog, he had started a blog as well. I encouraged him to keep up with his blog. About two weeks later he wrote,

I was contacted a week ago by an IT company, World Wide Technology, Inc., and offered an intern position! Before the interview process, one of the managers took the time to look at my blog. He told me that he was impressed with what I was trying to do with it, and he found it interesting. We ended up talking for at least twenty minutes after the interview about communication-related concepts. It was the best interview of my life. Just earlier today I received a call, and I was offered the position! — Brian Kennedy

To recap: When employers read your blog, they start to perceive you as knowledgeable. When you have several posts a week, they perceive you as passionate. If you have an engaging writing style, you’re perceived as likeable. When employers google your name, your blog usually appears at the top of the list. Your blog helps you almost every step of the way.

Now, one warning about blogs. In order for blogs to make a positive impact, you have to steer clear of the following pitfalls:

Don’t post inappropriate pictures of yourself
Don’t express views contrary to your potential company’s views (for example, avoid incendiary political posts; actually, just avoid political posts)
Keep your blog focused on the field of technical communication
Avoid badmouthing previous or current employers
Don’t use abbreviations such as gr8 for great or cu for see you.
Don’t blog with sloppy grammar
Don’t write excessively about your job search, because it tends to look a little pathetic.
Don’t blog with the idea that no one will find what you’re writing

Always remember that blogs aren’t anonymous. Blog responsibly by exposing your full identity. Include your blog on your resume, right next to your contact information. Remember, your blog is an asset not a liability. You want it to promote it because it brands you as an expert.

Step 6. Move to a Tech Hub

You’re young. You’re almost out of college. Where are you going to live? If you want a job in technical writing, you probably need to live in a major city. Most technical writing jobs are located in places where there are IT companies. The more IT companies, the more technical writing jobs.

Indeed.com shows you trends for IT jobs by location.

Locations where the most IT jobs are posted

It’s no secret here. The top locations are New York, Atlanta, Chicago, Houston, D.C., Dallas, San Francisco, Boston, Austin, and Los Angeles — all major cities.

Last year, Doug Davis wrote an article about where the most technical writing jobs are. He identifies a similar list of cities:

San Jose, California ( Silicon Valley)
Boston, Massachusetts
Seattle, Washington
Washington, D.C.
Minneapolis/St. Paul, Minnesota
Chicago, Illinois
Atlanta, Georgia
Denver, Colorado
New York, New York
Houston, Texas
Dallas/Ft. Worth, Texas
Philadelphia, Pennsylvania
Portland, Oregon
Los Angeles/Anaheim, California
Raleigh/Durham/Chapel Hill, North Carolina (Research Triangle)

The most recent STC Salary survey database (from 2008) maps a geographic distribution of technical writers and finds the following:

The states with the most technical writers are California, Texas, Massachusetts, Virginia, Michigan and Maryland. Only Wyoming seems to have not reported technical writers.

Where the technical writing jobs are in the U.S.

According to U.S. News, the 10 best places for tech jobs are Atlanta, Boston, Houston, Huntsville Alabama, New York, Phoenix, San Diego, San Francisco, Seattle, and Washington D.C.

I recommend moving to a major city that appeals to you. If you’re really adventurous, you could even move to India. But seriously, location matters. I know that I’ll never live in a rural area such as Wyoming because there aren’t many technical writing jobs there, as beautiful as Wyoming is.

Moving to a new location, however, is harder than it looks. Rarely will a company hire you from afar. When I was living in Florida looking for a job in Utah, the remote location turned recruiters and employers off immediately. Fortunately my wife’s family is in Utah, so while I was vacationing in Utah, I interviewed for a handful of positions here. Then it wasn’t such a problem that I was currently residing in Florida, and a good company eventually offered me a job.

Note: If you think moving to a new city is difficult fresh out of college, try uprooting yourself with three kids and a mortgage payment on a house in a recessed economy. Also, forget about landing that contract position in another state and working remotely from home – it just doesn’t happen with entry-level writers.

However you manage to do it, go where the jobs are.

Step 7. Volunteer for a Position in the STC

If you really want to get serious about moving your career forward, volunteer to be president of your local STC chapter. When I did this at the Suncoast chapter, it did a few things for my career that I didn’t expect. First, it made me extremely visible. Suddenly I was the one making announcements on the listserv, greeting everyone at meetings, organizing and planning programs.

Second, being president also put me in contact with more than a dozen professionals in the area who befriended me and gave me good advice. I’m thinking especially of my friendships with Mark Hanigan, Pam Treme, Mark Lewis, Karen Bachman, Becky Siebenthaler, Kelly Schrank, and about a dozen other people who I got to know precisely because of my participation in the STC.

The STC won’t necessarily find you a job, but it will put you in contact with professionals in your area who can let you know about open positions, recommend you, and give you advice about companies and career paths. Probably the greatest value of the STC, above all else, is the networking/friendship aspect. Not just networking with other professionals, but with professionals in your area.

To get involved in the STC, don’t just show up and ask if anyone knows of any jobs, and then leave when you find out there aren’t any. This happened more than a dozen times while I was Suncoast president. If you do this, your involvement in the STC will backfire. It’s through service that you build relationships. And those relationships are what guide you toward fruitful paths in your career.

Conclusion

To recap the seven steps:

Step 1. Learn the Basics of Technical Writing.
Step 2. Get Real Experience Doing Technical Writing
Step # 3. Learn Some Tools
Step 4. Put Together a Portfolio
Step 5. Start a Blog
Step 6. Move to a Tech Hub
Step 7. Volunteer for a Position in the STC

You can’t accomplish any of these steps overnight. But if you’re an ambitious student, with a couple of years left in your program, you can line things up so that when you graduate, you aren’t sitting at your parent’s house without a job. Instead, you’ll be working away at your first job as a technical writer, engaged in a new project, learning new tools, interacting with colleagues, and blogging about it every night.

Blog Sponsors

Introduction to Technical Writing (podcast)

Tom Johnson — Wed, 25 Mar 2009 01:00:33 +0000

Download MP3 (to download, right-click and select Save Target As)
Length: 43 min.

In this podcast, I talk with Ricardo Amigo, a translator and podcaster in Mexico City and Costa Rica, about the field of technical writing. This podcast is more of a reverse interview. Instead of me asking the questions, Ricardo interviews me. The general topic is the field of technical writing, including all of the following:

My path into technical writing
Structured authoring
XML and DITA
Information architecture
Usability — for documentation and software interfaces
Publication formats for help material
Breaking into technical writing
Tools for help authoring
The growth of technical writing
Creativity and technical writing
A typical day as a technical writer
Translation techniques and tools
Simplified technical English

Ricardo’s company is called Amigo Audio, and they principally do translation. For example, if you need your manual or software interface translated, Amigo Audio can help. You can contact Ricardo Amigo at sinpapel@yahoo.com. Additionally, you can read more about their translation services at Amigo Audio.

Blog Sponsors

WritersUA – The WritersUA Tools Survey – Tools

Tom Johnson — Fri, 27 Feb 2009 17:32:30 +0000

WritersUA – The WritersUA Tools Survey – Tools.

Blog Sponsors

Podcast: Make Your Help Indispensable, Safeguard Your Job

Tom Johnson — Sun, 01 Feb 2009 04:58:36 +0000

Download MP3 (to download, right-click and select Save Target As)
Length: 30 min.

In this podcast, I talk with Mike Hughes, second vice president of the STC, about his latest UXMatters article, “Straight Talk: Surviving Tough Times as a User Assistance Writer.” We talk about how to make help more valuable, more worthwhile and user-focused, so you don’t lose your job when companies begin laying off employees based on lack of value.

Here are a few other topics we cover in this podcast:

Where help must appear to be used, and how to pitch it to the user
Why documenting everything is sometimes the worst thing you can do
What it means to make your help “a mile wide and thirty seconds deep”
How identifying points of pain and information gaps can help you avoid writing obvious instructions
Why tools and technologies can distract you from the content

About Mike Hughes

Mike is a seasoned technical communicator with 20 plus years of experience. He currently works for IBM Internet Security Systems as a user assistance architect. He holds a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. Mike also contributes regular columns to UX Matters and writes a blog at http://user-assistance.blogspot.com.