User Paradox with Not Reading User Manuals

by Tom Johnson on Jan 30, 2007
categories: technical-writing

37 Signals quotes research by IBM describing the "paradox of the active user":

Users never read manuals but start using the software immediately. They are motivated to get started and to get their immediate task done: they don't care about the system as such and don't want to spend time up front on getting established, set up, or going through learning packages. The “paradox of the active user” is a paradox because users would save time in the long term by taking some initial time to optimize the system and learn more about it. But that's not how people behave in the real world, so we cannot allow engineers to build products for an idealized rational user when real humans are irrational: we must design for the way users actually behave.

In other words, users would save time by reading the manual, but instead they try to figure the application out themselves and then get lost/frustrated as they end up spending even more time getting up to speed with the application.

First, I have to disagree with this paradox a bit. Who says that it's faster to read the manual? A lot of times you really can just figure something out faster than reading a manual.

Second, manuals are not meant to be required reading prior to using a product. Manuals are for help when you can't figure out how to do something on your own.

A lot of commenters complained about the size of manuals, saying they wish products were simpler and manuals shorter. Just explain the most common tasks, most seem to say. We don't need all those fancy features — just the basics.

This points to a separate beginners guide and advanced users guide. But I think users don't often know what they want. When they need help for something, it may be a complicated task that is not often used. Shouldn't it be explained in the manual somewhere? A keyword search should quickly pull up the topic.

If what they're looking for isn't in the manual, they say the manual is useless. But including it in the manual may enlarge the manual such that the user looks at the 200 pages and says its useless as well! So this is a bit of a paradox too.

The additional/advanced features should be documented, but when we write help, the additional features can be tucked away in a more advanced user guide. Single-sourcing documentation can allow you to easily produce different guides without killing yourself with extra work.

Am I wrong here? How do you manage a help project that has tons of advanced features that you have to somehow document, but don't want present in a way that would intimidate/overwhelm users?