Information They Can Really UseJune 18, 2011
That’s the theory, at least.
My introduction to this new process left me scratching my head. How is scenario-based content different from what we’re already doing? We’re writing tasks, not concepts, so I had difficulty imagining how I’d apply the new initiative to my work. We had several more presentations and finally, I spoke directly to a writer on a different product who’d already begun using the process.
But it wasn’t until Tom Johnson posted this essay on the failures of topic-based authoring that it all made more sense. As Tom notes:
“The problem with topic-based authoring is that many times, these tasks don’t mean a whole lot in isolation.”
That statement reminded me of my experiences teaching SAP a few years back. When we pilot-tested a course I’d written to teach users how to create product codes in the new system, we discovered all the course did was present a series of isolated tasks, one after the other, with no backbone to tie them all together. Because the SAP system was quite different from the legacy system it replaced, the new tasks did not align perfectly with old ones, so even users’ domain knowledge did not help them. We ended the pilot early and redesigned the course with the end-to-end scenario superstructure Tom describes.
I sat with the students themselves as well as the SAP development team and produced job aids, process flow charts, and various cheat sheets that were essentially a bread-crumb trail through various use cases. For example, the use case for Create a Sellable Product Code is NOT identical to Create a Component Code. Creating a sellable product code required users to perform at least five different SAP tasks, including creating component codes. Worse, those tasks had to be performed in reverse order when compared to the legacy system. The end result was a well-trained user group able to successfully create product codes.
If you’re wondering why I did not design the course this way from the beginning, you’re not alone. The answer? We thought we’d covered that during design. The SAP implementation team consisted of actual business users, yet even they did not consider tying together the tasks required to achieve some goal. Every one believed it would be obvious to users when just the opposite turned out to be true.
This is a problem quite typical on project teams where schedules are aggressive and access to the right experts is scarce. As we adopt our new scenario-based content strategy, I’m concerned the same fate will afflict our documentation. We don’t always have access to real users and must rely on internal experts from Support, Development and Education.
I’m still not sure how to actually apply our new content strategy but I do think it has the potential for making our information truly usable. What do you think about scenario-based documentation?