RSS 
Email 
Twitter
FacebookVista Help Emphasizes Concepts in Effort to Create Power Users
June 4th, 2007 | Posted in Technical Writing, Web 2.0 2 Comments »
In this podcast from the Atlanta chapter, Rob Houser talks about Vista help, noting that topics in the help aren’t just steps. They often have meaty conceptual explanations before the steps. This is a trend away from the heavily task-based help that has been standard in years past. For an example, look at this sample sample help topic from SharePoint 2007’s help (excerpt on right). Look at all that conceptual stuff before you even get to the numbered steps.
Rob also says Microsoft’s help now uses more screenshots, but the screenshots are more instructional. They often illustrate concepts and are more purposeful, rather than just showing the interface.
My Reactions
I like these two points. Some users need the basic, task-only topics. But power users need more information. And we often skimp on the conceptual, business-oriented information that users want because it’s harder to write.
Why is it so hard to write? Oftentimes companies roll out software without knowing exactly how it will be used. So while the business, real-world information is essential, Rob says it often isn’t discovered until the product has been used for 6 months or more.
The latest article in June’s Intercom (“Kicking and Screaming: Modernizing Today’s Help Systems”) talks about providing user forums and other Web 2.0 mediums to supplement traditional help. This allows users to fill in the gaps for this business-process, real-world use information.
Lately I have been thinking that technical writing is more rewarding if you write the harder, more conceptual-based help. Describing simple tasks gets pretty dull. Sometimes I like the challenge of figuring out the impossible (or at least the hard to do stuff). Listening to Rob’s talk reinforced to me the importance of conceptual information.
You make some good points on task description help vs a more overview orientated type of help that answers questions like “Why and when should I do tasks X, Y, and Z?”
Yes, it is often amusing that engineers in particular often have little or no knowledge about what the purpose of the product actually is. A moment’s thought reveals they don’t actually need to know this information, since their job consists of making sure a particular report populates correctly, or a particular field accesses a specific cell in a database.
I’ve found that the best people to ask for this product-purpose kind of information are the sales and marketing departments.
They are always much closer to the clients, and often were involved in the very early stages of the product concept. Many products are a result of a client asking for something, or research that indicates clients are dissatisfied with something or would like something that answers a specific need.
In theory (and practice) the project manager and product manager know this kind of information too, but on large projects they are often too busy and stressed to be able to give you detailed information, especially for follow up questions and issues that arise on a day to day basis.
It’s also true that companies are often surprised at what clients do once they’ve bought a product and explored its capabilities.
Sadly there isn’t much we can do to anticipate this, except recommend a review of the documentation say… six to 12 months after a product has reached the market.
You also mention that “Describing simple tasks gets pretty dull.”
Welcome to the major down side of the job!
Perhaps it’s important to remember that describing simple tasks is dull but essential. Especially for the majority of users to whom the product is just a tool that should help them do their jobs, and crucially, not get in the way!
roGER,
Thanks for the thoughts. I agree with what you say about talking to sales and marketing people. They’re always looking for the right angle to pitch the products.
Re the bit about simple tasks being essential, yes I also agree. There is a need for both in the help.
I guess this leads to part of the problem of documentation. Beginners need novice help; power users need advanced help. You throw it all in the same file and it suddenly mushrooms into a giant file or document. Then the same users click the help and say eek, I can’t find anything.
How do you tend to manage the organization of beginner and advanced information?