Technical communication is the process of conveying information through writing, speech, and other media to a specific audience. A technical communicator has the responsibility to step into the shoes of the user who needs to read the documentation and work with the software in the course of their daily work or for specific reasons.

In my short stint as a technical communicator, I have realized that understanding the software being documented is one of the most important aspects of my work. In many cases, a technical communicator would know more about the software than the developers themselves, bugs included. As a technical communicator, one must never assume anything. It is always better to ask questions than to make mistakes based on wrong assumptions. More often than not, the work of a technical communicator requires working with the software while it is still in the final development stages. It is at this time that a technical communicator ends up testing the software.

Something I noticed in my own work as a technical communicator was that software created for in-house employees is customized for their requirements. This means that unless you understand the entire business process, it is difficult to understand the software. This definitely requires help from subject matter experts without which a technical communicator cannot use the software efficiently.
Creating technical documentation for a software application requires a great deal of testing. None of the features can be left out and there may be cases where improvements can be made to certain features. As technical communicators, we need to think like an ordinary user and ask ourselves whether we can use the software application without the help of a user’s manual. If it can be done, then the software has served its purpose–to make work easier for those who use it. On the other hand, if you have to break your head trying to figure out what a button does or what a check box implies, then the software needs a bit of tweaking.

Software that is set for release to the public is designed in such a way that any user with a basic understanding of application usage is able to work with it. Such applications have features that are self-explanatory and in most cases, users do not have to refer a user’s manual.
In a poorly designed application, the data entry flow may be difficult to understand. There are many instances where the standard business process is easy enough to understand, but implementing the same in the software is an arduous or near impossible task. In large systems there may be quite a few modules that are rarely used by the intended users, and hence bugs are not discovered until later, when the documentation specialists get their hands on it. More often than not, developers do not take into account the software’s usability by a general user. To get a near-perfect document, the technical communicator must be able to fully utilize all the features of the software.
References:www.wikepedia.com