RSS 
Email 
Twitter
FacebookWhy People Think Help Is Useless, and How To Change This Thought
December 19th, 2007 | Posted in Technical Writing 20 Comments »
I’ve been rethinking a previous post I wrote about the best response to the remark, “Nobody reads the help anyway. ” A better response is to ask people (at just the right time) to raise their hands if they’ve ever searched a help file. Unless someone is totally unique, most likely everyone has tried using help. When everyone has his or her hand raised to indicate they’ve used help, it provides irrefutable evidence that help is used.
The Real Problem
The real problem isn’t that people believe no one uses help, but that no one finds help useful. Most people are too tactful to say this outright, but it is a distinction you might raise: “Did you mean no one uses help, or that no one finds help useful?” The answer is probably both: people don’t use help because they don’t find it useful. And the more help isn’t useful, the less people use it.
Pyramid of Results
The “Pyramid of Results” (what I’m calling it) explains the root of the problem clearly (see graphic). Experiences are the foundation of our beliefs. Beliefs give rise to actions. Actions lead to results. Here’s the key:
If you want to change the result, you have to change the underlying experiences behind the result.
In other words, you can’t convince people that help is useful unless you change their experiences using help.
I once read that every poor help file is a black eye to the profession. I didn’t entirely understand that at first, but now I do. It means that even when engineers in other countries write terrible help documentation, though it seems unrelated to my products, life, and experiences, it actually drives the general experiences users have with help, solidifying in their minds the idea that all help is useless. Since help is useless, it’s unlikely that people use it. If people don’t use it, it’s not significant. Experiences form the basis of their beliefs. So as excited as I may be about my help file, I’m fighting against a mountain of poor experiences that users have had with other help files.
We have to change people’s experiences with help if want to change their belief about its usefulness.
My Plan to Change Perceptions
We can turn the tide of this thought, but it will require radical changes. It won’t be enough to merely provide well-organized, accurate, grammatically correct help. Help has to go above and beyond the mark of helpfulness. It has to be so good that it blows people away, that it gets your attention in a shocking way. People use the help and their jaw drops because … because … all the answers are there, in just the format you want. It’s simply awesome. It teaches you everything you need to know, right when you want to know it, concisely.
A Challenge for Creative Innovation
Although we sometimes think our field is dry, technical, and just a day job, if someone can figure out how to make help whallop the user with wonder and awe, it will be the creative innovation of the century. Once we begin to establish a standard and a precedence, people’s beliefs will change from feeling that “all help is useless and unimportant” to “the help at my company is exceptionally good and useful; I will explore it more often.”
Such a radical shift in help might have the following help characteristics:
- Audiovisual options for each topic (screen demos)
- Excellent search and index — searching for a word finds the topic
- Personalized help for your role and job title
- Ability to provide feedback to the help authors, to contribute, or otherwise interact
- Cheatsheets, cue cards, quick reference guides, and other handy references you can print
- Abundant visual displays of processes, workflows, procedures, and other eye-catching diagrams
- Help that calculates and aggregates the most popular topics based on number of times viewed and searched for
- An active, engaging blog about the product integrated with or beside the help
- Download options to load help content onto your iPod, BlackBerry, or other device
- Live chat support
- Holographic images of a friendly person explaining (with gesticulations) help concepts (I’m kidding here)
What do you think? What would help need to have to change people’s experiences for the better?
Tags: boring, creative innovation, online help, perceptions, pyramid of results
recent discussion on Tom Johnson’s blog
Check This Out!While looking through the blogosphere we stumbled on an interesting post today. Here’s a quick excerpt: Since help is useless, it’s unlikely that people use it. If people don’t use it, it’s not significant. Experiences form the basis of their
[...] Original post by Tom [...]
Hi Tom
Great article. I belong to the group that believes that everyone ends up using help whether one likes it or not. Our goal should be to pleasantly surprise the user by providing what the user is looking for in the easiest way possible.
To achieve this goal, I would choose the following potential characteristics from the ones you have listed:
1. Excellent search and index — searching for a word finds the topic
2. Personalized help for your role and job title
3. Download options to load help content onto your iPod, BlackBerry, or other device
4. Ability to provide feedback to the help authors, to contribute, or otherwise interact
There are other useful characteristics as well that might be helpful in certain scenarios.
Thanks,
Dharmendra
Hmm.
Perhaps the radical shift is helping to address issues without presuming that people will “end up in the help”. Instead of being the ‘last resort’ we should be striving to stop people having to get to that point.
That said, if they do end up in the help then yes, it should have a sufficient “wow” factor without being useless. Ultimately, make sure the information they want is findable by whatever means they choose.
Thanks for the comment, Gordon. I especially agree with your point about not having help be the last resort. But when you say, “we should be striving to stop people having to get to that point,” what exactly do you mean?
Dharmendra, first, what a cool name! Thanks for your comment. I’m curious if you have implemented #3 or #4. I’m not even sure what format to write in for BlackBerries.
I’ll think this out further on my blog but, ultimately, if you are a technical writer in a software company then you can get involved with UI design, usability and the actually planning and design of the software to make it easier to use and less likely to leave people ’stuck’ and reaching for the help.
Thanks Tom! I haven’t implemented #3, but sometime back we implemented a very basic version of #4. Unfortunately, we didn’t get much feedback. For #3, a start could be to add an ‘e-mail this page’ link.
@Gordon: I look forward to your post.
My comment was on how do we bring the ‘help is useless’ group to our side. Involvement of technical writers in the UI design of the software they are documenting is a worthy exercise, but it requires a huge leap of faith from the rest of stakeholders.
Ohh agreed! I’m deeply mired in pushing the UI design side of things here so it’s my focus, so perhaps *I* need to lift my head a little too!
Thanks for your interesting article Tom. Addressing how we enable users to do what they need to certainly requires creative thinking or creative approaches from technical authors.
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
Paul – regardless of their level of knowledge, users look for help when they are frustrated. If they don’t get what they want, the help has failed. That, again regardless of their level of expertise, makes them doubt using the help for that application.
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.
[...] Tom suggested that: if someone can figure out how to make help whallop the user with wonder and awe, it will be the [...]
[...] who haven’t used the help or didn’t even notice it was part of the application.Tom Johnson looks at people’s attitudes towards help and offers some suggestions for changing them. I like his phrase “wallop the user with wonder and [...]
I agree in principle, but the devil is in the details.
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.
Perhaps part of the problem is translation. We often give users the answers they need, but not in the format or language they would recognize.
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!
Craig, thanks for your comments. I agree with you completely here. It is a challenge, though, to make Dick-and-Jane help when the application is really sophisticated.
Why would I go ahead and read the help manual in the first place anyways?
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!!
[...] alternative experiences, see this comment by Joseph K on a previous [...]
[...] While most people are used to using Google to search for information in general, I have noticed that people still spend many hours getting tech help using the traditional help filters described at the beginning of this post. Traditional tech help methods have failed to keep up with increasingly complex and feature rich technologies. [...]