Technical Writers Training

The profession of technical writing is no more an isolated domain of west. The past decades have ushered the emerging numbers of technical writers in India too. To those who have not come across this profession or this opportunity, technical writing is the art and science of writing about the technical subjects to help end users of the technology.

Most often the requirement of becoming a technical writers demands advanced knowledge of English writing. In fact the good knowledge of English writing holds good to comprehend complex technical knowledge into simple English writing that helps user to understand the technology. But don’t get misguided that to be a technical writer you need to have prior experience of journalism or mass communication or a post graduate degree in English. If you have flare for writing in English and if you can write simple and crisp English, you are in the league. However, if you are transitioning from Journalism or have a post graduate degree in English, you will have an edge. Yet again, I would say that writing is more of an art than science and it can be anyone’s passion.

Today, the opportunity in the market requires you to be good in English. Many companies would prefer you to be on-board and train you in the technical writing on job. Most others would like to have a person who has some exposure of technical writing and knowledge of styles and tools of the trade.

The technical writing training offered by different institutes in different parts of the country exposes you on the knowledge of the following:

• Different style guides of technical writing
• User guide authoring and publishing tools
• Help authoring and editing tools
• Image editing and designing tools
• Classroom sessions on procedure and instruction writing
• A glimpse of different kinds of documents written by a technical writer
• The different technological domain in which technical writers are getting employed
• Creating a sample documents  

The training institutes are meant to teach technical writing and not English writing. You will be disappointed if you think that they can teach you technical writing without you knowing English writing. However, you can complement your average level of writing skills with the expert level of authoring tool knowledge which often required in trouble shooting and that makes you a production specialist.

If you have good skills of writing and preliminary knowledge of authoring tool, getting a job as a technical writer will not be tough. Today, almost all the industry driven by technology requires technical writers into their fold. Being a trained technical writer would greatly enhance your chances of getting a job.

The Painstaking Target Blogging

Blogging can be a fun and thought sharing as long as it remains under your control on your personal blog sites. But can be a painful exercise if you are asked to blog for certain sites for the targeted audience. Its no more a pleasure writing because you are tied up with a boundary and limitations. Overall you need to do a lot more thinking before you publish it. Even then, you would never be contented about the quality of the content.

The major shift from the personal blogging towards the target blogging is the lack of knowledge about the different subjects you are ought to put up a post. It might not be an interesting subject or a topic what you might have been asked to write. Secondly you are not the subject matter expert to enlighten the audience with your expert advice or suggestions. To write such kind of posts you are required to gather knowledge in various ways.

Personal blogging does not need such efforts. While you think of a post your new ideas are there in your mind and writing is far easier. You can draw parallels about your experiences and leverage your knowledge within this post. Additionally you can have your personal point of view too.

The target blogging is not personally opinionated; rather it carries the articulated marketing thoughts which needed to be pierced through the blogs into the audience mind. It has professional zeal and vibration to woe the audience without any controversies. It is a collective thought and not the independent thinker’s voice.

It is because of all this when I write a blog post for one of my acquaintances as a professional blog writer I sometimes fail to meet the commitments. I really need to work hard to be in the customize shoes at times. But that again is a part of the professional blog writing.

Nevertheless, whatever personal touch you try to give into the targeted blog, it still remains behind your personal blogging as an interest.

You are paid for your efforts

Most of us have transitioned into technical writing from a non writing career or from a different writing career. Obviously we try to gauge ourselves as a technical writer based on our English writing skills adhering to the different styles of technical writing. In the course of time we try to compete with our colleagues on better writing skills and try to position ourselves in the team and look for progression in the career.

This holds true if we are treated as a technical writer as an individual contributor. This also requires us to know all the other aspects of technical writing other than writing alone, such as authoring tool proficiency, skills to interact with the subject matter experts, and little bit of knowledge of estimation of the work and planning and meeting delivery schedule. However, having all in a person is quite a challenge at a time.

Technical writers’ jobs do not always require writing only. There are different kinds of documentation need and a technical writer’s work is driven by the requirement. For example, if a document is required to be re-branded, you hardly need to do any writing job. Similarly, if a document is to be updated for the revisions, you just need to write a few sentences or a few paragraphs to add into the documents. If the document is to be created into a different format your job is to use same content into the new format.

You are lucky, if you are associated with writing a new document wherein you can show your writing skills to your fullest capacity. Yet again, the document goes through several reviews for technical accuracies and language hygiene. This is done by other technical experts and fellow technical writer as a reviewer.

Although, the great job of writing of the document is done by a technical writer alone, but is it right to take entire credit for writing the document. For completeness of the document, others too contribute immensely.

Whereas, in a team setup, the competence and skills of all the team members are recognized based on one superior skill and team largely depend on that individual to fulfill that need. May be that person might not be a good writer, but he/she can be a good authoring tool specialist, a good trouble shooter, a good leader, a good technical person or a good graphic designer or a good communicator. Therefore, even for one deliverable, the efforts of all the individuals accounted equally.

