User Paradox with Not Reading User Manuals

January 30th, 2007 | Posted in blog 2 Comments »

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?

Archives

I’d Rather Be Writing » Is technical writing boring? says:

February 13, 2007 at 9:53 pm

[...] the content of what I write at work is not all that interesting, and even the paradoxes or other conundrums about technical writing sometimes dull, I really get excited about the [...]

John Woolington says:

May 11, 2009 at 9:01 am

My experience is most software has gotten so bloated and complex that there is no easy solution. Although I’m not a software engineer/programmer, I would venture to say that programmers are at the mercy of product managers who insist on adding hundreds of features that are only used by 1% of users just so they can be listed in competitor comparison tables. They are also never given enough time to make the software really intuitive and easy to figure out without referring to the manual.

In business we have no choice but to stay current with the latest version of Word or Illustrator and buy whole books for exorbitant prices to become proficient. My opinion of Office 2007 is it’s a disaster. As a user of office from the time it first came out, I expected to be able to transition into the new version smoothly. Not so. It took me six months to get the frustration factor down to manageable levels.

I agree that manuals should generally not be required reading prior to using a product and that splitting up the content into a quick start guide and a reference manual will get people to read at least the basics and an electronic version with links and cross references is the way to go for a complex product.

Sadly, very few product developers spend enough time to test the product, refine it, find out the frustration points, redesign it if necessary, and finally present an elegant intuitive product that people can use without going to a class.

I'd Rather Be Writing