Organizing a Reference Guide

Posted by:

|

On:

|

,

Most of us have observed that products tend to become more complex as they evolve.  This is not unusual, even for a set of golf clubs.  Increasing product and service complexity is a natural consequence of working in a competitive environment.

To address this, product documentation should be capable of moving in lockstep with product evolution, even if it occurs in ways that are hard to predict.  Talk about feeling insecure about starting a reference guide!  Fortunately, there are tools we can use to attack this, and they come from right from the product planning and project management playbooks.

Before staring a reference guide, we have found it useful to take a look at project records from a similar past project that was implemented using a tool like Atlassian.  By moving forward though some of the major development stages and noting how new features were added, it is possible to put together a pattern by considering a few questions.

How much did the product change as it evolved?  Did it end up entirely different, or was it simply enhanced in minor ways?  Were there a lot of changes in direction, or did the development process follow a pre-defined plan?

Make note of the answers to these questions and we are ready to organize a reference guide.  If the trend is for this company’s products to change slowly and per the original plan, it is probably safe to use the current product plan as a basis for organizing the guide.

However, if things went all over the map, spend some extra time with the team members to make note of a few likely outcomes.  If it is necessary to prepare for a somewhat random future path, plan accordingly.

Reference Guides

But before moving ahead, here are a few notes about reference guides.

Reference guides are not “how-to” documents.  They need to be like an abstraction of a dictionary and therefore should be organized to answer quick questions.  If this process generates more questions, fine.

Consequently, the guide should be complete enough to answer the next set of questions and so on.  It should be organized to make it easy to jump from one part of the product to the next with minimal effort.

Readers should not have to digest large sections just to find out something.  Rather, they should be able to get to an answer quickly and get on with their business!

As with most technical projects, take some time to get these basics settled first.  Then, the rest of the work will go a lot more smoothly.  We are ready to help you with that.