Author: Neftaly Malatjie

Writing software documentation may seem extremely easy for some of us, whereas others may consider it one of the most difficult tasks they could ever be asked to do. The generic term for this kind of writing is “technical writing”. A person who does this job is generally referred to as a “technical writer”, with quite extensive knowledge of software and technology and with a deeper understanding of the logic behind the software, or a “technical writer”, a person who, although somewhat overwhelmed by all the denominations and the algorithms of the software, is accurate in producing a proper technical text. Nevertheless, regardless of the orientation of the writers, be them more technical than writers, there are some things that need to be considered before, during and after the writing process.

On completion of this section you will be able to Document the installation of a multi-user networked operating system. 

1. The documentation specifies the configuration and customisation. 
2. The documentation shows the results of testing. 
3. The documentation includes evidence of acceptance by the user. 
4. The documentation explains basic user operating procedures. 

The next principle is to pay attention to your tone and language when replying to the customers. This matters a lot because you don’t want customers to feel like their suggestions have triggered an automated reply and that their suggestions will be going into the void.

Regardless of the feedback, it makes sense to thank the customer for the time they took to share their thoughts with you.

Before we decide how to respond, it’s important that we have the right mindset. Instead of hiding the truth from your customers to look good, customers will appreciate transparency more.