The technical communicator’s survival guide for 2011
At the 2011 North Carolina Technology Association annual meeting, Gartner analyst Michael Smith discussed how IT needs to show business value or risk being marginalized within an organization.
“How do we maximize business value?” is the discussion we need to be having in Tech Comm Land. Not FrameMaker versus Word, not DITA versus DocBook, and definitely not one space after a period versus two spaces after a period!
Business value. How do you develop, deliver, and deploy information that is valuable to your employer?
Does your content feel like this? // flickr: alex_stanhope
NOTE: The rest of this discussion assumes that you a) do not work in a regulated industry, b) do not work on restricted or classified content, and c) do not produce content for English teachers or people in the publishing industry.
Michael Hughes writes about the Degentrification of User Assistance (an article you should definitely read it its entirety):
A theme I have watched for awhile has finally caught up to me. There has been a steady movement away from using professional technical writers to produce user assistance and, instead, let subject matter experts do it directly.
He points out that information from subject matter experts could be badly written but still more valuable than what the technical writers are producing. Think about that for a minute. This is not high school English class, and unless your audience is other technical writers (!!), you are probably not being graded on grammar and mechanics.
To survive in this world, here are some things you need to focus on:
- Become a subject matter expert. That is, gain a deep understanding of the products you are writing about. You need to be able to unearth information that your readers cannot easily figure out themselves.
- Make life easier for other contributors, not harder. If your contributors are software engineers, then writing in XML is probably acceptable to them. Otherwise, look into browser-based authoring, wikis, or even a basic review workflow in which they can add information.
- Make life easier for readers. Give them excellent search, links, and navigation to help them find the information that they need. Allow them to contribute their knowledge and ideas to the technical content by opening up commenting and voting.
- Automate. Instead of spending your time formatting, reformatting, and setting page breaks, let the software do it. Focus on content, information architecture, and value.
Here’s something related from Ron Miller at Fierce Content Management:
And it’s Moore’s belief that employees are driving this shift because they want the tools they use at work to be as easy to use as the ones they use at home.
Tools like Yammer, which end users can download and use for free without IT intervention are changing the way enterprise users choose, interact and use software. They are using the software, then going to IT instead of IT coming to them and dictating the enterprise tool choice.
How can you make using technical information as flexible and easy as possible? Smartphone apps for help content? Tablet apps for troubleshooting hardware? Dashboards that show the most popular content for your support web site?
Your content strategy needs to be determined by your employer’s business goals. Do you know what those goals are?
About the author
davidwag
Using controlled language (terminology, fixed grammar, etc.) is beneficial not only for your A, B & C exceptions: controlling localization costs by optimizing content for first-run automated translation. This point does not refute the need to collaborate with other parts of your company and with users, of course, but it needs to be considered.
David Blyth
>Make life easier for readers.
I both agree and disagree. At the risk of burning at the stake, I think we place too much emphasis on “making users happy” in the STC or elsewhere.
We can give users “search, links, and navigation” tools running out the nose and still risk miscommunication if we don’t understand what the originator was trying to say in the first place. Yes, communication ends with the user understanding the original idea. But that’s boring. The communication _ends_.
Communication _starts_ with an engineer (artist, scientist or whatever)creating something that needs communication in the first place. And that’s interesting. By definition a new idea is intrinsically difficult to communicate. There _is_ no symbol for a new idea. It’s new – and no human language is perfect.
So the challenge of communication is not to teach users how to be better _receivers_ (tho that helps). Nor is the challenge of communication even to teach originators how to be better _transmitters_ (tho that also helps). It is not the job of an originator to transmit. It is the job of an originator to originate.
The challenge of technical communication is to determine how to _translate_ what an originator thinks and creates into what a user can understand and use. The goal of the technical communicator is to design something that best represents the new idea that an originator made.
The best interface between originator and user is none.
Bill Swallow
“The best interface between originator and user is none.”
I don’t know where to begin disagreeing with this statement. I could start with a social media argument for heightened engagement. I could start with conjecture akin to the telephone game. I could start with learning being a two way street. I could start with a UX approach akin to persona studies.
But all I have is “wow”.
Janet Egan
Good points. However, there is a case to be made for using a set of defined terminology and grammar beyond your three exceptions.
On automation, I agree with davidwag that controlled language helps keep localization costs down and makes automation easier.
On making life easier for readers, the use of consistent grammar and terminology makes it easier for them to find and understand the information unambiguously. Readers whose first language is not English, often struggle with poorly contructed sentences. This also speaks to making life easier for your software engineer contributors too. At one job recently, the Russian-speaking developers found the hover help text written by the Chinese-speaking developers ambiguous because of the lack of verb tenses. On the other hand, the Chinese-speaking developers sometimes found the lack of definite articles in the help written by the Russian-speakers confusing. Oddly, when I applied very simple English grammar to the help text and explained the rules to them, both sides were able to understand it. If the developers have a hard time with the help, the users probably will too.
Janet Egan
BTW, the grammatical errors in my post are mostly intentional.
Sarah O'Keefe
I’m not at all opposed to controlled language, provided, of course, that it adds business value for the organization.
Personally, I’m sort of a fan of good grammar and mechanics. But again, this is not about what you or I prefer.
I’m suggesting that we need to think much more carefully about how we spend our limited resources. Perhaps it’s in tight control of terminology. But maybe building out a wiki for user contributions would be a better use of our time. The answer is going to be different for different organizations, which brings me back to the recommendation to do content strategy based on business goals.
David Blyth
Bill, consider a very high-tech virtual reality – say an Army or Marine Live Action Role Play (LARP) – of a patrol visiting a suspected Taliban village.
In this case, there is no separation at all between what the designers dreamed up and what the user experiences. You experience the Taliban village exactly as you would a real one – except that they won’t actually die when shot.
There _is_ no interface in a LARP. The user simply interacts with their environment. See also the MS “Kinect” games. Where’s the UI? Bear in mind that both LARPs and Kinect are relatively primitive tech at this point.
>I could start with a social media argument for heightened engagement
Start away. I’m interested in this and in your other arguments. My only comment (so far) is that I’m not discussing “learning” but “communication”. So I don’t really see what learning being a 2-way street has to do with it.
Kai
I was esp. intrigued by the Ron Miller quote, so followed a few links and wound up at AIIM’s totally worthwhile presentation “A ‘Future History’ of Content Mgt” at http://www.aiim.org/documents/content-management-future-history.pdf
Key points, with relevance for TCs and their customers:
– Since 2000, enterprise IT was on hold, consumer IT was on fire – leading to
– The Big Disconnect: Why I am so powerful as a consumer and so lame as an employee?
– Consumer IT will disrupt Enterprise IT by replacing data-centric systems of record with user-centric systems of engagement.
I’ve never heard it phrased so succinctly, esp. the Big Disconnect!
Bob Flummerfelt
Reading some of these responses reminded me of something a marketing professor once said, “you can eliminate the middleman but you can not eliminate his/her function.” Companies that historically have spent large budgets in servicing their products, included sizable monies for technical communications/training/technical publications,etc. Their reasoning: maximize customer satisfaction; that can translate into product quality. There are many reasons for hiring professional technical communicators; high on that list, I believe, is effective fulfillment of the middleman function.
Roger
“In your [James Mathewson’s] study for IBM, you conclude âthat well-edited pages do 30 percent better than unedited pages,â meaning that readers clicked on links more often on edited pages vs. unedited ones. …”