I'd like to start today's entry by following up on the last one. Alex McKale kindly commented that he'd heard of the point about people commenting on minor details and ignoring large ones as "building a shed". This week, coincidentally, I found this URL in an email message in my inbox which discusses the same idea and seems to mention where this idea of "building a shed" comes from. Good to know.
Today I spent some time looking at the documentation for one of our products. It isn't bad. There's actually a lot of great documentation there. At the same time, this documentation seemed to reflect an old-style engineering approach to documentation. Sit down, document your technology comprehensively from start to end. This is useful at times, and even needed.
Yet, again and again in usability studies, what we see is that most people try to use software based on previous experience, and then turn to documentation only when they run into problems.
This is a difficult situation. On the one hand, some people probably do need to read the documentation thoroughly to understand the system. And it is probably crucial to serve those users since they probably (and I'm speculating here) serve as information resources for large networks of people that don't read docs. At the same time, there's a tendency in most software products to primarily deliver "comprehensive" documentation. Sometimes there's a push to deliver "task-based help". Yet, for the average user this doesn't really help much. Again and again I've seen users in usability studies say, effectively, "Oh, the help/docs is never very helpful, so I never look there."
Documentation (taken broadly) in the end is an important part of the user experience. People do run into problems and need to consult information resources. The problems here is that, ironically, the better your user model is, the easier it is to write docs, yet the less they are probably needed.