Scaling new heights as a technical writer

“Tech Writers are puzzle-solvers. They ask lots of questions. My one-liner, when asked what really do I do, is “translate from English to English”.
- Matt, Internet.

A developer needs to learn more languages and master more coding principles. A test engineer needs to learn more testing tools and master new logic. What should a technical writer (or editor) do to grow? Some argue that it is the organization's responsibility to make sure that the technical writers’ skills are updated. However, the truth remains that the writer (or editor) must initiate self-development in all the necessary spheres. Being a technical writer, if you are really interested, here are some simple ways in which you can grow and move up in the field of technical communication.

Language

• Upgrade your linguistic abilities continuously. Love or loathe it, you must keep honing your linguistic abilities to stay and grow in the field of technical communication. Remember that you need not become a Shakespeare, but you must strive to convey your message accurately to all levels of your audience.
• Merge language and technology in your learning process. If you find it difficult to follow the ‘learn one-word-every-day’ principle, read modern literature in both technical and non-technical journals to find new words, idioms, phrases, and their usages. Visit any of the journals’ websites and access the PDF versions to read them when you have the time. Thus, you hone your language skills while knowing about a technology if you go through some technical journals.

Tools

• Be aware of all the new and old tools that are being used. You need not know the in-depth functionality of all tools. Make it a point to know the purpose of the various tools and their basic features.
• Upgrade your tools knowledge too, regularly. If you are well-versed with Microsoft Word, try to learn about Adobe FrameMaker. If you are good at FrameMaker too, try to learn technology such as XML and DITA. From writing to structured writing to collaborative authoring, new methods and tools are flooding the market for you to implement. Try them and learn the basics. Most of the product companies offer trial versions for you to conduct a test ride on the tool. Consult your senior writers to know more about the current trends and new tools and technologies.
• Make use of open source applications. Ask your seniors or online experts about some good applications and try these open source tools.

Domain

• Master your domain and begin exploring other domains. Try to establish the relationship between these domains to broaden your perspective on all the domains.
• Probe further into your current domain and know about similar and different products. If you are in the networking domain, learn more about switches of different types, and then expand your knowledge base into routers even though you are not currently working on them.
• Begin knowing the basics of a couple of other domains. The Internet is the best place to conduct your research and learn more about the domain. As you do not regularly work on this domain, it would be useful to collate and store all information pertaining to it. You can revisit this information periodically to retain your knowledge base.

Processes

• Learn more about the different processes involved in the technical communication arena. You can master tools and domains within a stipulated amount of time. However, you can master the processes only through experience. Processes tend to evolve at different rates. Experiment, explore, and share your process experience.
• Keep a track of technical documentation trends. Visit some technical writing communities online to gather some of the common trends or read the blogs of experienced technical writers across the globe.

Project Management

• Understand the nuances of project management. Sooner or later, you are expected to manage people and coordinate their work. You must learn principles such as - Different strokes for different folks - to play the management role efficiently.
• Identify the relation between project execution, process frameworks, and people management. There are many underlying principles that you need to understand and appreciate to become and grow as a manager.

Collaboration

• Team up with other writers in various activities and participate in discussions pertaining to the technical communication field.
  Exchange your best practices frequently with colleagues across teams and locations. Thus, you get a chance to share and learn at the same time. In fact, this is one of the easiest ways in which you can move up along with others.
• Share your knowledge with others through various methods – write an article for your company newsletter or a blog on the internet. Send an email to the different technical writing groups to discuss, share, and learn new things.

You must have realized that it is time to stop cribbing about the lack of prospects to learn new tools in your current project. If development is your goal, you can achieve it easily by moving in the right direction. Note that these tips are not specific to writers and editors. Anybody who is working in any type of technical communication project can benefit by following the aforesaid ideas.

Research Methods in Technical Documentation

You can now read this article at this new location on techitive.com: 
http://techitive.com/process/research_methods.php 
You can find this and many more articles related to technical documentation by Chakravarthy Tenneti and other writers on the website - techitive.com.

Document Development Life Cycle

Technical documentation happens simultaneously with the software development and hence has a life cycle similar to the software development life cycle. You need to follow all the stages in this life cycle to ensure that the documents are technically accurate and are of good quality. The six steps of the document development life cycle are as follows:

