Even though I’m a writer myself, I don’t like to go through a series of steps to resolve my problem.

I prefer “quicker” resolution because I have deadlines to meet.

When users can find such “quicker” resolutions in the help manual, why wouldn’t they use it? At the end of the day, “solution” is what they are looking for.

“Customer” is always right and their time is always more precious than ours ‘coz their time includes the money they’re paying for our product and support.

The best way to make sure users find our help manuals useful is to write from “their” perspective, not blindly following the “writing guidelines”.

I think every help system should have one section dedicated to “quickies”. Other sections can include detailed information that customers can go through when they’ve time (assuming!).

This way, we’ll be able to deliver them both the things; “quickies” to save their time, and detailed information to help them understand our product better.

The real challenge, therefore, is not to change users’ experience, but to change “our” way of thinking and writing. Let’s put ourselves in customer’s shoes and think what do we need. This will eventually change users’ experience… Trust Me!!

It’s as if we’re writing Ulysses and users are expecting Dick and Jane. We need to write Dick and Jane help. I’m not promoting talking down to users. What I’m talking about is acknowledging that most users want a quick answer to a particular problem, written in jargon-free language, delivered in a help format that they are already familiar with.

No two help systems written by different companies look alike. Nore are they written in a similar fashion. Is it any wonder users call Support?

I guess I’m arguing for standards, aren’t I?

Great post, Tom!

A lot of people don’t like audio/visual elements so it must be an option (i.e., a button to click on to open a window). Such things also bloat the help system significantly. Especially if you’re documenting a large complex product. Professional level audio/visual content can also be expensive/time consuming to produce.

Feedback options are rarely used. We’ve implemented an email option in our online help so that customers can provide feedback. So far, in the few years it’s been available, we’ve had exactly 0 response from external customers. Occasionally the feature is used by internal staff.

As for the rest, I think staffing problem are usually the impediment. We don’t have enough staff to do the bare minimum to ensure quality, and management doesn’t care (again the perception is nobody uses the help so why invest in it, or Docs is a cost center and the real value comes from the developers).

And, an even greater impediment is the underlying technology used for help delivery. For example, on Windows, HTML Help is the standard; quite frankly it is buggy, limited, and bloody awful.

If you are lucky enough to deliver web-based help, then it comes down to fighting with conflicting browser/web standards, providing limited index or search fucntionality, or writing your own index/search routines in java (oh, what’s that? The IT dept doesn’t want Java enabled? Too bad). And the end-user gets a different help experience with every product they use requiring them to adjust to a new help interface every time.

In general, what I’ve learned is to keep documentation small, simple, and clear. Once it reaches a certain size or complexity, all the audio/visual and “feedback features” in the world isn’t going to help. I think usability/poor interface design in the product is the biggest hurdle for documentation staff and the end-user.

You talk of pre-existing anti-technology feelings? That is all part of the equation. I am a self-confessed geek yet I too can be frustrated and anti-technology, wanting an answer to an issue without having to research and dig and fight to get it. I am no different from any level of user in that respect.

As I’ve said on my blog, the prolificy of information, and the instant results (right or wrong) that Google brings means that EVERYONE has the expectation of getting an answer immediately.

What Tom is rightly suggesting is that we need to instil confidence in the provided help, to get people coming back to it to get the RIGHT answer, rather than ANY answer. Google had WOW factor when it first launched by being simple and accurate.

I have to disagree with you, however, that each time a user has a poor experience with help it can delegitimise all help. That will be the case for some users, but how often does that have more to do with pre-existing anti-technological feelings? Some users have an expectation of poor quality, of not being able to understand or of not being able to perform a task. (In reference to your pyramid, you can say that their a priori beliefs inform their experiences which in turn reinforce their beliefs.) I would argue that users who are comfortable with technology are more forgiving because they are not so dependant on the help as they are better able to evaluate the information in context.

Yes, personally, I feel slighted when people complain about help in general but that is because I take user assistance very seriously – it is important that information be of as high a quality as possible. I think most users can recognise the distinction when their feet are held to the fire (metaphorically speaking of course!).

Regards
Paul