From Technical Writer to User Engagement Specialist?
I came across this very interesting post by Paula Stern over on the WritePoint Staff Blog. Paul very clearly identifies the growing challenge for technical writers that I discussed in my previous post, Growing Happy Users–One Customer at a Time. The traditional “product manual” is going the way of the dinosaur because users are being conditioned by the web to both search for and interact with your corporate web site differently. Google, Facebook, and Twitter are forcing the issue and technical writers need to pay attention to what smart people like Paula are saying, because the tidal wave is coming.
From the post:
> [There] is a challenge facing technical writers. We cannot continue blindly producing manuals as we have been doing for many, many years… [What] we do as technical writers needs to change to meet the growing reality of communication world-wide.
> In the past (and even in the present), we have developers and users. The technical writers are the ones who stand between these two groups. We explain to the user how to use that which the developers develop. Often, we can offer communication in the other direction as well. We can explain to a company what we, as users, might expect and thus help influence the direction of the product itself.
> …
> The ground is shifting under us for many reasons, including the simple reality that as user forums and direct contact between the developers and the users increases, there seems to be less and less of a need for us to act as go-betweens.
> If this is a true picture – that users can now reach developers directly in user groups and email lists, in real time no less, and quickly receive answers directly – the user manuals we have written become even more obsolete.
Needless to say I agree strongly with what Paula is saying here. She is spot on in both her analysis of the problem an potential solution:
> [Companies] are turning to tutorials and videos, user groups, knowledge bases, webinars and whatever way they can to reach their users in more interactive and challenging ways. Our challenge, as technical writers, may well be to abandon the cut and the dry.
> …
> The good thing is that this is what we have always done. The basic functionality of the technical writer in the scheme of product development has not changed. There are still users and developers; and there are still information experts, technical communicators.
> Our goal has not changed – we have always been challenged with the task of finding efficient and cost-effective ways to give users a positive and complete information package to enable them to properly use an application. What does need to change, however, is an acceptance that the good old manual…may be old, but it certainly isn’t good any longer.
I apologize for the heavy quoting, but I kept finding great stuff from Paula’s post that I wanted to pass along. If there were one area that I wish Paula had touched on it would be the subject of delivery. One consequence of this growing number of communication avenues is that users have many paths to take as they seek out answers: forums, knowledge bases, blogs, etc. Where should they start?
Evolution is Required
———————
Products and tools must evolve to ensure that user experience does not suffer as technical writers evolve their delivery to suite this modern age. If a user has a question, there should be only one place to search, and those results should contain relevant hits from all possible content sources. Imagine a user asking for help and being given content from a knowledge base article, links to the seven conversations that have happened on the forums, and a blog post by your lead architect about that feature.
This is a positive change as long as we don’t forget that we must evolve the tools that we use to delivery our content to users. If companies don’t solve this problem, then the result is arguably worse, because now the answers to user’s problems are spread across the entire support site, in blogs, on Twitter, in forums, etc–rather than in one enormous PDF document.
-->