Preparation
This is similar to the requirements gathering phase of the software development life cycle. Gather all the requirements and available resources during this stage of the life cycle. Identifying the requirements includes establishing the primary purpose of the documentation exercise, analyzing the audience of the documentation, and defining the context and scope of the documentation.

The advances in the field of technical communication also prompted the necessity of identifying the medium. Earlier, hard-copy help manuals were the only source of information provided to the end user. Now, help is available in various formats - online Help, PDFs, and printed documentation. Thus, it is necessary to identify the medium at this stage.

Research
This stage involves reading the source documents such as system specifications and functional specifications. Gather the required inputs from the subject matter experts using various modes of communication such as interviews and emails. Analyze the information received from different sources such as source documents and SMEs during this stage.

You must also understand the importance of secondary research activities - brainstorming, mind mapping, and information mapping. Depending on the audience analysis and audience profiling conducted during the preparation stage, you might have to conduct these secondary research activities to collect additional information. Then, you should be able to define an outline of the document. Such an outline lays the foundation of a technically accurate user-friendly document.

Organization
Every formal document needs to be organized to suit to the end user needs. Organize your information using existing document references, customer-specific style guides, information mapping principles and structured documentation concepts. You must organize your document considering the type of the document - proposals, marketing collaterals, white papers, articles, manuals, or online help. The content in the manuals can again be classified based on the information needs - user manual, installation manuals, training manuals, tutorials, service manuals, operations' manuals, and special-purpose manuals.

You must also focus on visual organization - layout and design, and typography. Choosing appropriate visuals help in a variety of ways such as - showing objects and spatial relationships, displaying geographic information, and showing numerical relationships.

Writing
This is akin to the software coding stage. Writing is an essential part of DDLC. The quality of the document depends on the writing style and the flow of the content. Prepare a documentation plan before embarking on the journey of writing. Use all the information and resources gathered during the previous phases to write accurately.

The two major aspects of writing that you must consider include perspective and usage and process. Choosing the right perspective is also very important while presenting the information. Perspective refers to the approach towards the task on hand. It also refers to the understanding of the context of the document and writing accordingly. Usage and process refer to the usage of words and the process used in writing. You need to consider various aspects such as the usage of American and British English, style guides, and the appropriate method of development.

Review
Begin the review stage by verifying and revising your own draft. You must check your draft for completeness, accuracy, and consistency during this stage along with a check for the Grammar guidelines and usage principles. You must send your document for a peer review. When you peer-review, you not only check the Grammar and style aspects, but also judge the quality of the document by keeping in mind the information needs of the end user.

Editing and proofreading together form an integral part of the review process. Editing is a formal process defined with set goals to improve the overall quality of the document and ensure that the document is technically accurate.

Delivery
As discussed in the Preparation stage earlier, the document must be delivered in a format that is accessible to the end user. You might have to deliver the same installation guide in two different formats for two different types of audiences. Most often, every software application is delivered along with an Online Help and printed documentation. Hence, it is necessary to identify the accessibility needs of the end user and deliver the documents accordingly.

Technical writing and copywriting

Without discussing the common differences between the two similar writing fields, I would like to bring upon a few interesting observations I had while going through a good book on copywriting.

Features and benefits
While copywriters are expected to focus on benefits and then enumerate the features, a technical writer must explain the features and then enlist their benefits. More often than not, in user documentation, the user must already be aware of the benefits and would like to know how to use the product to get these benefits. However, the audience of the copywriter would like to know the benefits for using the product so that they can decide whether or not to buy the product. The ability of the copywriter lies in the ease with which the audience is persuaded or convinced to buy the product. The ability of the technical writer lies in the ease with which the audience is able to use the product without getting lost.

Call for action
While a copy calls for the action of buying, the end user documents call for ease of use. Though it is cliched, I'd like to recollect the old marketing saying that the customer is the queen. However, it is difficult for the copywriter to satisfy the customer. The technical writer just needs to help the queen effectively utilize the product and satisfy further. The catch here is that the mantra behind communication for both these fields of writing is to be simple. While there are some complex advertisement copies everywhere, these are very simple to their audience.

This brings us back to the 'audience' part of both forms of communication. Unlike poetry or writing novels, both copywriting and technical writing are directed by the audience and not by their creativity.