Product task analysis?

[Geoff Hart <ghart -at- videotron -dot- ca>]

Anna Gosling reports: <<My team has been "tasked" with a very specific 
analysis of our products. What this means is that each writer will take 
a component from each product and document EVERYTHING about it: how it 
works, how to install and configure it, etc. Each writer must create a 
list of all possible things each component can do, and then create 
end-user documents.>>

This is fairly standard "task analysis". Don't be intimidated by the 
"all possible things" or the large scope of the job; they don't expect 
you to document how to use the product to drive nails and feed the cat. 
The usual meaning is "document all reasonable tasks a user could be 
expected to attempt". That's a much more manageable solution.

<<These documents are online "solutions" that are part of my company's 
public knowledgebase, which means the documents must be short and 
concise. Writers don't have pages and pages to explain components and 
document steps for installing, configuring, etc. Writers CAN'T use HTML 
(because of the limitations of the editing tool they're using), but 
they can add hyperlinks to related solutions or to our Web site.>>

Concise is good; readers don't have time to read pages and pages. The 
way to come up with something concise is to identify what the reader 
needs to know rather than "everything that is available to be known". 
This requires you to determine what is essential to a process: if it's 
not essential, don't document it. (You can find out a lot about this 
kind of analysis by researching "minimalism".)

<<In short, how have you tackled such a monstrous task, especially for 
complex software that requires a great deal of explanation?>>

The first step should be to list all the functions. Next, group these 
functions based on how the functions will be used: that is, what tasks 
do they support? There may be many different ways to group functions; 
one of the best is the way you've already done this in your 
documentation. If not, think about reasonable categories: for example, 
you may have administrative, customization, and "actually getting work 
done" categories. Don't get hung up figuring out the perfect set of 
categories. Aim for "good enough for most users".

Another useful tip:

<<The other thing is the writers aren't supposed to be recreating our 
user guides or training manuals. So they're really looking for some 
direction about the best way to do this project. They can't pull from 
existing documentation; they have to create short, but detailed 
solutions>>

In fact, you _can_ "pull from existing documentation": if the docs are 
considered acceptable or even "really good", they provide you with a 
great starting point for listing all the functions and how they have 
already been grouped into tasks! You mentioned above that you can 
hyperlink; if that's the case, you can achieve conciseness by 
hyperlinking to the appropriate portions of the existing documentation.

--Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l 

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.