I’ve stated before that my goal with applications I create is to provide an application so intuitive that if one knows the job for which the application was designed that the interface be so intuitive that no training would be required. This is a lofty goal for sure — and not one easily achieved. It might be better to set the goal to be more like 95% of the time “…the interface be so intuitive that no training would be required…”, or 98% or something like that. My first answer to “Why User Documentation?” would have to be that it is what covers the shortfall percentage of design that just doesn’t measure up to the lofty goal.
Secondly I believe that most applications will have those activities which are only seldom performed, or performed only as a “fix” to something gone wrong. The infrequently performed operations which just don’t fit into the everyday flow of the business function, and therefore also not of the business application should be documented for users. Of course, any documentation available will be only as good as its availability.
Ready availability of documentation for an application, or more explicitly documentation specific to a particular operation is crucial. As long as I’ve been around applications this has always been an issue. First off, creating good user documentation (read this as usable user documentation), is not an easy task. It can also be a costly task. Ineffective and it won’t get used, unavailable and it won’t get used, confusing and hard to find answers and it won’t get used!
More often than not what I’ve seen is an attitude of “Why document – nobody ever looks at it anyway”, or, “Document the obvious, don’t worry about the details – let them (users) ask!”. Personally I think application users deserve more respect than that.