"Perhaps the true measure of a good idea is its persistence, even though folks are slow to pick up on it. SGML is a good example. It seemed like a great idea, but for a long time, had trouble getting traction in the general tool space. Then it started showing up at technical communication conferences wearing a name badge that said, “Hi, my name is DITA,” and suddenly, it’s a hit!
The same seems to apply to use cases. It’s hard to find anyone who disparages them, but those who use them are still a minority. In a previous life as a UX designer, I used use cases and developed a great respect for them. But it wasn’t until recently that I began using them to design user assistance. Why did it take me so long to get back to these reliable work horses of user-centered design?
As is often the case, it took a problem that needed solving to make me return to a useful approach I hadn’t followed for a while. The documentation team I belong to was feeling pressure to break out of the documentation whirlpool that is so typical of waterfall development cycles—we can’t document the user interface until it’s finished, and it’s not finished until the last minute before release. We also needed to align ourselves with a development process that was moving more and more toward an agile development cycle. So we decided to incorporate a use case methodology into our information design and development process to meet the following objectives:
* Start information development earlier in the product development process.
* Have testable information products earlier in the product development iterations.
* Improve our focus on user context.
* Maximize reuse of design documents in the production phase.
The first two objectives—starting information design early and having testable information products earlier—go hand in hand. We wanted the product’s development iterations that were going into testing to have the procedural Help topics in place. Not only would this help us validate the accuracy of the topics, it would give the testers a framework against which to test the user interface, because the Help would describe the ideal way in which the product was intended to work.
Our desire to improve our focus on user context came from our commitment to
* de-emphasize behavioral Help—which tells a user to “click this” or “type that”
* include more decision-support Help—along the lines of What’s a good value for this parameter? or When would I choose option A over option B?
* maximize the reuse of design documentation in production—which would help us to accommodate increasing demands on our limited resources" (Continued via UXmatters, Mike Hughes) [Usability Resources]