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.
Re: The audience doesn't know what it needs was: RE: What is "wellWritten"?
Subject:Re: The audience doesn't know what it needs was: RE: What is "wellWritten"? From:Mary Arrotti <mary_arrotti -at- yahoo -dot- com> To:Gene Kim-Eng <techwr -at- genek -dot- com>, techwr-l -at- lists -dot- techwr-l -dot- com Date:Thu, 17 May 2007 06:47:29 -0700 (PDT)
Related to this is that it's not uncommon to jump to possible solutions before needs are actually identified. Through business requirements (when successful), you can identify client needs. After this - your organization can work on putting together solutions to satisfy those needs.
Documentation doesn't always go through this process. In my experience, the people working directly with the clients don't always identify client needs - instead they just pass on the client's proposed solutions (or what they think will satisfy those needs).
Here's an example: two separate clients ask for changes to the release notes. One wants install info removed, another client wants more detailed install info to be added. They were proposing solutions but what were the problems/needs? The one client wanted to be able to distribute high-level release info without technical details. The other client wanted to get their install info without having to spend a lot of time with the lengthy install guide. So the solution could be to leave the release notes as is but create a separate executive summary doc and rewrite the install guide.
Gene Kim-Eng <techwr -at- genek -dot- com> wrote:
But they often do specialize in whatever work the
other tools are supposed to support. I don't know
how low the level of knowledge of the average SW
user is, not being in that business, but for the products
I've worked on, when I encounter people who express
the view that the users don't know what they want or
need, it usually just turns out that the the users have a
pretty good idea what they want and need and the
people who think they don't are developers and/or
product managers who have simply not taken the time
to find out. Thankfully, I have yet to encounter a
technical writer who doesn't at least *want* to find
out, even if the company is not terribly supportive of
the idea.
---------------------------------
Pinpoint customers who are looking for what you sell.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
