Pity the Poor User Guide
Does your company offer a product or service that requires a user guide? On a scale of 1 to 10, how would you rate the quality of your user guide rate compared to the quality of your product? Okay, now, how would you rate that guide if it was the only form of collateral you had available to market your product? No, you can’t use negative numbers.
I realize user guides aren’t sexy, and by the time your product passes beta testing, you’re probably anxious to get it out the door. User guide development becomes an afterthought.
Like it or not though, any document you produce that comes in contact with your customer is a marketing tool; user guides included. The quality of the guide you publish is a reflection of the care and thought put into your product.
A hastily assembled guide raises a red flag in a customer’s mind. If user documentation is poorly organized and hard to follow, what shortcuts went into the design and development of the product? On the other hand, a thoughtfully-produced, concise, and user-friendly reference is an asset that pays dividends in reduced customer support costs, better buzz on user forums, and recognition in product reviews.
Unless your development process is entirely broken, you don’t need to reinvent the user guide development process, and you don’t need to spend a bundle to get a great guide. Here are a few thoughts that will help you improve the next guide you produce.
Find out what’s important to users, then prioritize the development of your guide around that feedback. We often do this for the development of the product, but not for the documentation. What features require the most guidance to master? What are the most frequently used portions of your system? What do your metrics and logs show? What do people search for in the support section of your website?
You can gather some of this feedback by talking to users, but much may already available from your website analytics report, support forums, and help desk tickets. Analyzing and abstracting this information will help you create a user guide priority list. Perhaps you need to address a particular software feature differently, discuss it in more depth, or offer more examples.
When writing a new guide or revising an old one, adopt a conversational tone that involves and assures the reader. If you want some great examples of this, pull out a copy of a user manual for a common product, then pick up a copy of the O’Reilly companion guide. I’m working through Sharepoint right now. Microsoft’s documentation isn’t bad, but the O’Reilly title, Essential Sharepoint 2007, is better. It’s written in a comfortable but reassuring style that gives me a little confidence boost as I work through the examples to complete a particular task.
Try new user-generated models to build your documentation. Have you done a search on your product to see if user-generated documentation already exists? There may be a growing body of content available for you to use as a basis for your own effort. Not only that, if you have cultivated a significant online following, you may be able to use tools such as a wiki to encourage users to develop documentation that can serve as a model for your own.
Consider new forms of documentation altogether. It’s never been easier or cheaper to create new forms of interactive documentation. If you produce a physical product, consider producing a series of how-to videos. If your product or service is software-based, take a hard look at creating screencasts to show users how to perform those frequently used tasks. Producing these items serially also offers you a way to stay in front of your customers. Here’s a sample of screencast documentation for a blog template called “Thesis.”
These are just a few ideas for producing better documentation for users. What are your ideas? What have you done to improve the user guide experience for your customers? Has it made a difference in the mind of your customers?