Once, one of my colleagues said, “We are paid for our efforts.” As an immediate thought I realized that being a technical writer he is passing the buck and trying to cover for his incompetence in writing. Later, it haunted me loudly and reality seems to be true. The best of the work is achieved by team work and it consists of every team member’s best efforts.

May be, my freelancer friends would have different opinion on this but as a part of the team and working in a corporate setup, this is the reality.

Technical Writer as a User

The name technical writer suggests about a person who writes the technical documents for the user, which helps them using the product. More often than not, when the user struggles to find out the answers of their problem in using the product, they seek the help from the support group. Obviously, users don’t find the answer of their problems in the documents, which were shipped to them along with the product.

The standard procedure followed to analyse the user’s problem and leading them to learn the product to use are not based on the realistic approach. Neither feedback system revamps the standard procedure in the next revision of the documents. The revision only includes the recent addition in the features and functionality. But most of the time even users also do not like to send their feedback on the documents. May be because of the perceived idea that their feedback will not be taken care or the life cycle of the product is so short that they understand that revamps are not possible.

In any case, it does not help documentation to improve. Therefore, sometimes technical writers, who are to be blamed for the sub-standard documentation, finds even user responsible for this cause. In a normal scenario, a technical writer assumes to be a user and interprets the knowledge transfer in a best suitable way they can. But, that may not be the simple way of translating the knowledge what user would have liked to be. I really bet, the understanding level and approach of different users differ immensely. That is how, even the understanding and use of an authoring tool widely differs among the technical writers too. Some are easily able to use the tool, whereas some takes time to learn and use.

I can understand that each one of us has different learning curves and that reflects while even using an authoring tool. Nevertheless, when a technical writer struggles to learn the tool using the Help or the User manual and finds it tough to get their answers, even then they would not like to send the feedback to the corresponding writers group. If they do so, hopefully, it might help improve adding those points in the next version of the product that could help another writer avoid rigors of tough learning.

Ideally, it could be better to list down the questions, which could be included in the User Manual or in the Help and send across to the product company as feedback. And I suppose during the next version as an update even these new answers could feature into the document. Therefore, as a user, it’s a best way to help our fellow writers and help improve even the documentation on the community level. Otherwise, we will continue writing the documents as we usually do and get overwhelmed thinking that we have produced the best. But, in reality, we will not be serving the user, for which we are paid for. Its time we don the role of a writer when we are writing the manual and take the role of a user when we use a product. At the end of the day we should not forget to send and receive feedback which would lead us to help and get help on our documents.

Redundancy in User Documentation

End user documentation in software industry, to me, sometimes looks redundant. I have had the opportunity to work in few of the software companies which develop software application. As a part of the end user documentation, following documents are prepared to ship with the application:

• Release Notes

• Installation

• User Guide

• Web-Help

• Admin Guide

• Tutorials

The release notes specify different features and version of the software in the particular release, whereas the installation guide describes about the system requirements and stepwise installation procedures of the Software. Sometimes, it discusses about the architecture of the software too, for the better understanding of its compatibility with hardware and other software for operational efficiency. These are the useful information contained in these documents.

Admin guide is another document which takes you through the functionality and features that helps in administering the software. Sometimes, you, as an end user can act as an admin too. In another cases, like in enterprises solution software, there are different individuals who would be responsible for acting as admin.

WebHelp is another documents prepared as one of the applications, to be integrated with the software which comes handy to understand the functionality of the software. The content created with this application contains various web pages linked with hyperlinks with each other and can be navigated through a table of contents. In this, the contents are created keeping in mind the task based approach. Even the particular windows of the software can be linked with particular web pages which are called context sensitive. This entire application is integrated with Help menu of the top menu bar of the home page of the software.

Ideally, the user guides are created to take a walk-through of the software with the minute details. The approach is to focus on every bits and pieces of information about the structure and functionality of the software. However, some of the information contained herein are already discussed in the WebHelp. The tutorial again has the mixed contents of WebHelp and user guide.

Therefore, user guide, WebHelp and tutorials contain approximately 50-60% of similar contents. Some of the software application has exactly the same content in user guide as well as in WebHelp. Only the format of display is different. In industry, it is called single sourcing. The idea is to write once and display in different formats.

Can we call it as effective documentation? In my opinion, certainly not! Because end user find almost redundant contents in these document. The time is come to realize this and give the user the documents which is useful for them. Otherwise, tradition will continue as it is said that a user never reads or consult the documents shipped to them along with the software.

Truly, if user does not find the answers he is looking into the document then definitely he would never consult them. This throws open a question on our credibility of being a technical writer asking whether we are doing our job keeping user in mind or not. This also shows that we are writing a document which is not useful for the users. Well, are we only fulfilling a regulatory requirement or ready to help users?

Remember, being a technical writer we are also a user of the documents that we refer in day today life while working with different software applications. Incidentally, how do you feel when some of your questions does not fetch you answer from the integrated help or user guide on that product? You feel even disappointed when the topic is there but if it is not well explain to guide you to complete a task. You definitely blame the technical writers for sloppy job done. This is a great feedback for you to be self motivated to treat your user valuable and think of the documents which will help them. But not load them with unnecessary documents, which will make them dump these without even looking at them.

So, be creative and use your wisdom.