Database Reference
In-Depth Information
pictures you include are genuinely helpful to the user, instead of confusing them further. Sometimes this means
that sections of the illustration should be highlighted and/or numbered to properly indicate what is intended by
the gure.
Additionally, figures should be numbered accurately and referred to properly within the text. Figures should
never be pictured without written instructions indicating the purpose of the illustration, unless, of course, you are
writing instructions for Ikea.
Figure Captions
Illustrations should always be captioned with a figure number as the title and a brief description of what the
figure is indicating. The description of the figure is typically more like a label, and not a full sentence, so it does
not need a period at the end of the caption.
Figure numbers are a very important aspect of your user manual's instructions. Each figure should be given
two numbers. The first portion of the number indicates whether it is the first, second, third, and so on, subject
within the manual. The second portion indicates the order in which the figure appears.
Take a look at the format used for the gure numbers in this topic. It does not matter if you format them
exactly as you see here or if you use a dash or another commonly used format.
■
If you gave every figure a single number starting with 1, by the time you get to the very end of your user
manual, you may then realize you need to add a new figure somewhere near the beginning of your text. If so, you will
be forced to renumber every single figure within your entire manual after that change. When you give your figures
two numbers, the first for the chapter (or subject) and the second for the sequence within that chapter or subject,
you only have to renumber the rest of the figures within the chapter (or beneath that subject).
Tip
User Manual Testing
Just as your BI solution needs to be tested to be sure it works, your user manual needs to be tested to make sure it
works as well. If you are the original writer of your user manual, you are unlikely to recognize missed steps, wrong
information, or confusing instructions. This is because you already know how it all works, and your mind fills in
the blanks.
Because of this, we highly recommend that you have your documentation tested by someone who is
unfamiliar with your program and is detailed minded enough to point out where they got lost and even make
suggestions on how to fix it. And, just like your BI solution, user manuals can benefit from user feedback after the
initial release so that new versions can be drafted with more precision.
All of this information about how to compose a user manual may sound simple enough, but at this point it is
still just hypothetical. To truly gain an understanding, you need to try it.
This next exercise is a really fun, out-of-the-box way of learning how to effectively compose written
instructions. It is based on an exercise from a college-level technical writing course.
exerCise 19-1. Creating a ChilD's play user Manual
This fun and simple exercise is a hands-on example of how to create a user manual and have it tested by a
team of users for accuracy and simplicity.
As humorously as this exercise may be written, the understanding that is gained from performing it is
invaluable for learning how to communicate instructions accurately and effectively. This exercises will not
