Re: Task Oriented Documentation For Non-Task-Oriented Software

[LDurway -at- PAV -dot- COM]

Sounds like task-oriented documentation is exactly what your product needs
to help the user make sense of it.  It's not really your documentation that
will expose the bad design of the software:  the bad design is already
evident, and any user who learns how to use the product will notice the bad
design whether they read your docs or not.  A task-oriented manual simply
shortens the learning process for them.  A good task-oriented doc could
serve as a valuable resource to your development group for the very reason
you name:  it will expose the errors in their design & emphasize the need to
improve the interface in future.  Sometimes the writer is the closest thing
a group has to a human factors expert.   1/2  :-)   I argue that your first
responsibility is to the paying customer, not the development group.

Lindsey

> -----Original Message-----
> Question to all listserv members:
>
> In creating end user documentation for an existing (complex) software
> package, if the software was NOT designed task oriented, can the end user
> manual be written in such a fashion?
>
> Typically, to accomplish a given end user task with our software, you have
> to travers up-and-down through several (seemingly totally unrelated)
> menus.
>
> Problem:  When you write task oriented documentation for this sofware
> (i.e.
> bring all required menu selections together under the specific task), the
> lack of task oriented design becomes glaringly evident. The documentation
> acutally prompts the end user to ask the question "Why do I have to do so
> much jumping around between menus to accomplish a given task?"  This does
> not make us look good.
>

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=