Search results

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?

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.