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: Philosophy: the Aim of Technical Comms? From:Chuck Blessing <chuck -dot- blessing -at- CBIS -dot- COM> Date:Fri, 3 May 1996 06:31:55 -0500
Nancy Hayes wrote on 5-2-96:
>>And I would add, "whether or not they really =want= it".
I work with
technical procedures, and if we gave the users what they need, when they
need it, and where they need it, we'd end up with hundred-page procedures
(or 2-page procedures if we're talking about a senior operator).
I'll agree that user-oriented technical writing is the best idea, but in
many cases what the user needs isn't necessarily what the user wants.<<
Giving users just what they want rather than what they really need is a common
trap that software development falls into when writing requirements. The
argument for this is that "we are customer oriented." Requirements then become
the verbatim requests of the customer.
The trouble with this is that the initial wants of the user do not necessarily
satisfy their real problems. If you just give them what they want and later
they discover that it is not what they really need, then the user will
ultimately be dissatisfied. They will, of course, blame this on the software
developer (or the writer in the case of unsatisfactory documentation)--and, of
course, they are absolutely correct in placing the blame.
The value that a writer brings to documentation development is guiding the user
towards understanding their real problem and understanding their real needs. If
the writer doesn't do this, then the writer is not adding the value to the
project that the user should expect. If successful in guiding the client to a
real understanding of their problems and needs, you will find that their wants
and needs will converge, and the user will get a satisfactory product as a
result.
Chuck
*********************************
Chuck Blessing
Cincinnati Bell Information Systems, Inc. (CBIS)
Cincinnati, Ohio
chuck -dot- blessing -at- cbis -dot- com
- OR -
cjb -at- one -dot- net
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
