7 Must: What a Technical Writer Must Do Apart from Writing

A technical writer’s work is only part writing. To do this part of your job well, there are several other things you must do continuously:

1. Talk to SMEs
   The best source of information about the product you are writing about is subject matter experts (SMEs). Talk to them often using both the formal and informal channels. Sometimes, you’re likely to learn a lot more about the product talking to a developer over coffee than during a closed-door meeting with the entire team. It’s not unusual to find SMEs who are great at their work but don’t fare very well in the communications department. Put such people at ease and don’t intimidate them with your superior communication skills. Try using their local language to make them more comfortable – to your surprise, you’ll find them giving you a lot more information and insight than you could have ever imagined.
2. Keep your ears open 
   Join technical team meetings, status meetings, and even customer demos if possible, and keep your ears open. You will learn a lot about the product’s capabilities, limitations, and customer use cases, which in turn can help you provide richer and more relevant information in your user guides.
3. Become the user – try things out first hand
   Get your hands dirty and do all that you want to tell your customer to do. It may be slightly time consuming, but it will be worth the effort in the long run. Having done it all yourself, you will know exactly what to write about and how to write it best. This approach will also help you sequence flow of information logically.
4. Don’t try too hard to understand everything
   While is good to try your hand at the product yourself, it is a common mistake to try an internalize everything. This is particularly relevant while writing API documentation for example. Remember that you are not the subject matter expert and hence you need not understand everything that’s going on. You need to know “what” happens and in many cases “why it happens”. But you really don’t need to know everything about “how it happens”.
5. Become a proxy quality and testing personnel
   In most organizations, documentation runs in parallel with development. So as you keep writing, make sure to identify and report bugs, inconsistencies, and errors. These things may not be part of your job description; but if you ignore them, your dissatisfied customer will crib them later. Worse, he will hold you responsible for not warning him in advance about them in your documentation.
6. Help identify usability issues
   As one of the first users of the software, you can help catch, if not all, but at least the more obvious usability issues. Many companies now treat their technical writers as part of their extended user experience group. So make sure to contribute your bit to make your product user-friendly. This will indirectly reduce your work load – products that are easy to use need lesser documentation and support.
7. Identify topics with “special needs”
   Make a note of complex topics that users might need additional help with. For example, identify topics that are probably best explained in the form of a video. There are other obvious examples, like ensuring that installation guides are not bundled with the software – users must be able to read it before or while installation. So you can create a special installation guide that is available online.