Re: Problems Documenting An Application

[SusanH -at- cardsetc -dot- com]

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
architecture.

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