We had a great meeting of the Jerusalem Technical Writers Group on Thursday night. I enjoyed presenting and was thrilled to see that this was a topic of “Innovation and the Future of Technical Writing” was of interest to those who attended. Some clear thoughts came out of the meeting – clear ideas about the current and future directions for technical writers. I’ll post my presentation shortly, but for now I’d like to summarize the main points we discussed.
First – there is a challenge facing technical writers. We cannot continue blindly producing manuals as we have been doing for many, many years. In many standard user manuals, one of the first things we do before getting to the how-to…is define the prerequisites. In our discussion, we did the same thing. The prerequisite is an acceptance that much of 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.
While doing this, we have produced manuals and online help according to basic rules and formulas. Heading ones are used in such a way, followed by those wonderful heading twos. We know when to use tables and bulleted lists, numbered lists and notes. It’s all so well planned out, so standard, so obvious.
That’s what we have always done and it is likely that this is what we thought we would always have to do. The tools we use have developed over time, but how much have we actually changed what we deliver? For the user, does it really matter that WebHelp looks different than HTML-help, which looks different than WinHelp?
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.
In my presentation, I defined current technical writing as “the box” and explained that I too see the future of technical writing as one in which we either redefine the box, or plan for “out of the box” solutions. I still believe that there will always be a need for technical writers to define what a product does, how a user can benefit from this product, and how a user can best use it. I don’t believe that engineers will suddenly have a wealth of time to sit in user-groups and explain everything. I don’t believe that users will become so sophisticated that they will intuitively know how to use every application, at all levels, without any documentation of any kind.
The challenge we face is to not only accept what we have known all along (and even joked about), but to understand that this can no longer continue to be the norm. We all joke about “nobody reading the manuals anyway.” The joke, however, may well be on us. We have been calmly saying this for a long time, and yet still producing those same types of documentation.
But companies and users are starting to listen to this. If no one is reading it, the companies reason properly, why continue producing them? If the manual doesn’t provide the user with an acceptable way to digest the inner workings of the program, thinks the user, where will I turn when I really do have a question? Users simply don’t “trust” documentation to accurately document the product and so they have turned elsewhere as a first option, only going to the manual when all else fails.
In short, the question posed to many at the conference, last Thursday night in Jerusalem, and shortly in the future in other places, is: Is there another way to accomplish what the manuals seem to be failing to deliver? The answer, we must give, is yes, of course there is a way for technical writers to be relevant in the field of user satisfaction and knowledge.
More and more, 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. It isn’t about how many headings we use, periods in bulleted lists, being fluent in the latest versions of FrameMaker or Word. It may well be about finding a way to help companies reach their users. 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.
So…having defined the challenge, the next steps we take to meet it will likely define a whole new world for many of us.