Many people have observed that users will spend many hours flailing helplessly rather than read perfectly good documentation (ReadTheFineManual). I would take this one step further. Users can't read.

The basic idea behind this principle is that you need to design your programs so that as close as possible to ''no'' reading is necessary in order to get good results. Features that are hard to describe are probably hard to use. 

Note: it is important to avoid the trap of ItsIntuitivelyObvious. Simply reducing the amount of documentation in response to the fact that UsersCantRead will not result in a more usable program.
----
The problem with most documentation is that it tells you 100 things you don't want to know or already know before you find what you do want to know. Reading documentation is often a sequential search. I once pulled my hair out looking for something about "delays", which ended up indexed under "timing". I didn't think to look it up under that particular word.

Further, most people are social in nature, and want to ask a person or person-like thing and get a person-like answer back. Anything else they are uncomfortable with.
----
JoelSpolsky has a great book chapter on this issue available at http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
----
Sadly, this entire page is a rant aimed at the wrong problem; it's not that users can't read, it's that OEMs write awful user documents. When was the last time you took a look at a man page? Now multiply that by two orders of magnitude and make a complex system manual out of it. There you go.

And you wonder why users don't read this tripe? Sheesh.
----
See: VideoDocumentation, UsersAreSmarterThanProgrammers

CategoryDocumentation, CategoryRant