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.
If the project as I understand it is showing people how to use Microsoft
Outlook, why do you need to document what it can do? Microsoft has
already done that.
It seems to me that all you need to produce is a shorter document
regarding how to get Outlook working as an internal deployment, including
info on how to handle possible difficulties/who to call when the thing
breaks. Then maybe you can synopsize OUtlook's many feature and point
them to Outlook's help.
G
On Mon, 27 Jul 1998, NetBrett Thorson wrote:
> I am reading the "Managing Your Documentation Projects" book by Hackos.
> Previously, we were in an ad hoc state for creating our documentation.
> However, I am bringing our doc projects up to par with our very organized
> software creation projects.
>
> There is one thing that I don't understand so far. I am looking at two
> possible projects that we could use for a test bed. The first project,
> already has the software installed, the people are using it, and they know
> what they want.
>
> So that helps out a lot with the question, "What do you want from the
> documentation?"
>
> However, the other project I am testing this on is the deployment of
> Microsoft Outlook internally. I know what the product can do (e-mail,
> calendars, etc.) But how do I discover the tasks other people want to
> perform.
>
> I would first need to introduce them to the product,
> Show them what it can do
> Ask them what they would want to do with it.
>
>
> Further more, I am wondering how you people write these documents without
> even having a product made that you can show them.
>
> So in the end, I guess what I am asking is how do we as tech writers
> discover what the user wants to do with the system, before they know what
> the system can do?
>
> --Brett M. Thorson
>
>
>
>
