How to Avoid Extinction as a Technical Communicator

by Tom Johnson on Jun 15, 2009
categories: technical-writing

In a career development workshop at the TransAlpine Conference in Vienna, Ellis Pratt, one of the founders of Cherryleaf, argued that technical communicators may eventually become extinct if they keep using the same methods and formats to deliver information.

Although there will always be a need for people to explain technical material non-technical people, Ellis said, others may be doing it instead, through the formats users prefer. To survive, technical writers may need to morph into content strategists, managing the information in a systematic way rather than merely creating it.

Ellis started by showing a thought-provoking video from Michael Wesch called "A Vision of Students Today." In the video, students explain why the traditional educational model is outdated and at odds with the way they learn.

Rather than reading textbooks, today students learn through text messages, virtual chats, Facebook updates, interactive media, blogs, wikis, virtual worlds, collaborative efforts, read/write behavior, forums, podcasts, videocasts, and Google searches. The old book-reading, classroom-lecture model of learning has fallen by the wayside. It's just not how students get the answers they need.

Although students usually aren't the target audiences of our applications, the same concept applies to software users. The long manual and online help are declining formats few want.

Ellis relayed an observation from Tony Self, a technical communicator who organizes conferences in Australia. Self says if you look at an online help file from 15 years ago, it looks about the same as a help file produced today. This stagnancy of innovation in the technical communication community is frightening.

Whereas Web technology continues to move forward with daily developments—from Web 2.0 to Bing to Google Wave to RFID technology that scans and displays information in real-time wherever you are—technical communicators are doing the equivalent of writing textbooks for people who no longer read them.

Ellis predicts that unless technical communicators make some changes, they're not going to be around much longer. The role of teaching people how to use technology will be passed on to others delivering it in the formats the audience prefers, expects, and learns from.

But rather than postulating any kind of new media delivery of technology, such as wikifying all your content, or providing instant support through Twitter, or porting everything into Facebook, Ellis recommends that technical communicators solve a different but related problem: managing the diversity of information.

Because information is fragmented and scattered across a dozen different types of media and sources—RSS content, content management system content, training content, engineering content, support center content, user-generated content, web content, marketing content—a need is emerging for someone to manage it all.

Ellis thinks that if writers can evolve to fill more of a content strategy role, in which they manage the fragmented information, they will survive. Rather than being a "technical communicator," their roles will more likely be content wrangler, information strategist, user-generated content editor, information assets director, and content use analyst.

Ellis said the idea of Content Strategy and the new role technical communicators must play is something he learned in part from Rahel Bailie and her Summit presentation, "The New Face of Documentation."

My Thoughts

Ellis and Self are right about the lack of innovation among the formats for technical communication deliverables. We need to evolve. The problem is that there's no compelling replacement for the traditional formats. A lot of good possibilities exist—wikis, blogs, interactive multimedia—but none seems to be the online help / manual killer.

Another problem is that many of the web technologies aren't available behind the firewall, which is where much of technical communication occurs. PHP and MySQL (required for almost every Web 2.0 blog or wiki technology) are readily available online, but these open source technologies usually aren't robust enough for large-scale companies who require MS SQL, Oracle, or other technologies. The Web 2.0 technologies available behind the firewall usually just include SharePoint 2007. You usually can't take advantage of cool web technologies unless you're actually on the world wide web.

Personally, I have been trending towards quick reference guides (anywhere from 1 to 8 pages) and short video tutorials (2 to 4 minutes) as my core deliverables. I also create an online help as a searchable repository of answers, but I create it with the idea that it will be searched, not necessarily navigated for information. Single sourcing the full online help to a printed manual is just another step, so I don't omit it, but I don't promote it much either.

Overall, I'm excited about the new DITA publishing capabilities of Flare 5, because it means you can push the content out to additional formats more easily. You can convert DITA to the Confluence Wiki format, DITA's XHTML target to WordPress, DITA to InDesign, DITA to web pages, and other formats.

The key to solving the problem of information fragmentation is to get the content into a format that is versatile enough to be pushed to any format. If you can keep the original source in one location and just export to different formats for your audience, letting users choose based on their learning style and preferences, then you could perhaps solve some of the problems Wesch raises in his video. (The exception of course is video and multimedia, which you can't simply output to.)

As for switching from content creators to content managers, I'm still a bit skeptical about this. Except for public, web-based, multi-author, open-source software models, I just don't see a lot of users contributing help content to the corporate-grown applications (except for the big ones, such as Microsoft Office). Most companies want their help content to look attractive and be accurate, and few project managers believe users can and will fill that gap if you take away the technical writer.