Information Technology Reference
In-Depth Information
glossy, shallow and weak, which merely reinforces the original impres-
sions. Good design of informational documentation is important. Designers
and managers must devote the necessary time to interact with those who
prepare such documentation so that the right information is conveyed
with proper emphasis where it needs to be.
Generating informational documentation is a two-step communication
problem — from technical to the marketing persons within the company
and from them to the outside world. Done early on in the development
process, it can be a useful process, if only to see how internal and external
perceptions of something can be so different. At times the discussions
can lead to some design improvements in the application itself.
A workhorse of the software industry has been the white paper. They
are used as a marketing tool. It is an attempt to inform while subtly, and
not so subtly, positioning ones product. The sponsored nature of the
document engenders skepticism. A lot of information gathering has, of
course, moved to the Web. This allows a powerful opportunity to keep
the information up to date at minimal costs. Unfortunately, not every
company uses this opportunity properly — information provided may be
shallow or out of date, more style than substance.
Problems with Documentation
There are some problems in our approach to documentation in the
software industry, including:
Just as in other products that we use, software usage is also largely
repetitive. Most users do not need to refer to documentation after
the initial learning phase. This is why formal classroom training is
considered a better option by some software vendors. It is certainly
good, but users change over a period of time. That is why “train
the trainer” is preferred. More importantly, however, it is only in
software that one will find that two software products created by
different vendors in the same business domain (e.g., CRM [customer
relationship management] or ERP [enterprise resource planning]),
solving similar problems, will likely be very different in usage. A
cursory glance at the user interface will not tell enough to be able
to start using the system. Unlike DVD players, cell phones,
or blenders from different manufacturers, the learning curve for
software is much slower. This strongly reinforces the continued
need for documentation.
In the early days of computing, we expected developers also to
be able to do end-user documentation. Programmers have not
