Is anyone reading the help?

[dwag]

For the sake of argument, if our help content generally provides the help our customers need, how do we get them to start using it more, for crying out loud?

[LTinker68]

Is the help on a public website or internal to your customers? If it's on a public website, then make sure you list your site with the main search engines so it'll come in the results when they Google.

Either way, if a customer contacts Support asking how to do something, you can respond with something like "As explained in the help (hyperlink), follow the steps below to blah, blah, blah". If they ask for help often enough and you keep informing them the answer is in the help, they might start to get in the habit of looking in the help first.

This means you also have to educate your tech support staff about the help, and include references to the help in knowledgebase articles, so support see those references when they look in the KB, because support might very well not read the help, or might only read it when they first start with the company but not read updates.

[dwag]

Thanks for the response. The help isn't on a public website--yet; it's shipped with our software to customers, so internal to customers. Your suggestions make great sense, and through the years, in one way or another, they've been tried. But in the end, it seems to me, no one really cares to read for help. Reading is hard, especially in this era. Words are daunting, depressing. Give me pictures. Give me cartoons. Give me YouTube.

Get me the number to the call center.

What good is written help? For every 1,000 words of help written, how many are ever read?

Today, a picture's worth 1,000 words. But 1,000 words are worth one lousy picture.

[RamonS]

Help needs to be both informative and entertaining. You need to make users want to use the help, even if it is because you show pretty screen videos. After mulling about it for a very long time I came to the conclusion that a good help system follows the DITA principle or at least has two separate sections: one that described in detail every UI component and one that provides step by step instructions that are clear and work (have QA test those!!). Ideally, also add full documentation for any error or warning messages with suggestions on how to fix that issue...although that part should really be inside the error or warning message. Further, use help that relates to a sample setup so that it is really easy to follow steps 1:1. Lastly, dial down the styling and prettifying to a minimum, two or three heading styles and a few styles to make it clear what type of UI component you reference. Ditch the watermarks and the cutesy warning / info / suggestion / proposal /whatever else notes in boxes with animated graphics that add zero informational value. Rather use bold font in red color to draw attention if it really is necessary.
What I want from a help system is tell me what I need to do and tell me what to do differently when stuff doesn't work. I rather get that from a bland looking help than something that is styled to the nth degree with artwork dialed up to 11, but no substance. As mentioned before, screen videos with slight annotations are very helpful, because those typically show what to do much quicker than 27 steps filled with jargon.

And to really be on the safe side, have QA test your documentation (after all, it is part of the application and the same as source code, just that the 'programming' language used is English) PLUS have your alpha / beta testers test the help as well. They represent the people who will use the help in the end. If they come up with complaints then drop everything and fix that first. That is why it is incredibly important to have the docs ready for beta test (right, MadCap?).

Those are my 2 cents...well, maybe 3.

[nickatwork]

It is probably one of the hardest things and most defeating as well. Coming to the realisation that a lot of the content you/I/we (?) write, especially as a help system gets larger and larger probably goes unread, or is at least hardly read compared to how much effort is put in to writing it.

I think about how often I read help, or instructions. Almost never, I can't be bothered. And if I can't be bothered then why would users of our system want to - instant information is only a phone call away - and in my particular industry time is money, no one has the time or desire to spend more than a minute reading help.

So, make your help more consumable. Smaller, bite sized chunks. Don't offer a big help system if you can avoid it - it is too daunting for most people. Well placed contextual help is so much better - but I know it is not always possible. We don't have contextual help, just can't. Too much cost, too much dev time. So I'm stuck with producing a large online help system but offering short printable 'cheat sheets' or quick guides. It is a huge improvement on thousands of pages of PDF documents but it is by no means perfect.

The best way now is to inform our users it is there - make sure it gives them the information they need. Makes sure the TOC is easy to navigate and understand. Always provide information when the help is updated and what we have changed. Advertise it. Make sure the support teams know what is happeneing with it and get them to always inform users about trying it and to offer feedback of improvements.

[mlezak]

Nick --

It is frustrating. But the way I see it, I consider Product Support to be one of my main customers (and they know I feel that way).

If they can answer a call by pointing to a location in the Help, everyone is happy.

Does that help?

[i-tietz]

If it's on a public website, then make sure you list your site with the main search engines so it'll come in the results when they Google.

