Leader DIRECTOR-SPONSOR'S 
COLUMN

INDUS
September 2002 


 

 

 

 

   Home

   Editor's Footnote

   Dear Editor...

   Presidential Gavel

   STC India Diary

   Member Profiles

   DS's Column

   About Us

   Archives

   Situations Vacant
   Networking
   Learning
   Tidbits
Do We Have to Hide Behind the Words We Write?

By Rob Houser

Have you looked at the computer section of your local bookstore lately? The shelves are bulging with books that supplement the documentation (online and paper) that is currently shipped with the product. What are these books? Why are they so successful? Do these books have anything to teach us as developers of user assistance?

What are these books?

The computer books that users buy in the bookstore are mostly aBooks combination of strategy guides and "how to" instruction manuals. They tend to be written in a more informal (or even irreverent) tone than the official documentation. They provide instructions using common, everyday speech. They incorporate lots of graphics, including cartoons. They tend to have lots of tips and tricks highlighted throughout the instructions. And, unlike official documentation which tries to spin product problems as product features, they point out bugs, shortcomings, and work-around with delight. 

Why are they so successful?

Most of these books claim to explain more about the "real world" use of the product than the official product documentation, and perhaps they do. These supplemental computer books explain how to get real work done using a product, not just how to use the product for its own sake. They provide examples of the final output; they provide scenarios that illustrate the successful use of the product; and they use the vocabulary of their users, not the product. The authors of these books can only provide such information because they have analyzed the way users work and organised the information about the tool within the context of the user experience.

The computer books that users buy at the bookstore provide more direction and advice than the product documentation. Official product documentation lists all features often without ranking them by importance or usefulness; they often fall prey to explaining the underlying functionality in too much detail; and they try to explain every possible way to do every possible task. They are providing information, but not direction (or even instruction). In contrast, supplemental books point out the best way to do a task (rather than all of the possible ways). They focus on what users "really" need to know using the user's language. Successful computer books act like a guidepointing out the proper direction, calling attention to possible problems on the trail ahead, and making recommendations about how to reach the final destination.

Another interesting aspect of supplemental computer books is their tone. The authors of these books do not attempt to mask their personalities. Instead, they identify with the reader, building a strong sense of trust. They use humor and frankness to encourage the users to approach the subject without fear of failure. They use a more conversational tone than is often found in traditional user documentation.

What do these books teach us?

In most cases, I believe our users would like for us to step out from behind the words we write. They want us to help them get their work done; they want us to provide direction and advice; and they want us to make our products approachable (and even interesting).

We have to get closer to our users if we are to create truly successful user assistance. While many in our industry say they support investigating users, few are still investing the money and time in gathering real information about users, tasks, and environment. If we don't know how users are working now, how can we provide a product that helps them get their work done successfully? We have to reflect the "real world" application of our products, or we lack credibility with our users.

Once we know how our users work, we must provide direction and advice to help them use our product to do their work successfully. Too many products refuse to take a stand on how a task should be done. They provide multiple paths and vague signals to the users, not to accommodate different users styles but to avoid making any suggestion at all. I have heard too many developers of user assistance say that they did not want to "restrict" the user's options when using the tool. Users don't want options so much as they want to get the job done. Of course, it is a good idea to provide shortcuts for experts, but for the majority of users, especially beginning users, we must provide more explicit direction about what needs to be done next and more useful advice about how to complete the task effectively.

Finally, we should not forget how boring it can be to read and interact with user assistance. Users know that people created the product that they are using, yet we work hard to keep any personality out of our user assistance. While tone may not work for all audiences (especially international audiences), it does go a long way toward putting users at ease with the product. We don't have to take the common persona used in supplemental computer books of "us against them." Rather, we can project a tone that says "you and I will get the job done quickly, effectively, and as painlessly as possible."

Take a look at the supplemental computer books in your local bookstore and see what kind of lessons you can learn from them. The market clearly thinks they are a good idea.

(Rob Houser is the Director Sponsor for STC Region 3. You can contact him at rob@userfirst.net.)


STC India | Home | Contact Us

Copyright © 2002 India Chapter STC. All rights reserved.