How to Write a Customization Guide

The first question is: who are you writing this customisation guide for? As a technical writer, the skill to developing a useful guide is to keep the reader in mind.

• Who will be reading this customisation guide?
• What’s the most important thing they need to know?
• How can I make this more helpful to them?

These are the main questions to ask yourself before and during the documentation process.

How to write a customisation guide

So, let’s break down the tasks:

1. Meet with the project sponsor first. Ask them what they expect to see in the document? This helps shape the initial draft and avoid any possible confusion later on, especially assumptions she may have had about the contents. So, agree on this first.
2. Prepare a Table of Contents. This is the framework of your document. It’s the centre of gravity. Everything should be developed with this in mind.
3. Start with the most important tasks first. Why? You may not always have access to the developers or other subject matter experts. Figure out the really critical sections – what needs to be customised first – and document these.
4. Get these out for review. This means you get the doc review cycle in place asap. Get other team members up to speed, show them how to use Track Changes if necessary, and walk them through the process.
5. Be patient. Just because someone knows how to develop software doesn’t mean it’s easy for them to explain, especially if English is there second language.
6. Update the docs based on the feedback, keep a master copy under control, and then start on the secondary items.

What needs to be documented? Of course, all this implies you know what needs to be doced. Maybe you don’t. Here’s an approach.

1. Ask the team lead to identify three parts of the software that are likely to be customized.
2. Ask them to demo how this works, if possible. If not, get them to show you the code.
3. For each item you want to customize, say an XML file that you can configure to change the look and feel, get them to show you the schema, elements, and properties that need to be modified.
4. Get code samples. For more technical customisations that need to be documented, get code samples and provide explanatory text.
5. Add comments to the code. This is very helpful to developers who are joining the team as they can walk through the code, seeing how its constructed, and understand how the system hangs together.
6. Documents all properties that can be modified, including the default values and recommended settings. Also highlight any mandatory properties.
   Add diagrams to explain complex workflows. This helps illustrate dependencies between different layers, wrappers, and modules. It’s fine to describe it in text but an image gives you a nice snapshot.

In the next tutorial, we look at the different parts of the customization guide and how to create a template that works for different customizations.