???? pardon me ???
What about CSH? Why the heck do you let your users google for your help? You must be joking.
If your users don't find the help you will simply have to get it closer to them ... with ? buttons beside controls for example or with a tool window for help text or help links.

But there will always be users who prefer to ask somebody who they think knows to opening the help.
For the very simple reason that it's usually faster - at least that's their experience. If they have to go looking for the bit of help they need and it takes more than 30 seconds, then they will learn from that, that asking some expert is faster. What do YOU do, if you don't know how something is working in a software you use? Don't you go and ask somebody who knows, too (just in case you have sb who might know better than you)?
A business partner had an intriguing idea: If the caller asks something which is in the help, he pays extra ... don't know about the success, especially because I know their help ... it's far from good, more of an alibi ...

[i-tietz]

This means you also have to educate your tech support staff about the help, and include references to the help in knowledgebase articles, so support see those references when they look in the KB, because support might very well not read the help, or might only read it when they first start with the company but not read updates.

Might turn out difficult, since they profit from bad or unknown help: If users find what they're looking for in the help, they won't need the phone support. In the long run that's less profit for phone support department ... it's a shame, but some see it that way.

[RamonS]

If it's on a public website, then make sure you list your site with the main search engines so it'll come in the results when they Google.

???? pardon me ???
What about CSH? Why the heck do you let your users google for your help? You must be joking.
If your users don't find the help you will simply have to get it closer to them ... with ? buttons beside controls for example or with a tool window for help text or help links.

Sadly, it is not a joke. I read several articles where users go straight to Google to find help and support, even if it is for a locally installed application. Yes, it is dumb and it is sad. TWs can do a lot of things, but they cannot fix stupid. So better adjust to how users use resources and look into SEO.

[i-tietz]

Maybe it's accepted fact to produce help just like Adobe's ...

For help for an Adobe product I go into the internet straight away, too. Because I tried ever so often (to no avail) to find help in the help, which has never been CSH before, and still isn't. I usually go straight to the Adobe forums or to Adobe support ...

Then again: Maybe telephone support is a growing profit center, whereas you don't get extra money for supplying a good help ...

At least this is what I think when e.g. I open a window with 6 tabs and a total of about 70 input fields/lists/buttons and open the CSH for it, only to find a very short topic and a link like "Enter data". I follow that link and it says "Enter the data" in a different phrase ...
But support people in the forums can tell me about single input fields ... seems to be "in" ... we're being made redundant ... literally ...

[RamonS]

I'm not disagreeing, but all you can do is make your help better and easy to search (assuming it is served publicly). I like field level help, both using and writing it. I always found that it preps me much better for my other tasks that always included some form of customer support. After all, when you can describe an application you should be the best to explain how to use it.

[LTinker68]

If it's on a public website, then make sure you list your site with the main search engines so it'll come in the results when they Google.

???? pardon me ???
What about CSH? Why the heck do you let your users google for your help? You must be joking.
If your users don't find the help you will simply have to get it closer to them ... with ? buttons beside controls for example or with a tool window for help text or help links.

Two reasons. First, say you inherited the help from someone and they hadn't done a very good job. So bad in fact that your users ignore your help. How do you get them back? Send an email telling them about the all-new help? Great, if they read the email. But if they've gotten in the habit of Googling to find the info on message boards, for example, and your help now starts coming up, then they'll start using your help. Won't necessarily break them the habit of Googling first, but at least they are going to the help. Case in point -- I don't use Microsoft's built-in help anymore. It never has the answers to what I need, so I no longer try to use their help, and some answers probably are there, but why go to the help when it's been so disappointing in the past.

Second, it doesn't matter how users find your help, just that they find it and, more importantly, find the answers they're looking for in the help. Who cares if they access the help from your application, from Google, from a friend's email, from a message board? As long as they get to the help somehow, then that's what you want. As someone else noted, users today are used to Googling for everything. Ignoring that fact is just burying your head in the sand. Might as well make Google and other search engines work for you by directing them to your help instead of someone else's message boards.

[i-tietz]

Two reasons. First, say you inherited the help from someone and they hadn't done a very good job. So bad in fact that your users ignore your help. How do you get them back? Send an email telling them about the all-new help? Great, if they read the email.

