…or the manual, or the ReadMe file.
That is, for the most part, because we train them not to. People will take the path of perceived least resistance. Note that I didn’t say “least resistance.” The perceived part is very important.
It seems much easier to shout a question over the cubicle wall to a coworker than to push F1 and sort through hundreds of screens of information apparently unrelated to what you need to know. And if your coworker is knowledgeable, and the help file is badly indexed, it may be easier! If they try F1 through many programs and always have problems finding what they need, then they are much more likely to shout that question over the wall than try again. We’ve effectively trained them out of reading the manual/help files/tutorials.
There are ways to mitigate this and get your customers to use the help techniques you provide. First, make the help file actually helpful – the writer needs to know what the users really need, and how they go about looking for it!
- If you have writers on staff, let them talk to your customers.
- If you hire a writer, do the same thing.
- If your programmers will also be writing the help file, make sure they understand that users think differently than they do. This does not mean that the end user is stupid, just that she has different priorities. For example, if I want to make a word bold face, I don’t really care about, or need to know, how efficient the algorithm used to do that is, or what steps the computer goes through to do it. I just want to be told:
Select the words you want in bold face and press CTRL – b.
Knowing what your users want and need from documentation is the first step to producing documentation they will actually use.