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.
Subject:Re: Understanding the things you document From:Dan Lewis <danlew -at- DELPHI -dot- COM> Date:Wed, 7 Jul 1999 08:44:58 -0400
Thom Randolph wrote:
>It probably depends on the product complexity and the amount
>of that complexity "surfaced" to the user.
I think there is another point which is perhaps an amplification of this.
I write manuals for users of a software product. What I am documenting,
almost exclusively, is the user interface. While on occasion I do need to
at least describe some of the algorithms, or their underlying assumptions,
most of my documentation is task oriented and descriptive. For this sort
of documentation I would argue that it is something of a benefit NOT to
know too much of the detail. I purposely avoid paying a lot of attention
to the engineers before I get my hands on the interface. This way I can
more easily put my self in the mind set of the user. My expertise lies
more in my ability to scope out an interface and break down complex tasks
into simple steps. Often in the process of doing this I discover bugs in
the interface that those who already have a firm knowledge of what is
supposed to happen don't notice.