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.
I didn't catch the start of this thread, but a recent posting said:
"Needs of the user" and "understanding the product" are the same thing.
I agree with this formulation if it means that the user must be led to
understanding the product by the writer. If it means the needs of the user
are equivalent to the writer's understanding of the product, it's completely
false. If the latter were true, programmers would be the best writers of
user documentation, which is historically not true. Five minutes in a
usability lab will demonstrate conclusively that "understanding the product"
must reside in the user, not the writers or programmers, for the user to
operate the product.
A lot has been written lately about the writer's need to understand the
product technically before writing. But how far does that understanding have
to extend? For example, I couldn't tell you how a single line of Windows NT
is coded, but I can operate the software efficiently. I can also write
instructions for operating Windows application software without
understanding a single line of code. Yes, a certain understanding of
underlying databases and data processing (what happens to the data) might
be necessary to explain the operation of the software to a user. However, my
understanding of the product doesn't need to approach that of a programmer.
Nor do I need that level of understanding to get the programmer's respect.
My job as a writer is to wrest the information the user needs from the
programmer, who has far more information than the user needs. As a writer, I
may also need to understand more than the user in order to keep technical
nuances correct while glossing over them for the user. If I keep the
programmer focused on giving me what I need as a tech writer, I will usually
get his/her respect. If my questions show my homework and some high-level
technical understanding, I will get respect. If I don't waste time,
including listening to technical tangents by programmers, and always pull
the discussion back to the relevant information, I will get respect.
Overemphasizing writer technical understanding wastes time, in so far as my
central job function of communicating with users is concerned. The trick as
a writer is knowing when I know enough. This state of knowledge is
admittedly a moving target, and I may be wrong, but that's what technical
reviews are for. Writers who feel we have to have as deep an understanding
of the system as the programmers may be indulging our personal interests
more than performing the art of technical writing efficiently.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by an
anonymous satisfied subscriber since 1994.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
