User Manuals are Maven Traps

In his afterward to The Tipping Point, Malcolm Gladwell writes about maven traps, "a way of efficiently figuring out who the Mavens are in a particular world." He says that "how to set Maven traps is one of the central problems facing the modern marketplace."

I think user manuals are Maven traps. How often have we heard that no one actually reads user manuals? Compare that sentiment to this from Gladwell:

In the midst of all the product information [on the back of a bar of Ivory soap], there is a line that says: 'Questions? Comments? Call 1-800-395-9960.' Who on earth could ever have a question about Ivory soap? In fact, who on earth would ever have a question about Ivory soap so important that they felt compelled to call the company right away? The answer ... [is] the soap Mavens, and if you are in the soap business you had better treat those soap Mavens well because they are the ones whom all their friends turn to for advice about soap.

The people who read user manuals are the rare software users who want to know everything about how an application works. They read Word's help to find out in complete detail how tables work in Word; then when a colleague calls them over because a table is misbehaving in a Word document, the Word Maven can help. They love to help—at least, according to Gladwell. They love to soak up as much knowledge as possible in an area and then share it with others.

This means a few things for technical writers creating user manuals.

First, and most commonplace, it means that even though most users will never look at the manual, the information in the manual is nonetheless the primary means of dissiminating information about the software to users. It just doesn't happen directly. It happens through the intervention of Mavens, who will read the manual in detail and then pass the relevant info along when a friend or colleague has a question. This isn't a new idea, many others have mentioned something similar before.

Secondly, it means we should reconsider who we're really writing manuals for. Often technical writers bemoan the fact that "no one" reads the manuals, and work to broaden their appeal so that more users turn to them more often. These efforts might include omitting obscure features, making manuals increasingly task-based so users can get out of the manual and back to work more quickly, including more videos or more attractive, brochure-like graphic design. All of which makes the manual less appealing to Mavens. These are people who subscribe to Consumer Reports magazine and write detailed product reviews on Amazon. They want detail. They want to understand. They're our core audience and we should cater to them first and foremost.

Finally, it means we have a new way of justifying the importance of technical writing in an organization. This is the "trap" aspect. In The Tipping Point, Mavens play a crucial role in the spread of social epidemics, including the success of products in the marketplace. One of the challenges organizations are faced with is identifying the Mavens among their customers and getting in touch with those people. Technical writers are doing that every day; we're doing it better than anyone else in the organization. Our user manuals are one of the few things put out by our company that Mavens will gravitate towards and trust. We have a direct line to these people, and the better we treat them, the more likely they will be to recommend our products to their friends. (And as Gladwell points out, when a normal person recommends a product to ten people, maybe 2 or 3 of them listen and try it out. When a Maven does the same, all ten people try it because the Maven is usually right about these things.) That's a powerful reason for a company to invest in technical publications. 

Another unnecessarily confusing interface

I checked in for a flight last week using a self-serve kiosk. When I first approached it said "Touch screen to begin," so I poked the screen. It beeped and displayed a second screen that said something like "Choose an option" and listed five methods for identifying myself—swipe a credit card, swipe my passport, scan a printed boarding pass, and two others I can't remember. Each of the five options was displayed inside a large square box that looked like a button or a three dimensional frame. I wanted to use my passport so I poked the screen inside the passport area. The screen beeped and nothing happened. I assumed it was just slow. I waited but still nothing happened. I poked the screen again. Nothing. I poked it again. Still nothing.

Eventually I decided to try swiping my passport. I opened it up and found a bar code type area and swiped that, but it didn't work. I swiped it a couple more times, varying the speed and direction, but still nothing.

I poked the screen again. Beep, and then nothing.

I studied the picture inside the button more closely and tried to orient my passport the same way as in the picture, and swiped it again. Finally the machine recognized my passport and a new screen was displayed. From there things went smoothly.

But that was needlessly frustrating. Why make the options look like targets if I wasn't supposed to touch them? Why hide the list of options behind a "Touch screen to begin" page, priming me with the idea that I interact with this device by poking the screen, instead of just listing the options on the front screen so I can swipe my passport before interacting with the screen? It was like the interface was designed to lead me astray.

Perhaps the best redesign would be to go with the perceived affordance of touching the option you want to use, and show a second page saying "Swipe your passport in the slot above." Then there would be enough room to show a video of a passport being swiped and a picture calling out the part of the passport that the machine wanted to read, so I wouldn't have had to try to guess from a tiny iconograph how I was supposed to do the swiping.

How do you test what someone doesn't expect to be able to do?

