February 7, 2006 - SALT Conference in Orlando
Workshop: "Improving Interfaces, Instructions, and Training Materials Through Task Analysis" by Richard Catrambone, School of Psychology; Graphics, Visualization, and Usability Center; Georgia Institute of Technology
These notes extrapolate how I felt Richard's ideas mapped on to our authoring challenges.
Goal: Design training materials and interfaces to help learners/users to:
- Get started quickly
- Solve novel problems (which cookbook procedures can’t support)
Solution: Perform task analysis first! Task analysis of procedures provides guidance and roadmap, so create materials after task analysis. Task analysis
- Provides the raw material
- Is not standardized (adjust method to fit each project); there are dozens of methods out there, none of which have become widely adopted, because they’re too heavy and formulaic
- Requires skills of “knowledge extraction” (to brain-drain SMEs)
Method: Task analysis requires an interdisciplinary pair: Domain expert (SME) + “Knowledge extraction” expert (writer). Writer works intimately with SMEs before developing domain experience to do a novice-eye analysis of task domain (that is, don’t teach yourself the software before task analysis). Analysis must finish before starting production of any documentation/teaching materials.
- With SME, identify a set of problems/tasks you want people to be able to solve/do; this list serves both as the doc development plan and allows me to build skeleton book structures
- With SME, solve the problems/tasks (SME drives, you interview and take notes)
- With SME, demand “why did you do that? how? when? who?” for each step (“what”) and record the details of explanations, rules, definitions, implications, conventions
- Only now, on your own, use solutions and notes to create materials
Dangers of examples and demos
- Users beg us for specific examples and demos, but these are very often not effective at building knowledge
- Problem: Shows “how” and “what” very well (cookbook), but misses “why” – generalizations that build up intuitive understanding of the product
- Solution: Ensure examples/demos expose the underlying knowledge/rules.
Summary: How to create good documentation
- Ask: what does learner/user need to know/do?
- Insist on tight collaboration between domain expert and knowledge extraction expert
- Don’t invest effort into a formal, exhaustive analysis of the domain
- Focus on the novice’s needs; avoid getting sucked into conveying your SME’s view of domain
- Be as explicit as possible in revealing the rules of the domain
- Focus on the task analysis, and let the procedure set and authoring fall out of that work