Complexity of help documentation

Trying to maintain balance between technical jargon and simple instruction is the one of the primary objectives of any technical writer. Technical writing must be technical, it’s in the name, but this is not necessarily how it needs to be portrayed to the end user. It is the technical writer’s duty to understand the subject matter in a way that they can relay this back to their audience.

Often is the case that the audience is unknown and therefore must be assumed to include a broad range of users with varying levels of technical knowledge and background. Help documentation needs to be written in a way that is understandable for a wide spectrum of users yet communicates the technical details of the subject matter efficiently.

Keep it specific

Documentation needs to be kept concise and specific if it is to make the biggest impact to a user’s experience of a product. It is unlikely that the first step for a new user is to examine the whole suite of documentation before they use a product, it is most common for a user to read the documentation if they have encountered an issue. When they have an issue, it is likely that they want to fix it quickly and therefore documentation must eliminate any uncertainty and ambiguity if the user is to have a happy experience.

Involvement

I believe the most important aspect to improving performance as a technical writer is to become immersed and involved in the projects that you will be creating documentation for. As part of the Software Development team at Software Europe, becoming involved in the development process as early as possible provides a clearer definition of deliverables and how the user will interact with them.

All of these factors put in to practice will help to ensure a happy customer base.