Interpreting the results of a usability test is tricky at the best of times, but in a study I recently conducted I found that it's even more difficult when the feature you're testing is something your users don't expect the software to be able to do. In this type of situation, the interface has to reveal the software's capabilities to the user in addition to making those capabilities easy to use. That's an additional constraint on the design. (Normally the user expects to be able to accomplish something with the software, and the interface's task is to match the user's mental model—their expectation of how the feature should—as well as possible, or to bridge the gap between their mental model and the system's implementation. In this case, the user has no mental model, or their mental model doesn't extend that far.)

So how do you test something the user doesn't expect to be able to do? And how do you interpret the results?

I can't discuss the details of my test but I can use a roughly parallel example. Imagine you were testing the Smart Playlist feature in iTunes (the ability to create a playlist that automatically fills with songs based on criteria you set, like genre, artist, rating, or any combination of attributes). Many iTunes users I know have never heard of this feature. If you were testing it, what would you do?

What we decided to do was give them a scenario that we thought would supply the expectation for them. In the iTunes example, this might be something like: "Create a playlist that automatically includes all of your Rock songs from the 1980s."

Now imagine that all of your test participants immediately tried searching for 1980s Rock songs in their music library and then looked for a way to add these to a playlist. And when you informed them that there was another way to complete the task, they tried creating a playlist and calling it "1980s Rock."

In this case, the scenario seemed to prompt the participants to imagine capabilities the software doesn't have (saving search results as a playlist, filling a playlist based on its name), instead of the one it does have that they didn't expect.

Does that mean the Smart Playlist feature is difficult to use?

I don't think so. It seems like anyone who discovered Smart Playlists would bypass the confusion that was uncovered during the tests, and discovering it in context would do a better job at setting their expectations about it than the scenario did.

In short, it seems like the scenario created the confusion, and thus the difficulties encountered in the task really tell us little to nothing about the usability of the feature we set out to measure.

I'll have to try something different next time.

A glimpse behind the walls at Cooper

This video shows how Cooper uses Adobe Fireworks to do their interface design. It also provides a glimpse into how they divide the design tasks between an interaction designer and a visual designer.



I don't know much about Fireworks, but it looks like it might allow you to prototype interactive designs. One of the things I find most difficult about designing in Visio is that the screens are all static; it's very difficult to document a more complex in-page interaction with a tool like this. It's also difficult to work out the interaction in the first place without a tool that lets you quickly build it and try it.

I also like how they've divided the work involved in designing and developing software into discrete specialties. I think the level of polish and sophistication they're able to obtain as a result is the best answer to 37signals' argument that Web designers should also be web developers.

Is reading changing?

Allegedly people are learning a new way of reading, thanks to the internet, which would better be described as skimming. Tony Karrer defends this change:

Yes, we need opportunities to reflect, but for me that's blogging. I'm reflecting on his article as I write. But, indeed, I skimmed through passages.

I’m skeptical that skimming + blogging is as good as careful reading in the first place. I suppose with blogging there’s no accountability to master the material, so you can get a way with skimming and take away whatever you like from a piece without needing to accurately grasp the author’s arguments or position. Perhaps skimming is good enough, then, for what Mr. Karrer is trying to accomplish.

Bit if reading does change to skimming, should writing change to accommodate? Where does that leave the types of writing that aren’t amenable to skimming, like the development of a complex argument or a narrative?

Experimental Philosophy?

A post over on the Mind Hacks blog discusses the possibility of an "experimental philosophy." What would make this philosophy, they argue, is that that it would seek new empirical data that could weigh in on questions philosophers care about.

That's not philosophy. Academic disciplines are defined by their methodology, not the topics of interest to current practitioners. That's why you can have a philosophy of science and a sociology of science and distinguish between them.

This reminds me of a story one of my philosophy professors once told. He was at a party and got into a conversation with a physicist who, upon learning that his conversation partner was a philosopher, asked with some consternation, "What do you take as you data?" Maybe you have to be a philosopher to find that funny, but that's just my point.

An answer to the Easterlin paradox

In Stumbling on Happiness, Daniel Gilbert writes about a study where:

[R]esearchers telephoned people in different parts of the country and asked them how satisfied they were with their lives. When people who lived in cities that happened to be having nice weather that day imagined their lives, they reported that their lives were relatively happy; but when people who lived in cities that happened to be having bad weather that day imagined their lives, they reported that their lives were relatively unhappy.

This seems like a good answer to the Easterlin paradox. If today's weather has a big influence on my assessment of how satisfied I am with my life overall, then obviously asking people how satisfied they are with their lives is not, in fact, a good measure of how good their lives actually are. So a failure to find a correlation between people's self-reports of their overall life satisfaction with their level of wealth proves nothing. Maybe driving an Audi R8 does make your life happier, you're just not always cognizant of it. Like, for example, when it's raining, and you just got back from walking your daughter-in-law's dog who you're dog-sitting for the weekend, and you get a call from a telephone research person asking how happy you are about your life as a whole, and your hair is still wet and it's dripping on the floor, and you're cold.