Re: Problems Documenting An Application

Subject: Re: Problems Documenting An Application
From: SusanH -at- cardsetc -dot- com
To: pbw3172 -at- yahoo -dot- com
Date: Wed, 23 Feb 2000 08:33:36 +1100

Paula wrote
"I have been tasked with documenting an entire application by myself. The
client wants each screen as a separate work instruction with a data entry
table for the user to refer to for field entries.... My problem is that
this application has SEVERAL screens and I don't know where to begin."

I know there have been endless discussions about user task analysis, with
various list members championing either side BUT this is a perfect example
of how flexible a user-task architecture is as opposed to a product

If you base the documentation on how all the bits of the product fit
together, and worse still, if you are in Paula's position where there are
no state diagrams or equivalent system documentation, you cannot start
putting things together until you bring light to the world in darkness.

On the other hand, if you list all the significant tasks that users do
(significant = whole, meaningful business tasks)
1. you have an immediate structure for your documentation.
2. you can slot in the customer's requested screen descriptions (oh well,
sometimes management is very insistent and believe they are the experts!)
and you can slot them in as they occur in the user task.
3. you EVEN have an organisation for your information domain that matches
where users will probably be coming from!!!!

You may find that you break up the original task groupings if there is
overlap between tasks but at least you have a rule of thumb for making
design decisions and moving forward.

Susan Harkus

Previous by Author: RE: Web media... shopping cart statistics
Next by Author: RE: FWD: Getting out of a bad situation
Previous by Thread: Re: Problems Documenting An Application
Next by Thread: Re: Problems Documenting An Application

What this post helpful? Share it with friends and colleagues:

Sponsored Ads