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[2]: Request for change From:Arlen -dot- P -dot- Walker -at- JCI -dot- COM Date:Fri, 9 Feb 1996 06:59:00 -0600
The problem: boss wants us to develop "system" documentation rather than
"user" documentation -- that is, how the system works vs. how to use the
system. I believe he feels it will be easiest to write that kind of
document, and since we have only two writers, that's probably a real
valid concern.
Since your boss has also been a developer in his time, you might try asking him
this question: Should the system you're documenting be easy to write, or should
it do something useful for the user? It doesn't matter if it's easy to write; if
it's not useful it won't be used.
Your product is supposed to save people's valuable time. If it doesn't do that,
it will never sell. What good it is to be able to save an operator's time if the
operator can't figure out *how* to make that savings happen? If an extra day of
time spent documenting saves even one second per user, then you only need 28800
sales to break even on time.
Have fun,
Arlen
arlen -dot- p -dot- walker -at- jci -dot- com
-----------------------------------------------
In God we trust, all others must supply data
-----------------------------------------------
