TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> Our department has planned to release a *light* version of our
> current software application. This light version will have limited
> functionality...
I worked for a company with a somewhat similar situation. In our case,
the application had six main modules, which were further broken down
into roughly 40 mini-modules or "granules". With only a few
exceptions, customers had to buy only what they needed. In addition,
we included a demo system which provided access to all areas of the
application, which was a general business accounting application.
(The application also let users insert or remove fields, rearrange
screen layouts, modify processes, and so on, so we really didn't know
what the application would look like when it was fully implemented.)
Our approach was to use Help as much as possible to document the
details, such as field definitions, and discuss all of the concepts
and procedures in the manual. We tried to use a minimalist approach in
the manual.
Where applicable, we included a note telling the reader which granules
were required to perform a given task. The note also reminded the
reader that he or she could experiment with these features in the demo
system. For the most part, the sample data shown on screen shots and
used in examples matched that in the demo system.
The result was a very large field-level Help system and a reasonably
sized, task-oriented manual. The feedback we received, both from
pre-release usability tests and post release comments was favorable.
The manual was also used as a marketing tool. By having information on
all system capabilities in one manual, prospects found it easier to
evaluate the product. For existing users, the manual reminded them of
capabilities they had not yet purchased.
Those are some of the benefits we found with that approach. It worked
for that application.
Depending on the application you are documenting and the tools you
use, it might also be possible to use conditional text features to
handle your situation. For instance, using FrameMaker, you can set up
conditional texts and define multiple "books" which share common
files. You may be able to achieve the same result with Word.