In Features sell products (but don't get used), Heidi Adkisson says most people never use the features they pay extra for due to the “paradox of the active user.”
A few years ago I did an extensive in-home study observing use of a particular computer hardware peripheral. Most people had high-end models with many features. But in my observation of use, only one “power user” went beyond using anything but the core, basic features. These people had paid a premimum for features they didn’t use. However, when describing their purchase experience, it was clear they aspired to using these features and sincerely intended to. But, once the product was out of the box, the paradox of the active user took over.
What’s the paradox of the active user? It’s the term for a behavior pattern observed during studies at the IBM User Interface Institute in the 1980s…
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.
Related: The CEO of Philips asks, “Do people need the gizmos we’re selling?” [via GE] He thinks manufacturers should draw inspiration from the clarity of Google and Craigslist.
Spending hours learning to use a new gadget is the last thing most of us want to do. The ability to take a product out of the box and just have it work, without the need to read a manual for hours, is now high on most consumers’ priority lists when deciding on a purchase.
The attitude behind “RTFM” reveals an interesting bias. It assumes there’s one manual…THE manual. But that’s a company perspective, not a customer perspective. Customers have to use dozens of products each day that come with manuals, not just the one product you make. It’s not that they’re lazy bums who don’t want to read the manual. They just don’t want to read all those manuals.
Dan Boland
on 30 Jan 07I wonder if the length of the manual has anything to do with it. When I was a kid, I was the one kid that read the manual before I popped in that new Nintendo game. And as an adult, I generally read the manual, unless it’s way too thick. That’s why I still have trouble doing simple things on my phone — the manual was 100 freakin’ pages! I’m not reading that!
Nathan Rutman
on 30 Jan 07I think it has to do with the broad audience a manual has to be written for. Usually I find manual reading a waste of time because it’s 100 pages were written for someone who doesn’t know how to open an application (“Go to the Start menu, up to Programs…”) and that isn’t me. I love the “Quick Start” stuff that many products these days come with. It’s a overview of the manual that I can look at pictures and glance over, and then if I have questions, I can refer to the manual. That approach gives a wide audience multiple parts of entry into the documentation. Adds bulk, but I find it helpful.
brad
on 30 Jan 07This brings up another thing that software and hardware designers often forget to think about: the context in which their product will be used. Sure, reading a manual might not take long if it’s the only thing you have to do. But if you’ve got thirty programs on your machine and you’re expected to read all those manuals, sorry, it’s not going to happen.
I’ve often felt that software manuals miss the mark: instead of explaining all the features and how to use them, why not focus on the tasks you’re most likely to do and how to accomplish them?
heri
on 30 Jan 07hi, i like this post. There are 2 paths from there: simplify your product (ie focus on less features, à la 37signals) or make it so simple that all power features are avalaible to all users from the first use. that’s what Philips CEO says i guess. I, on the other hand, because i dont have philips’ or apple’s ressources, i am choosing the first path.
beto
on 30 Jan 07Proof that “more” doesn’t really mean MORE when it comes to gadgets. In the end it’s all a psychological, placebo effect (the belief that “more” whatever that is somehow equals to “better”). For most people anyway.
Then again, I have to admit that few things are more disappointing when purchasing a gadget (or game) than spotting a 200-plus page manual. Thankfully many companies are wising up and providing us the ADD generation with fancy, light “quick start” guides to get up and running in no time.
Stephen
on 30 Jan 07I think it’s a sign of the times that we now blame the consumer for failing to optimize his/her peripherals rather than blaming the company for not making easily-understandable products. Modern video games come with 200+ page manuals. New LCD screens come with 50+ pages. My ergonomic keyboard came with a booklet, for crying out loud. My motorcycle, however, came with 50 pages (albeit very small print), split between 4 languages. If I misuse a video game, I might have to load a saved game. If I misuse my motorcycle…
Warren Henning
on 30 Jan 07Well, people don’t want to read crappy writing for one thing, that’s a dimension not being covered.
There’s a vast difference between a good, helpful manual that is optimized to quickly take care of the most common questions and concerns the user/customer may have and a useless one.
I’ve had good experiences with Ikea’s literature, their furniture instruction manuals (they’re more like little booklets). First of all their furniture rarely requires more than a screwdriver or a hammer (and often times just these little Allen wrenches they include with the furniture). Each page is completely covered by a diagram showing one step of the assembly process so you can easily see it from several feet away and also from a sharp angle. And actually if I remember correctly they don’t even have any words, or if they do there’s very few, which lets them focus most of their resources on just producing one good manual that transcends language rather than having to produce n (probably lousy) translations for each of the n countries they do business in.
Alejandro Moreno
on 30 Jan 07I must be an alien. I read manuals. Period.
Somehow I’m still well aware of the fact that my apps should, under no circumstances, need a manual. So I guess I’m okay.
Walker Hamilton
on 30 Jan 07Jeff Veen made a comment similar to brad’s when he was ranting about CMSes and their manuals.
Cody Foss
on 30 Jan 07To paraphrase Robert Hoeckman Jr., if your product requires people to read the manual before they can use it, you’ve already lost the battle.
Derek Vaz
on 30 Jan 07The “paradox” makes sense. How many of you read the instructions before transforming your Transformers? Instruction manuals are only really used for troubleshooting and building (think IKEA).
And, after all, great products aren’t necessarily immediately intuitive. An “active” user should be able to figure out a well designed product (think about the first time you pressed “Menu” to go back on the iPod’s interface) pretty quickly even though it wasn’t obvious .
I think that was the beauty of Transformers, really.
Kathy Sierra
on 30 Jan 07Yes, what Brad said: “instead of explaining all the features and how to use them, why not focus on the tasks you’re most likely to do and how to accomplish them?”
Cody: I don’t agree with this quote: “if your product requires people to read the manual before they can use it, you’ve already lost the battle.” Or at least not without plenty of qualification. There are plenty of things with enough necessary complexity that just DO need manuals, and trying to eliminate the need for a manual might end up stripping out capabilities that just have to be there. That doesn’t mean there shouldn’t be a goal of having the experience be as brain-friendly and intuitive as possible.
But some things simply must be learned, and it’s our job as providers to help our users learn in the fastest, most efficient, least painful way. We’ve trained users to not want to read the manual because they nearly always associate the manual with PAIN (dull, often incomprehensible, not useful or relevant, takes too long to get what they need, etc.)
If we want users to RTFM, we need to make a better FM. (which might not even be in print, depending on the product… it could be an online help system of some form)
If the manuals were as engaging and seductive as the material we make when we’re trying to convince someone to BUY something, they might be a lot more likely to at least crack it open. My theory has always been that we ought to divert marketing funds (and potentially some of the marketing or advertising ‘talent’) and put it into user learning materials.
Excellent topic and discussion!
Charles
on 30 Jan 07It is so true. Let me tell you about my own experience about this.
I am 61 and quite a newbie in computer stuff, especially technical properties. Moreover I am French, which doesn’t help much about rationality.
For my new job, I had to buy a computer. Laptop. I went to the nearest computer shop to listen during half an hour to the salesman. I undestood less than 10% of the words he said. In the end, I took what seemed to me, the best product with so many functionnalities that it would take a week to list. Why ? Because I was sure I could do anything with it.
I was very proud of my acquisition.
When it was time to use it for real, I just turn it on. And watch the screen for about 20 minutes. Not knowing what to do with it.
It was a month ago. No I know how to go to internet and read blogs, post comments and so on. But definitly I don’t need all the softwares, options, cards… that my computer have. I just need a browser.
I went back to the shop, telling them I want to change my marvelous and expensive laptop with something designed to go on the web and only that.
I let you imagine how much they laugh at me.
Dan Sage
on 30 Jan 07Maybe this is why Apple is doing so well. The iPod turns on and plays music. There really isn’t all that much to it. The printer connects and prints. The camera connects and downloads pictures. Some people are fed up with the hours spent trying to setup or troubleshoot. Simple works.
brad
on 30 Jan 07I think most of us learn software the way I learned to fix cars: when something broke, I learned how to fix it. Similarly, when we need to accomplish a specific task with software, we learn how to do it. That means there are big gaping holes in our knowledge about what the software we own can do, but is that such a bad thing? We don’t need to know everything a program is capable of doing, but rather how it can help us do what we want to do.
I think the best approach to training users would be to start by giving them a brief and focused overview that includes real-world examples of how the software can help them accomplish things they may need to do at some point. Sort of a more in-depth version of the product tour that you might have looked at when you were deciding whether to buy the software. That gives users a clear sense of the possibilities; they can learn the detailed how-to later as they need it.
The folks at Juice Analytics just posted a rudimentary but useful Excel training worksheet that got me all excited about Excel because I had no idea it could even perform some of these functions. That’s what I mean about revealing the possibilities. I actually think this sort of training is especially useful after you’ve already lived with a program for a few years…it shows you more efficient ways to do things you’re already doing, plus it opens your eyes to things you didn’t even know the program could do.
One of the reasons Steve Jobs’s presentation on the iPhone was so effective was that he showed people how easy it was to find a local Starbucks, dial its number by touching a link, and ordering 700 lattes to go. Apart from the number of lattes, that’s something pretty much anyone could see themselves doing. And this is another thing that I think is missing from most software manuals and training: watching (or following step-by-step) an experienced user perform a task. The videos on lynda.com do this pretty well, but sometimes the user is too experienced and moves too quickly, and the student feels overwhelmed. You need trainers who can put themselves back into the “beginner’s mind,” remembering what it felt like to be a neophyte.
Nate
on 30 Jan 07There is something kind of surprising here though that isn’t really being talked about. “Most people had high-end models with many features”.
Do most people still tend toward thinking that “more stuff” means better value when it comes to software, even when simplicity is what they love after purchasing it? Are they thinking “More for my money”?
The user bought the products because they thought it had all these features, which in many people’s minds proves that it’s more sophisticated or a better value overall. But they don’t really want the “sophistication” (read: hassle/complication) when they are actually using the thing.
We have begun to see that recently with our product at inklingmarkets.com. Some prospective customers are comparing the length of the feature lists or even our API documentation to help sort out whether our competitor or inkling is a better value/purchase. But once they make a purchase of our product, the length of documentation or endless complication of features isn’t missed, and we get the “I love how simple it is.”
So is the answer to follow “Getting Real” and keep things simple, but pay attention to when you need to market your product as everything and the kitchen sink?
Does anyone at 37signals see sales being lost because a potential customer wants Basecamp to be a complicated mess of features (e.g. FogBugz), even though when they finally commit to using and paying for the thing, they love the lack of them?
JF
on 30 Jan 07Does anyone at 37signals see sales being lost because a potential customer wants Basecamp to be a complicated mess of features (e.g. FogBugz), even though when they finally commit to using and paying for the thing, they love the lack of them?
I’m sure there are. Sometimes we get emails with a list of 20 questions about how our product compares to some competitors. Our answer is usually:
“We don’t believe feature lists are an accurate way to compare products. Two products can say ‘to-do lists’ but what does that really mean?
If this is an important piece of software for your business we highly recommend trying out a few different products and seeing which one(s) feel right. That’s really the only way you’ll ever know which product fits your needs best. Feature lists can be deceiving, but your experience is real.
We’d love to have you as a customer, but we understand that our mix of features and experience isn’t right for everyone.
Thanks for considering us and we hope to have you as a customer.”
In the end we just want people to use what’s best for them. If they think they need a ton more stuff then we offer, then they should use another product. If they try ours and like it then hopefully they’ll stick with us. But it’s more important that they use what makes them happy than use our product and be disappointed.
Tom Greenhaw
on 31 Jan 07I think it’s interesting that in this discussion that there is no mention of online help documentation that is:
A) well organized B) linked in context C) searchable
I resort to manuals when I can’t figure out how to do it through immediate exploration and discovery. I will however look at a brief introductory demo and also glance at a well made one page “quick start” guide.
Leith
on 31 Jan 07I know I happen to be a manual-reader, particularly on something new and big and bright. But when it comes to software or web sites, my mantra has always been that the interface has to be such that a manual is not needed. A user should intuitively know what they can do and how to do it, without explicitly reading a manual or help page.
The method I have seen for doing this cleverly is when sites detect your recency and frequency of visits, and provide suggestions on what you can do in a clear and simple way. For instance, newbies to a site are told “Now you can do ….” or “Want help in doing ….”, and more experienced users are offered suggestions of higher end functionality.
Other useful tricks are the effective use of tooltips, quality contextual help automatically appearing on the screen as you do new tasks, and thoughtfully worded links and menus. These elemens usually go a long way to invite a user to experiment confidently with new functionality on a site.
That being said, I am a big believer in the importance of quality manuals. Its so obvious when reading manuals, particularly of stereo equipment (why is that!?) that the manual has been an afterthought delegated to the least involved and least eloquent people in the organisation. Alas.
Estigy
on 31 Jan 07Oh, nothing could be more true than this post.
Some weeks ago I bought a new keyboard, spending some more money because it has a whole bunch of great little extra buttons (for launching the browser, writing an email, playing music, you know what I mean).
Now have a guess: Which buttons do I not use right now…? Exactly.
Luca Mearelli
on 31 Jan 07I absolutely agree with Kathy here, in that there are tasks that are inherently complex, and that even ifsoftware can be built to be as simple as possible there will be a need to educate the user.
What is lacking sometimes (most of the times?) is a good “help” design. I mean that “helping the users” should be integral to the design of your application and be treated as a first-class element as much as the rest.
For me a good help (or manual, or …) should have these:
1. be helpful (tell me how to do something, not the why of a feature, and don’t give me too options),
2. be contextual (help me on what I’m doing now),
3. educate (let me know me that i can do more, but don’t shout at me that I’m a newbie),
4. be self revealing (complex features of the system should not get into the way of the simplest uses, which I’ll need most of the time, but they should appear evident to the advanced users)
Igor Asselbergs
on 31 Jan 07We have some interesting experience in this field: We try to make our software as easy to use as possible. So as to allow a user to get from A to B with as little clicks and as little fuzz as possible. As far as we’re concerned a manual is for reference only. A user should only need to pick it up to find out some details. Other than that we provide our software with some sort of Quickguide to help a user on its way. When developing a photo imaging application we actually tested the usability. It appeared that users who received an personal explanation of the sofware were on their way in 10 minutes. Users who received no explanation, but followed the quickguide were on their way in 30 minutes. And users whith no explanation and who didn’t bother to look at the quickguide (most people, when given the choice), were on their way in one hour. No matter whether or not these users were experienced computer operators. I’d say that’s a pretty good result for a rather complex application. And the manual played no role whatsoever.
Bogie
on 31 Jan 07There is a lot of discussion of manuals on this page, but very little on contextual help and screencast videos. They can, in most instances, replace or negate the need for a traditional paper (or electronic) manual.
Pop-up tool-tips on form fields can be a great help (see the registration form on VOX.com), as can walk-throughs (see Mint website).
brad
on 31 Jan 07There is a lot of discussion of manuals on this page, but very little on contextual help and screencast videos.
Probably because they’re not as widely used. I’ve had such bad luck with contextual help that I never think of using it; a shame, because some programs probably have good contextual help. The problem with screencast videos is that you have to remember the procedures that you watched, whereas with a printed manual you can always go back to the page and refer to it as you perform your task. I don’t like online help either for similar reasons…I often end up printing out the online help page if the instructions involve more than two or three steps, and then I can refer to the printed sheet.
ML
on 31 Jan 07Related quote from this article about the Wii: “Her husband did some research about which console to buy. She said he liked the idea of getting started without spending a lot of time reading a manual — and, more fundamentally, being a bit active while they played.”
Bryan C
on 31 Jan 07I have to admit that I don’t usually read manuals unless I have a problem. Decent online help and lots of tooltips go a long way toward making a new application easy to understand.
One thing that really bugs me is the lack of consideration for users who’ve upgraded from a previous version of the same product. Most companies can barely be bothered to write a pitiful little text file or single help screen. I want a nice, simple list of everything that’s been changed or added since the previous release, each with a brief explanation of the changes (screen captures are welcome) and links/page references to additional information. Is that too much to ask?
I think the “core features” thing is largely a red herring. Features don’t have to be used every day in order to be valuable, and customers aren’t extravagant wastrels for wanting to have a feature available just in case they need/want it. The marginal cost between the low-featured product and the high-featured product is usually not worth worrying about. Not when compared to the additional effort required to get that functionality when I really do need it.
Besides, many customers today have a sneaking suspicion (often correct) that the lower-featured products are deliberately crippled versions of the “real thing” that could just as easily be much better than they are. Sometimes there are good reasons to market products this way. But it still makes people uncomfortable.
Alex Bunardzic
on 31 Jan 07Heidi Adkisson, quoted at the beginning of your post, had inadvertently opened up a new door in the discipline of software product design.
If indeed it turns out that barely anyone ever uses anything other than the bare-bones features of a high-tech product, while at the same time clamoring for as many bells and whistles as possible, then it would be incredibly easy to give vaporware another lease on life.
In other words, we could advertise/hype up myriad of incredibly elaborate, sexy features, fabricate all kinds of vaporware literature/screencasts etc., while at the same time quietly working on building our regular product. Then, when we launch, everyone will flock to buy it; however, they’ll never get to notice that all the ‘sizzle’ that sold the product is not actually there!
It’s like that guy from a couple of comments ago who bought the more expensive keyboard for the ‘launch more browsers’ extra little buttons etc. and never actually bothered to give them a try. Hey, maybe those buttons are actually fake, who knows?
Perfect. Sounds like best of both worlds. I’ll do some more research, and hey, maybe we’re on to something. It’s snake oil all over again!
Murali
on 06 Feb 07If every new product comes up with an interface that a user need no introduction to get started, we shouldn’t be having any ‘new’ products to speak.
I love quick starts and manuals that are clearly targetting various levels of users. One manual for all freaks me out. Demos are the best manuals to get started.
This discussion is closed.