Technical Writing – How Wikis will Transform Technical Writers into Information Coordinators

In case you are not too familiar with it, Wiki is a web site that can be built by many authors together. That’s its most basic definition. But “wiki,” which means “quick” in Hawaiian, refers to the application that makes a wiki web site possible as well.
wikipedia is the world’s best known wiki but, as important as it is, it barely scratches the surface of the wide variety of wiki applications on and off the Internet.
The reason I say “on and off the Internet” is because there are many high-tech companies around the world today that are creating their own wiki sites hosted on their own servers. Sometimes these sites may be reached by the general public and sometimes not since some wikis are for the exclusive use of a specific company or membership group; just like the “Intranet” sites.
The power of a wiki is the way it allows multiple authors pool their knowledge and experiences and build up a collective knowledge base quicker than a single author could ever do it. Just look at how the Wikipedia has replaced many other traditional paper-based encyclopedias, especially for the under-30 generation.
Technical WritingThe reason why you as a technical writer should pay attention to wikis and learn more about them is because high-tech companies have started to shift their documentation load to wikis where not only technical writers but engineers, field technicians, quality control engineers, managers, and even clients and end-users can also participate in knowledge creation. The online help software creator Quadralay is one such company that opened up its knowledge base to its end-users through a corporate wiki. In such a new environment, technical writers shoulder the editing and facilitation roles as well.
Here is a typical situation that is repeated on a daily basis in many hi-tech companies around the world:
You are a technical writer who authored all kinds of user documentation for the ABC product which is installed and configured in a number of different ways by the end users. The end users constantly fiddle around with ABC’s features and discover bugs while demanding new features be made available in the next model (or version). So this is a situation in which there is a regular flow of information from the customer base. But it is first filtered through the marketing and sales department.
Some of the information is passed along to the project management back at the company headquarters.
Then, again some of that information is passed further along to the product management.
And at the very end, you as a technical writer learn about what works and what doesn’t about the product, and what needs to be updated in your documentation.
There is an inevitable time delay and content loss in this step-by-step process as the information is passed from one level up to another, depending on priorities, time and resources.
Technical WritingThis classic hierarchical model of information flow might be necessary in some industries. If, for example, you’re manufacturing baby food or heart medicine, you might want to make sure that as many decision-making levels as possible are involved in the information flow and in a sequential manner before you make any changes to your documentation.
But in some other industries time is of the essence. The faster you get customer feedback, and faster you get it cleared through the management, the quicker you can update your documents and thus serve the customer base better.
In such cases a wiki could be what the doctor ordered for. In such a hypothetical situation the customers can directly enter their suggestions, comments, issues etc. into a wiki site. The information can be channeled instantly to all those authorized to receive it. If you are on that list, you can immediately start working on the updates and generate your new drafts much faster.
That’s why I believe in the near future, as wikis become more prevalent, the technical writers of today will emerge as the indispensable information coordinators of tomorrow. They will start to set up wikis, configure them, and make sure the information flow up and down between different levels continue unimpeded, while they still perform their writing and editing functions.
Get ready for your new role as a “wiki operator” and an “information coordinator.” Learn as much as possible about wikis since the future belongs to them.

6 Comments

  1. […] I was reading a post from Ugur Akinci about how wikis will transform the role of the technical writer, and it reminded me about the wiki initiatives I was trying to promote at a previous job. Wikis are […]



  2. Julia on February 20, 2009 at 11:01 am

    This is definitely something I’ve been thinking about Ugur, and I just wrote about it on my blog too! Thanks for the inspiration! (http://is.gd/kfe1)



  3. admin on February 20, 2009 at 11:14 am

    Thanks for your kind comment, Julia. I added you to my Blogroll list. Take good care and best regards. Ugur



  4. Alan J. Porter on February 23, 2009 at 10:10 am

    Thanks for the mention of the Quadralay/WebWorks documentation wiki (http://docs.webworks.com).
    We also have a new White Paper on Wiki Publishing available that details some of the lessons we’ve learned in implementing and deploying wikis. If any one would like a copy just email me at aporter@webworks.com



  5. admin on February 23, 2009 at 11:45 am

    Alan, hi! Thanks for the offer. I’ll take that since I’m busy educating myself about Wikis and I really did enjoy your eye-opening presentation at last year’s STC Conference in Philly. Are you planning to have a presentation this year at Atlanta as well? Best regards and thanks for reading TCC. Ugur



  6. Alan J. Porter on February 23, 2009 at 12:41 pm

    Hi Ugur – Hope you enjoy the white paper. Thanks also for the kind comments about last year’s presentation at STC.
    I will be doing two presentations at STC in Atlanta this year – hope to see you there.