Technical Communication 2012: Our Biggest Challenge Is Thinking Differently About Being Different
Scott Abel, The Content Wrangler
The field of technical communication is going through a period of significant change. Several of these changes are challenging traditional ideas about the role of technical communication — and technical communicators — something that makes the change-adverse in our industry nervous, to say the least. But, like it or not, change is taking place all around us. Organizations of all sizes are adopting new approaches to communicating with customers.
Some are adopting structured information standards (think XML, DITA) and using component content management systems to help them dynamically deliver documentation to those who need it, when and where they need it, increasingly, on a wide variety of mobile devices.
Others are socializing their product documentation, pushing it to web-based communities where customers can interact with it, augment it, improve it, comment on it, and share it. In some situations, customers are encouraged to (gasp!) create it.
And still others are getting rid of traditional forms of documentation altogether, or drastically minimizing its footprint, opting instead to create engaging, interactive customer experiences by leveraging photographs, 3d images, infographics, video simulations and other rich or augmented media in lieu of user manuals and online help systems. And, they’re delivering this digital content in eBooks, in apps, and via the social web.
At the recent Adobe Enterprise Technical Communication Summits (Boston and San Jose) I was asked to deliver the keynote address. Instead of focusing on DITA topics, video documentation, or EPUB (eBook) files, some of the many useful content types the Adobe Technical Communication Suite helps TechCommers create, I decided to focus on the real problem. We allow our traditions to get in the way of our productivity and advancement by avoiding the adoption of manufacturing principles into the content production lifecycle. We cling to the “we’re different” line of thinking, pretending that it’s true by hiding behind some fictional wall that separates technical communicators from everyone else whose job it is to create products. We even manufacture the need for “certification” programs that will further differentiate us from other types of communicators not included in our specialized domain.
The way I see it, the “we’ve always done it that way here” approach to creating documentation and training materials is preventing us from meeting the goal of the customers we serve: getting the right information, to the right people, at the right time, in the right language, on the device of our customers’ choosing. Our outdated ways prevent us from operating efficiently. By continuing to cling to traditional ways of creating content, we fail to demonstrate our true value to others — leading to technical communication being thought of as a necessary evil, a cost center with little value, at least when compared to marketing and sales content. We hold on to outdated notions of what’s important based on ideas espoused by old school academic types and others (you know who they are) with a stake in maintaining the status quo.
The irony is, customers increasingly use the web to research products before they make a purchase decision. And yet, most product information is stored in silos (online help in our products, support content in our knowledge centers, marketing on our product websites and newsletters, training on our “customers only” extranet). Because much of that content cannot be seen by search engines, it isn’t working for us as a magnet, drawing people in to interact with us. And, even when the content is exposed to the web search engines, it’s nothing more than static content, lacking in the rich interaction that users have grown to anticipate — even desire — on other places they search for answers on the web.
Add to the challenge that seldom do the people involved in the creation of customer-facing content work together to create a unified customer experience, opting instead to create content in the way their department prefers to do so (usually the most inefficient way possible), without any concern for the customer experience. This problem isn’t limited to our efforts. It’s a bigger problem, something most enterprises have yet to acknowledge. But, the costs of such inefficiency (conservatively estimated at over $1 billion in waste annually in some industries) is gaining some attention.
When organizations showcase their technical communication products on the web, in the way that Autodesk and ExactTarget do today, they experience many benefits, including deep knowledge about their customers that allow them to make valuable incremental improvements to the customer experience.
Organizations like iFixit.com are taking that approach a few steps further by creating technical documentation that is designed to sell products. I bet there’s a product manager in nearly every organization that would love to understand how technical communication can be leveraged to sell content. Just ask one.
Regardless of how your organization decides to create, manage and deliver content to your customers, it’s critical that you stop pretending to be different from those who build the products and services you sell. Customers only care about differences when they negatively impact them. They don’t care how your organization is organized or why your product marketing is totally disconnected from your product training, customer support and technical documentation. But, you should. And, if you’re like me, I bet you do.
If there was one challenge technical communication professionals should work to overcome in 2012, I believe it’s to rid our industry of the notion that we are somehow different. The smart ones among us will work to partner with marketing, develop relationships with product managers (and others concerned with sales), and find ways to showcase our values that don’t have much to do with our mastery of our native language, punctuation and grammar — all things wee learned in high school.
We need to find ways to expand our sphere of influence by learning from people outside our industry. Just once I’d like to see an entire day of learning at our industry conferences presented by people who don’t write technical documentation for a living. And, conversely, I think we ought to be sharing our knowledge and experience at other types of communication events. Chances are the approaches we use — single-sourcing, multi-channel publishing, content reuse, socially-enabled support and the like — might solve problems other communicators are now struggling to overcome.
The real value we provide is not our mastery of the style guide. Rather, it’s our ability to impact the customer experience in positive ways. When done right, our efforts can lead to improved efficiency, reduced costs, enhanced findability, a sense of community among current customers, and a new revenue stream that leads to increased sales.
What do you think the biggest challenge for technical communication is today? I’d love to hear your thoughts. Leave a comment and let’s discuss.
Similar Posts:
- Web 2.0 101: Understanding Web 2.0 and Its Impact on Technical Communication
- Scott Abel, The Content Wrangler, On Adobe Technical Communication Software, Silos Busting, And Convergence
- Adobe Announces Technical Communication Suite: Four Tools That Work As One
Scott-
This is an excellent article, and a positive affirmation that the future of technical communication (or whatever we end up calling it) is exciting.
I feel sad when I see core communication in our industry relying on mailing list technology.
Newcomers expect instant or on-demand information, and embrace social media. They will quickly make the old guard irrelevant if the old guard does not embrace new techniques, strategies, and tools that support a change in information consumption.
-Arnold
Hi Scott,
I agree wholeheartedly that tech comm as a profession has been living on an island for years, and that it is past time to join the mainland, to cease imagining that we sing solo and instead find our place in the choir.
I agree also when you say “We allow our traditions to get in the way of our productivity and advancement by avoiding the adoption of manufacturing principles into the content production lifecycle.” But I would point out that the current crop of content management tools and practices, including DITA, are very much stuck in tech comm’s past and by and large have not brought manufacturing principles into to production of content, but continue to do most of the important operations by hand and by eye.
As I recently blogged, structured writing is not desktop publishing plus angle brackets (http://everypageispageone.com/2011/12/12/structured-writing-is-not-desktop-publishing-plus-angle-brackets/), but that is still very much the approach that many of these tools take to structured writing. Most content remains handwoven (and thus insular) even when the loom is a CMS. What we need to get to, to truly bring manufacturing principles into content creation, is a focus on creating highly reliable content data that can be organized, linked, and published automatically without human inspection or intervention.
HI Scott
I broadly agree with you. In fact I’ve submitted an article along these lines for the Feb ’12 edition of Intercom magazine.
However, I take issue with you on one aspect. When we conducted a series of interviews with UK Documentation Managers earlier in the year, they told us the biggest resistance to change came from *outside* the Tech Pubs Department. Senior Management often had a particular view of user documentation, in terms of its scope and the way it looked. Some didn’t want it to be too good, as it could reduce the number of Support or training contracts!
We found the most innovative teams were in successful companies where the Tech Pubs department was left to do its own thing. The cost of Tech Pubs was so minimal, in comparison to other departments, that they allow the Documentation Managers freedom to be innovative.
I suspect this will only change once Senior Management see an innovative example elsewhere and decide ‘we should have one of those’.
Ellis: That’s an interesting angle. And, I suspect in some circles, it’s true. But, certainly in consumer product circles (where training contracts aren’t generally needed) this type of scenario isn’t the driver for the poor documentation. Again, I see where competing interests could cause such a desire for “not too good” documentation.
And, I wholeheartedly agree….”we should have one of those” is a powerful driving force for change when it comes from upper management.
Where are those upper management folks hiding again? I think it’s time we had a chat.
Good article that hits on a point that I made in a lightning talk at Lavacon, namely that the trend towards more and more complex tools and techniques may have made us better at producing output, but it hasn’t made us better at creating useful content, and it has done nothing to help us get closer to our engineering, marketing, and sales colleagues.
Regarding Ellis’s comment and Scott’s reply:
I agree that management can be a problem — I have seen situations where management was clear that all they wanted was a minimal effort, Though, in the case I’m thinking of, it was simply from being cheap, short-sighted, and dim, rather than because of some notion about support or training contracts (p.s., not any of the companies I’ve worked for:-).
However, I don’t think that diminishes the point that tech comm has isolated itself (and allowed itself to be isolated) way too much from other parts of the organizations it serves. We have become so wedded to our traditional deliverables that even when we branch into new media, we’re just pouring old wine into new bottles. Working in a closer partnership with engineering, marketing, and sales is one way to help break out and address some of the concerns Scott outlines here.
[...] Scott Able has recently pointed out, technical communication is going through a period of great change. Sometimes the greatest change is the hardest to see. But I suspect there is no greater challenge [...]
[...] Scott Abel on technical communication’s greatest challenge for 2012: thinking differently about being different [...]
[...] Abel, The Content Wrangler, posted a terrific article this week that got a lot of attention from the technical communications community. Looking ahead to [...]
I completely agree that the profession is in a period of serious flux and we need to break up our marriage with what Richard aptly called “traditional deliverables”. Following with the relationship metaphor, it’s time we started to see other people. Actually, we should’ve done it a long time ago.
Both Richard and Mark have talked about tools in their posts. I see this reliance on tools as one aspect holding the profession back. With respect to tools, are they a form of technological determinism that in some way limits our thinking? The output or artifact that the tool creates can end up being the most definitional part of the process. It tends to overtake the bigger picture of the communication process: What the audience needs and wants.
Tools, however, permeate job ads. Listings for proficiency with THIS-Suite and THAT-Suite are everywhere. And, it’s those listings that drive students to look at programs that emphasize tools. I know we [yes, I’m an academic…] receive countless calls asking “What tools will I learn?” Courses with broader descriptions of theory, analysis, and innovation-generation, as they relate to today’s socially/digitally mediated world, still result in phone calls asking, “But, will I learn THIS-Suite of tools in that course?” Try convincing a student that tools aren’t the ‘value layer’ in the degree.
Great topic….certainly, there’s lots of conversations to be generated here.
Scott
This is a timely article for me. I teach and direct the TPC program at Cedarville University.
For years I have taught a course called Design of Manuals. It’s pretty
obvious what the course covered. I decided to redesign the course.
I started by changing the name of the course to Documentation Design.
I plan to have students begin by reading this article. We are using Anne Gentle’s
book Conversation and Community: The Social Web for Documentation for our
text. In your article you mention Exact Target. One of my recent grads
is creating documentation for them. I am hoping to prepare future technical
communicators who can think differently. I am trully tired of the “old
guard” trying to monopolize the conversation. They no longer
speak for me.
I think Laura is absolutely right about the technological determinism of tools. The tools we use shape our understanding of the task, and that holds us back from responding effectively in periods of profound change. I think this can be seen very clearly in regard to structured writing, where the mindset of desktop publishing continues to dominate people’s view of how the task should be performed. This has resulted in a generation of structured writing tools and standards dominated by (and severly limited by) the desktop publishing mindset. Technological determinism does indeed seem to be at work here, and those tools often heralded as the most progressive are in fact those most crippled by an outdated tooling model.
But its is not just in the area of production tools that we suffer from technological determinism. It is equally in the area of the output or artifact that we produce that technological determinism blocks our progress. We continue, by and large, to follow a publication model determined by the physical characteristics and limits of paper. We think in publishing terms — we concieve of our work as a months-long preparation for the production of a single static published artifact. That artifact my not be deliverd on paper, but the technological determinism of paper still dominates how we think about what we do.
We should be clear on this. Our job is not to create and deliver documents. Our job is to ensure that users have access to information. The notion that producing a fixed published document is the way to do that is a piece of technological determinism from another millenium.
I think it would also be fair to say that our getting stuck in the thinking pattern of desktop publishing tools is in no small part a result of our being struck in the thinking pattern of books and other fixed artefacts of the publishing event. If we could shift from a publishing mindset to a database mindset, I think the shift from the DTP mindset to the structured writing mindset would come much more easilly.
Hallo Scott
This is a great article! I love the point you make that the true contribution of technical communicators lies not in a perfect style guide, but in adding value to the customers’ experience and to the growth of the organization. To achieve those ends, we work with other teams within the organization and with the customers themselves. No silos, but productive collaboration.
The tools we use are important, both in ensuring that we can produce the user assistance that our customers need, and in giving those customers the opportunity to interact with the documentation or other help content. By “customers”, I mean both the stakeholders within the organization and the people who use the organization’s products and services.
One thing I disagree with, though, is putting the blame too much on the technical communicators for getting stuck in a mindset determined by the tools. I think that most of us are happy to investigate new tools and to swap to a new tool when practicalities allow. The trouble is that swapping to a new tool is a time-consuming and troublesome process, primarily because of the cost of converting existing documentation and training staff.
What we need is a tool, or a set of tools, where development is ongoing and innovative. We need a toolset whose developers are open to suggestions from us, their customers, and are able to satisfy our requirements quickly and brilliantly.
Cheers. Sarah
Sarah:
I hear you and agree. I blame some writers because they are not like you and do not want to change (maybe they want to, but are unable to for cultural or personal reasons). I’ve actually had writers say “Why can’t we just keep doing things the way we have been…?” and various other renditions of the same sad refrain. I have also had content creators tell me that when I am gone (when I play a consulting role introducing change) their staff will eventually go back to doing things the old way (for a variety of reasons). And, I have had content creators blame their inability to change on the tool vendors themselves, when, in fact, they were;t using the tools of their trade as they were designed.
Now, I’m not disagreeing. Just playing Devil’s Advocate for a minute.
Yes, tools can be made easier. And, they should get better every iteration. And, iterations should be faster and driven by the users of the product. That’s all good. But, if we are to consider ourselves professionals, we ought to stop thinking our tools will be as easy to use as some consumer products. XML authoring tools, component content management systems, etc. are not consumer tools, they are professional tools we use to create products for consumers. That said, ease of use is important, but there is also an argument to be made that if the tools we use are that easy to use, why should we pay you so much money (average technical communicator salaries are pretty high compared to some other writers) when pretty much anyone can do what we do.
Now, I can hear the writers saying, “Hey, they pay me to write, not know tools.” Yes, and no. Yes, you are paid to create content. But, you are now expected to know how to assist organizations in making that content jump through a series of constantly moving digital hoops to achieve goals that are movie targets. So, while it’s easy to argue your point Sarah (and I do agree), I am suggesting it is much more complex challenge for software vendors than many realize.
Thanks for sharing. I love that you stopped by to drop your comments into the comment box. Please do so often!
Thanks, Scott, that’s a great summary of trends and challenges, a state of the union address for our profession. I’ve shared it with my colleagues, and I’m sure it gives us food for thought!