Is the "Help" feature really helping?

Question

Almost all apps/sites have a feature 'help' regardless of type and subject of the app/site. I have rarely seen people using the same for their benefit. I would want to know if it's worth putting the effort into developing a help feature if it's only used by a few people?

So, my question is

1. Is it really necessary to give help feature regardless of subject/app type?
2. Do people really want a feature such as 'help', whereas most of them would just like to play with the site and explore themselves (for example in FB we just play around and get to know many of functions instead of going for help, at least me :) ).

Answer 1

Someone once said that "Help is for the advanced users". (Don't remember the source now, but it's been with me for the last 15 years).

At first, this sounds like a contradiction. But if you think about it, it's true.

Novice users need an intuitive interface. If they are stuck, they will most likely play with it until they figure it out - or perhaps leave empty-handed.

Advanced users OTOH, they will use the help to solve advanced tasks.

When designing help, it is important to bear this in mind.

• Nobody needs a help that says "this is the close button and that is the open button".
• The advanced users who opens the help need a task oriented description on advanced topics.
• The (few) novice users who look at help also needs a task oriented "get started" description.

---

Help is an advanced topic, and many professionals advocate that the help systems should be considered to be a separate project and thus a project that need dedicated analysis, design and testing.

---

Answer to the question
Where do you draw the distinction between a "novice user" and an "advanced user"?

Rule no. 1: Know your user.
The user can actually be novice/intermediate/advanced in multiple dimensions.

1. General computer knowledge
2. The system
3. The domain/profession

As a vendor you need to investigate and make a decision.

The investigation can be carried out in various ways: Questionnaires, interview, observation, user testing etc etc. In short: Conduct an user analysis. This user analysis usually results in some sort of documentation. Like personas and/or user specification.

Then you need to make a decision. If you want to success as a software vendor, you need to make decisions. Define the criteria for the various experience levels your product require. There are no golden rules that does this job for you. You must do a proper job yourself.

This can be a bit tricky, because it might not always be as it seems. For example, you might have an user who claim to "be online every day". It's easy to draw the conclusion that these users are experienced Internet users - but it can turn out to be someone who's son-in-law just added a solitaire shortcut to the desktop and this is all this user uses. He starts the shortcut and plays solitaire - every day. If you point him to another website, he wont get it.

My experience is that the actual experience level is lower that I've expected. But YMMV!

Answer 2

Help sections inevitably fail. They are usually out of context, they are never comprehensive and they rarely speak the user's language. Most users just muddle through -- they "satisfice" achieving a good-enough result, or they leave.

You'd get more ROI by user-testing your interface and tuning it up based on feedback than you would creating a help section.

Some kinds of help are low cost and actually helpful. For example, tooltips. Do all your icons and cryptic links have tooltips? Add them in; it helps. Also in-context help is a good way to guide users. See attached image from Twitter's Settings/Profile, note the paragraphs in the right margin -- helpful n'est ce pas?

Other kinds of help that don't suck are FAQs and crowdsourced FAQs, where the questions come from real users. If you have a Customer Support group, they could probably give you a top-ten list of user questions real quick. There are also a couple of new services that crowdsource frequently asked questions and up-rank the most popular. User Voice ( http://www.uservoice.com ) and Get Satisfaction (http://getsatisfaction.com/explore/customer-support) are two such solutions.

So, back to your original questions:

1. No, it's not necessary to build a help section, and

2. Most users have learned to ignore help sections because they're usually a big waste of time.

Answer 3

First, no, not all sites require a (monolithic) help section. Look at Stack Exchange, for example, which doesn't have one (not just the UX site, but even sites whose demographic is less likely to be technologically-inclined, like Gardening.SE). In fact, the only place the word help appears where SE is asking us for help.

This is because the interface mechanics require virtually no explanation beyond what the most basic computer user is likely to know. What is required is behaviour shaping, which is achieved by the faq and other interface elements like voting.

There are smaller embedded tips, however, where needed, which seem to follow precisely Jørn's assertion that help is for advanced users: the (?) icon above the editing window for markdown help, but that's just a code reference.

Second, a help section ought to be required for some purposes, such as explaining what goes on behind the scenes that the user may not be aware of. Their interface may be intuitive, but the user may still need to know about the mechanics of what's going on, or what certain configuration options do, etc.

For example, while Facebook's privacy option "Only Me" may seem obvious at first, only I can see it, but perhaps not all users would realize that:

This option allows you to post stuff to your timeline that is visible only to you. Posts with the audience of Only Me will appear in your News Feed but not your friends' News Feeds. If you tag someone in an Only Me post, they will be able to see the post.

This is necessary because things shared with "Only Me" may explicitly be shared with people who are not you.

Answer 4

I'm going to have to disagree with most of the answers here.

Do people really want a feature such as 'help'?

Yes, people really do want a Help feature! Studies have shown that people prefer to use self-service options as opposed to emailing, calling, or chatting with a support person. This is great news, since self-service Help is much cheaper than the other options!

Is it really necessary to provide a help feature regardless of subject/app type?

Generally, yes, you should provide a Help feature. Not only do people prefer to use Help over emailing or chatting with your support team, it's also cheaper.

You seem to have two unasked questions, which I'll go ahead and answer:

How do I make Help more helpful?

There are some great resources available on this subject, but I think it boils down to: don't make the user think. The hardest part of Help is figuring out how the information is organized - it's a hassle to click through a bunch of guides, topics, etc to find the answer to one simple question. If the answer is too hard to find users get irritated and switch to a different support channel (or competitor!). I think the best solution to this problem is context-sensitive Help.

For example, if the user clicks the Help link when on the Login page:

Then she should see different answers then when she clicks the Help link on the settings page:

Context-sensitive Help means the user doesn't have to dig through a bunch of Help topics - the information has already been filtered to the most relevant topics.

What's a fast, easy way to make Help that's helpful?

Fortunately, you don't need to make this feature from scratch. There are tools available that do the heavy lifting for you. Try HelpIQ or HelpJuice.

Answer 5

Documentation contributes to a portion of an applications UX, though one that may frequently go un-experienced. A 'help button' is a usable means of access to your documentation. Whether or not you wish to implement this feature boils down to return on investment. You can spend time writing documentation that is unlikely to be read, and that is likely to be accessed unintentionally (eg. 98% bounce rate after pressing F1 on Firefox).

The other concern is that you have to keep this separate document up to date. These two factors may be why in-situ tips have taken over monolithic help. Furthermore it's often faster to google something than look it up in a monolithic help system.

If what you are writing is an expert tool where users can be expected to read the documentation or an in-house or offline app then help might be worth considering.

Otherwise just remember:

'Help' generally doesn't

Answer 6

My experience with Internet users is if they stuck, they would leave or if they need that website/service, they would use search engines to solve their problem and just a few of them would look for a "help" link in navigation.

So it is better to help them, Where and When they need help.

Identify where your UI is not clear enough for users, and help them right there by using inline help messages or with a little help of javascript, with bubble style popups or any other solutions which make the user solve his problem in less time, when he needs help.

This is far better to collect all help and how-to contents to a garbage which nobody visits there.