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