- You could get them via the application: Make the help redesign prominent, e.g. by a screenshot of the new help popping up at opening the application for the first time after an update/upgrade/patch.
- You could also have the GUI of the software redesigned and insert some eye catchers pointing at the "also new help", e.g. "?" buttons beside controls that you have a help topic for, e.g. text in an info box hinting at the F1 key ...
- Embedded help is another point for the user to notice ...
- The software producer could produce a print magazine talking about the redesign - that's more difficult to ignore than an email.

Who cares if they access the help from your application, from Google, from a friend's email, from a message board? As long as they get to the help somehow, then that's what you want. As someone else noted, users today are used to Googling for everything. Ignoring that fact is just burying your head in the sand. Might as well make Google and other search engines work for you by directing them to your help instead of someone else's message boards.

The user does: The longer he has to search for the right answer, the more frustrated he becomes. That can end up fatal, even if he's not telling you ...

AND:
If the data on the computers of the users have to be protected for whatever reason, the user might not have access to the internet. Then the approach "the help is on the internet" simply implodes. Means: You will have to know and use different methods anyway, so why not use them for the better of all people involved?
It's our job to
1. get the information to the user and to
2. do that as fast as possible.
That might not be easy or cheap, but that's why tech doc is something that you can study at universities ... just like marketing - they have the same problems ...

So I recommend a little bit of creativity ...
... for the sake of the user who gets the right answers quicker and
... for the sake of the software producing company: As you said, sending the user into the internet search makes him find all sorts of things, sometimes even a competitor that "does everything better" (or at least he says he does) or he'll find some help which isn't correct (any more). Both impossible for you to prevent and very frustrating for the user ... pretty dangerous.

[DocuWil]

Well, let me add also something.
We have years of experience now.
What my company does is more or less educating the customers.
Some customers often come with questions to us and when it is in the documentation, we don't give the answer. We just tell them in which topic of the WebHelp or what page in the PDF it can be found.
If it is not in the documentation, we are sometimes educated. Because then we have to consider to put it in.
The nice thing is that I get sometimes a remark from a customer, because he or she did not understand something written quite well. That's in my opinion the most positive thing. It motivates to improve the documentation!

[RamonS]

You do give the answer if it is in the documentation by providing where to find it. Technicalities aside, make sure that whatever else you add is relevant for most users. Although I currently do not work on help files I do write technical bulletins that cover all these special cases that come up once a year or so. It helps one or two customers out of a thousand. Passing on that info to just those is IMHO better than cluttering the help with it, having it show up in search results, and potentially frustrate the gros of the user.

[MarinaMichaels]

Maybe it's accepted fact to produce help just like Adobe's ...

For help for an Adobe product I go into the internet straight away, too. Because I tried ever so often (to no avail) to find help in the help, which has never been CSH before, and still isn't. I usually go straight to the Adobe forums or to Adobe support ...
...

I agree. When I am using either an Adobe or a Microsoft Office product', I have so rarely found the information I needed that I now go straight to the Internet for help.

All the suggestions given for making your help more useful are great. I especially agree with Ramon's suggestions (keep your help clean, clear, and simple). (Though I do have a note/tip/important box, which is neither cutesy nor animated.)

[kwag_myers]

Nick --

It is frustrating. But the way I see it, I consider Product Support to be one of my main customers (and they know I feel that way).

If they can answer a call by pointing to a location in the Help, everyone is happy.

Does that help?

I stumbled into Tech Writing when I was a Marketing Manager. I've found that my marketing experience has been advantageous in developing content that meets the needs of my users. The biggest asset to this is user input. In marketing, we had focus groups. In software development we have QA and Tech Support, and for in-house applications, we often have direct contact with the users. I was reading Flare's Help about the Feedback possibilities and I think that would be very helpful when users are the general public.

Also, I read an article recently about the coming trends in technology and one thing that stuck out to me is the prediction of users Googling instead of calling for tech support. That's good news for those of us who write the stuff. Maybe we'll get back to the days of Silicon Valley when Sr. Tech Writers could make six figures. Hang in there, dude. Our day may be coming.

[dwag]

Remember Gus the fireman in "Leave it to Beaver"? His existence was justified by the blue-moon fire and visits from the Beav. That's kind of how I view the justification of help's existence: It's gotta be there, but if you're writing it, leave your pride at the door.

[RamonS]

Also, I read an article recently about the coming trends in technology and one thing that stuck out to me is the prediction of users Googling instead of calling for tech support.

Makes sense, Google searches 24x7 for free, calling support requires a support contact. Also, people like me love online resources, because I don't like calling someone on the phone.