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: inhouse vs outside doc From:"Rebecca P. Rachmany" <purple -at- NETMEDIA -dot- NET -dot- IL> Date:Mon, 10 Aug 1998 13:03:33 +0300
> because the purpose and focus of third party books is just
> completely different from the regular documentation.
<snip> one of the neat things about writing third party
> books is that you can focus COMPLETELY on the user needs
> and not deal with corporate marketing issues, product positioning
> issues, or the "this feature is really important and everyone will
> want it and it works as designed--it's not a bug" issues.
>
> Many (probably most) users don't WANT or NEED full instructions
> on using the product--they want just enough to get them
> started and doing what they need to do
I agree. I still think users deserve to get full documentation with their
tools. However, the more I meet users, the more I think that one of the
main purposes of a user's guide is to answer the question "What do I do
_now_?", whether now is at the start or after the user has already gotten
him or herself into a mess.
I spend a lot of time trying to convince my customers to allow us to create
a useful manual. Marketing usually isn't the biggest problem; R&D is. The
R&D department tends to take the attitude so well expressed by Tina the
Technical writer when she said "Let's be honest userboy, if you need to be
told _that_, you're too stupid to use this product." The R&D folks tend to
nix chapters like "Getting Started" or neglect to fund a decent tutorial.
I don't see an intrinsic conflict between providing documentation that is
useful and creating documentation which answers needs of marketing and R&D.
I think laziness (and penny-pinching) within organizations prevents them
from creating good user documentation. In the end, they are just funneling
money to their service department, which has to answer all of userboy's
questions.
My question is, if you are a third-party technical writer, how do you know
who the user is? The Dummies books have chosen their readers, to some
degree, by using a clever title. However, that is not the case for most
third-party manuals. How can you focus on what the user wants if you don't
really have contact with the user?
Rebecca Rachmany
General Manager
TECH-TAV technical and end-user documentation
PO Box 2419 Tel Aviv 61024
info -at- tech-tav -dot- com http://www.tech-tav.com
