FAILURE IS NOT AN OPTION! It comes bundled with every copy of our software.
Most computer "help files" should be called "unhelp files"
If all else fails, stop reading the manual, you'll do much better that way.
Serious (yet, tragically funny) comments:
A user was lamenting that a software manual was so riddled with errors that it was easier to use the software by ignoring the manual. She also explained that whoever wrote the manual didn't think about how the software would be used, just how it was written. I explained to her that unfortunately, this is the normal case for computer manuals. I wish it weren't a joke, but it is true that Manuals typically document:
In the fall of 2002 an Alberta Government software package sent to schools throughout the province came with a document
Note: I have been involved in creating "real" manuals, books and articles for "real" software. I understand that most developers, having spent way too much time and effort on the development just can't be bothered writing good manuals. In my opinion, the number 1 missing feature of most manuals is a "procedures" section. This is a section that stands back and asks:
Once the software gets into alpha and beta test, every question asked by the testers should be considered in light of the above 3 questions to see if it warrants documentation this way.
The number 2 feature missing in most manuals is a USEFUL index. Most software packages will have manuals that only document using the words used by the software developers. For example, in a product that has "Automobile", so the index has an entry for automobile. But it should also have index entries for things like car and vehicle as appropriate to the software. Just because the developer used the word "Automobile" doesn't mean that the user will immediately think of looking up under automobile. Remember: If you don't immediately come up with the words your users will search by - they won't come up with your words when searching the index.
So how do you gather good words for an index? This is easy! I'm glad you asked! You initially provide the manual on line only, with a search engine for finding words. You then record every word searched on, whether the word was found or not, and ask the user to reply whether the search resulted in the expected information (with a comment field for them to explain). Then you study the results, especially the "no hits" and the "well, it found the word, but that wasn't what I was looking for"s.
Also, all error messages should be documented in an alphabetic way (or indexed) and then key it to the procedures section.
2017 Update: Given how pervasive and easy indexing is (you can use google to search a specific site that doesn't even have an official index), I am more and more leaning towards just including the alternate word in the body of the text. So saying 'blah blah Automobile (car/vehicle) blah blah' the first time in a section I use such a term, this allows any indexing system to find it. I also sometimes run things together for exactly the same reason, so the phrase 'The Automobile' has a very specific meaning in your application, I might put (TheAutomobile) in as well, making it easier to search. I don't usually do this for 'consumer' manuals because it is confusing to explain, but for technical users I do.
Computer programming often has cryptic codes that make sense only to the developer. One day I was working through some code where all variables of a type started with "T" followed by a word or phrase. In the code review we came across TReason, upon which one of the reviewers cried out "That's TREASON!"