Domain-Specific Technical Writing

The second regional conference, held in Bangalore on 5^th November, introduced several domains to technical writers. The key take-away for the participants was an impressively abundant package of industry and career trends. There were ingredients to make one a complete technical writer- right from preparation for aspiring technical writers at one end of the spectrum to enhancing the knowledge of seasoned veterans at the other. Now, you have the option to choose a domain that particularly interests you. The regional conference was only the tip of the iceberg, both in terms of writing as well as the sheer size of the industry here.

To delve deeper into the subject, is writing for a specific domain any different than what most of us do every day? One can look at this topic from three different angles and try to answer the ensuing questions: (1) Use or usage scenarios are different for domain-specific products, and so the audience analysis may differ. The use scenarios may be specific, requiring more knowledge of the domain to carry out an effective audience analysis. (2) The process of writing is distinct. A "click-here-click-there" approach may not usually work when writing documentation for specialized domains.  (3) General software applications are easy to use, and technical writers can use them to understand the user’s role better. This may not be the case with domain-specific products.

Let us now consider the example of telecommunication, aerospace, process control, security control and automation, or networking products. It is not easy for technical writers to use the product themselves. Rather than mere "use," it is more about setup, configuration, complex installation, and troubleshooting. Technical writers working in such domains must have the required technical/product knowledge if they have to create technically comprehensive, accurate documentation for their users who are usually proficient in programming, system/network administration, and so on.

So, what should generalist writers do to become proficient in domain-specific writing? They must build on their technical skills. Instead of focusing just on the user perspective, they now need to learn the admin part of the product being documented. One classic example is the documentation of GUIs. In specialized products such as semiconductors or software routers in networking, command-line and terminal user interfaces take priority over graphical user interfaces. In that case, technical writers have to think in terms of supportability, usability, portability, performance, and so on.

How does a generalist writer prepare for this kind of writing? Focused training on a specific domain should help one to prepare for this kind of transition. Reading technical articles, discussions on expert user forums and standards-defining forums and reading specialized books in the domain should also be of some help.

Why should an established general writer or an aspiring newbie writer look out to work in a domain if it comes with so many complex requirements? There are opportunities aplenty in a burgeoning profession. The current situation of domain documentation is one of a compromise. Writers good either at technology or at writing get selected for want of that perfect blend of both. Recruiters are therefore banking on the learning potential of technical writers. There are a notable number of engineers working as technical writers in these domains. Finding the right talent remains a challenge for recruiters.

The next time you want to opt for a change or a better technological challenge, take time as you look out to discover a domain that best suits your area of interest. Find ways and means of preparing yourself for the challenge. Certainly more sweat and tears initially. However, patience, perseverance, and a learning attitude may well turn you into a sought after expert in the chosen domain!

Subash Babu and D Vijayalakshmi