There are some dreaded words that most technical writers encounter during the ritual of bi-annual performance appraisals – “Reskilling”, “Product focus”, “User-oriented approach”, “Keep pace with Technology”, “Adapt to changing documentation trends”.
Out of the time I have spent among tech writer friends, some of them wilt and fade away when these words are thrown at them. They either quit or choose mediocre career paths. Some others complain about bullying managers and cut-throat companies. However, a few of them raise up to the changing demands and become key contributors to their product teams.
To be fair to these hapless tech writers, we must acknowledge that their jobs have undergone radical changes over the years. Technical writing was earlier popular as the most relaxed and deadline-free job in an IT company. It was common for married women to shift from demanding technical roles to technical writing, to balance their work and personal life!
It is important to understand these critical transformations that have taken place in the technical writing job profile, over the years.
Critical Transformations to Technical Writing Job Profile
These transformations have pushed technical documentation from being a fringe role to a critical, product development role. So naturally, the requisite Technical Writing skills for playing this role become more broad-based instead of being a mere writing job.
Product teams have moved from being product centric to user-centric.
Earlier, product manufacturers focussed on balancing their product feature list with cost and time to market considerations. But this approach has a high product failure rate. So the concept of user-centered design and development evolved. Now, the product user and his requirements are the focal points around which the entire product development takes place.
Product documentation has widened to cover all phases of the product lifecycle (From product pre-research to post-release support)
Technical documentation in the traditional sense referred to installation manuals and user guides. However, in the modern context, a technical writer could be contributing to a pre-research phase technical white paper or writing API documentation for software products.
Read Also: How Technical Writing is changing with the times
Product documents have lesser textual content and more audio-visual content
The attention span of users especially in the digital world has dropped drastically. If you cannot convey the key part of the message within the first few seconds, then the communication becomes ineffective. So there is a push towards visual representation. Availability of high-speed internet allows users to access videos freely, so documentation can also carry video messages. I would rather see a quick 1-minute video on “Unboxing my mobile phone” instead of sitting through and lengthy step by step installation manual.
Product documentation is moving from one-way static information to interactive communication
Gone are the days when help documentation would sound like a sermon, delivering the same content to users irrespective of their experience levels, circumstances, etc. For instance, a car maintenance manual would elaborately describe the entire process of “How to change a flat tyre”. Which a first timer might appreciate but a repeat user finds annoying. To a repeat user, just where the jack is located in the car needs to be conveyed succinctly, rest is redundant.
New age technical writing tools such as Augmented Reality (AR) and customized content delivery address this key aspect of delivering the right amount of information to the user based on the user’s feedback and preferences. Interactive performance support and Technical documentation tools such as Whatfix, being a case in point that has ushered in this trend.
Now that we have established that technical writing (more appropriately technical documentation) has undergone some critical transitions, we technical writers need to reorient our understanding of the job at hand and the Technical Writing skills required to perform this job effectively.
6 Essential Technical Writing Skills That Every Writer Must Possess!
I have listed below essential/desirable knowledge area and Technical Writing skills that one must possess. The listing is divided based on the area of focus for career advancement, not on temporary market fads.
1. Competence in understanding the product
A Clear understanding of the product under development is the most critical skill one must possess. This would cover:
- product functions, key purpose
- product performance, stability and other non-functional aspects
- usage pre-conditions, first-time use,
- troubleshooting, repair, and replacement
Since the technical writer essentially views the product as a black box, it is not required for them to be familiar with internal components, design aspects, etc. So if Facebook is the product you are writing FAQs for, you do not need to know that Facebook is written in PHP, C++ and more recently in D programming languages. You just need to have thorough knowledge on “How to post on Facebook”, “How to add friends”, and so on.
However, when it comes to technical documentation for software platforms, there is an added dimension of integrating with other software products. So in such cases, some amount of knowledge on the interfaces (Hardware interfaces / Software API) that the product exposes is essential.
2. Accumulating In-depth knowledge in the product domain
Unlike entry-level software programmers, it is not easy for technical writers to switch from one business line to another. Simply because tech writers need to understand how products work, and products cannot work in isolation. They are often deployed as part of a larger solution in a business domain.
Let’s say presently I am employed as a tech writer for a telecom company. It is natural and inevitable that I would pick up knowledge of the underlying domain – such as broadband networks and mobile telephony. And how the product under development fits into the business scenario.
Now, if I look for a job change and pick a company in the financial sector, my past domain knowledge comes to nought. Accumulated domain knowledge is an ace up the tech writers’ sleeve. Not so much for mass-market commercial products, but definitely for business solutions.
3. Pinpointing the target user persona
IT’S ALL ABOUT THE USER STUPID! That’s the maxim a product team must never forget, especially true for technical documentation members. Before products reach the market, the system tester and the technical writer act as proxy users. They install, configure, run and troubleshoot the product as per the defined specifications.
But users come in various avatars. For small household products like a broadband modem or a microwave oven, we have a single user who might perform all the above-mentioned tasks. On the other hand, take the case of large-scale commercially deployed products such as security surveillance solution in a mall. The target user for an installation manual is an installation engineer and the target user for a troubleshooting guide is a service technician. They might even belong to different service companies.
Tech writers in many companies double up as UX (User Experience) engineers. The underlying skill required is:
- Installation, deployment, execution, maintenance time use case analysis
- B2B or B2C user profiling
B2B users are intermediaries, system integrators or software platform developers. They know the system from within and are concerned with technical aspects such as Operating System environments, hardware specifications, programming APIs, build tools, test automation. Especially when multiple products and platforms deployed as part of a composite solution.
B2C users are primarily laymen who just care about using the product as a black box. So product documentation must be from that perspective.
Read Also: Tips To Technical Write For An E-Learning Solution
4. Documenting all the essentials
Technical writing has always been an integral part of the product lifecycle. Before the digital revolution, technical documentation was the only way to reach out to the target user, at any lifecycle phase.
The diagram below illustrates various technical documents that product teams prepare for each phase.
5. Mastering the mode of communication
Physical products come with accompanying document booklets. Software applications might include PDF documents for documentation on installation/usage/maintenance. The online software could have in-context web help, FAQs, pop-ups, embedded videos within themselves.
New age IT solutions such as Augmented Reality are making their way into product tour, support and documentation. Google street view is an example of superimposing help information on the product itself.
Mode of communication is determined by the user’s relationship with the product. A technical writer must be aware that the user function determines the mode of communication, not the other way around.
6. Using the right technical writing tools
Document management, layout design, writing, images/audio/video editing – there are various tasks a technical writer performs. Tools aiding each of these tasks are available in plenty in the market – some free, some glaringly expensive. Depending on the company/product profile, the appropriate tools are to be chosen. A series of articles covering all aspects of technical writing tools was published earlier. You might want to refer to them
Technical Writing tools for:
– Information Gathering
– Documenting Information
– Information Publishing
Important Note: The areas of focus above are listed in descending order of priority. Which means to say, possessing knowledge on latest tools might look fancy on a resume but the key strength of product knowledge from the user perspective is much more valuable.
I urge technical writers to view their job roles with a 360-degree perspective encompassing all the above mentioned Technical Writing skills. The next time somebody addresses you as a mere technical writer, you could give them an earful on how diverse and enriching your job is. Good luck!
Let me know what you think about this article in the comments below.