Why Won't We Read the Manual?
May 26, 2002 5:29 AM Subscribe
Why Won't We Read the Manual? I'd say we are a pretty tech-savvy group here. Do you STOP to peruse the instructions before you touch the "on" button of your new "must have" tech toy (to say nothing of your new microwave)?
Probably not. But there are reasons, according to this Washington Post article. I, for one, have been burned royally by manual writers. Scratching my head, I often hear myself mumbling "What the hell are they talking about?" And, in fact, don't you just hate when they are actually wrong?!
Having been a manual writer, I always try to put myself in the place of someone who comes into the situation completely cold. I'm afraid that's not always the case.
I wrote a manual for an interactive TV device that mercifully went out of business days before it hit the market in 1995. In the process, I found out one of the reasons why these manuals can be so dreadful.
After I wrote the booklet on how to install and operate the device, the company's chief technical officer held a meeting with her department, didn't invite me, and rewrote the manual to make it appear the device was easier to operate than it actually was.
posted by rcade at 6:46 AM on May 26, 2002
After I wrote the booklet on how to install and operate the device, the company's chief technical officer held a meeting with her department, didn't invite me, and rewrote the manual to make it appear the device was easier to operate than it actually was.
posted by rcade at 6:46 AM on May 26, 2002
Many products now don't even come with manuals. For example, I recently bought an HP printer that has no paper manuals, all of the info is installed on my hard drive in various help files and user guides. I find it pretty annoying.
posted by rks404 at 7:10 AM on May 26, 2002
posted by rks404 at 7:10 AM on May 26, 2002
As a tech writer, one neat thing I experienced working for a software company were post-publication changes to the product. We'd finish the on-line help and the printed doc for the product as it stood at code freeze (really, code slush) then the developers (really, at the behest of product management) would implement changes without alerting the doc team.
I think a lot of companies don't value technical writers, or good writing in their manuals. They look at it as an "extra" and don't put a lot of time or talent into creating good, comprehensive, understandable documentation.
posted by jennyb at 7:12 AM on May 26, 2002
I think a lot of companies don't value technical writers, or good writing in their manuals. They look at it as an "extra" and don't put a lot of time or talent into creating good, comprehensive, understandable documentation.
posted by jennyb at 7:12 AM on May 26, 2002
As a tech writer, I should have said "one neat thing I experienced working for a software company was post-publication changes to the product." Can I blame this on pre-coffee posting?
posted by jennyb at 7:15 AM on May 26, 2002
posted by jennyb at 7:15 AM on May 26, 2002
I once wrote a manual for a computer game on genetics. Not knowing genetics much I thought I was a good one to write the instructions. It did go to market but I did feel compelled to tell the doctor who developed this game that it would probably be far above the average person. He didn't think so.
Last summer as I was trying to put together my new lawnmower, I was beginning to feel like a real dunce. Part A would not fit on Part B as the instructions so "clearly" stated. Come to find out, Part A was not supposed to fit on Part B. And I was missing the correct part to boot. When I called the store I purchased the thing from the guy said "oh yeah, that happens all the time." Doh!
posted by Taken Outtacontext at 7:46 AM on May 26, 2002
Last summer as I was trying to put together my new lawnmower, I was beginning to feel like a real dunce. Part A would not fit on Part B as the instructions so "clearly" stated. Come to find out, Part A was not supposed to fit on Part B. And I was missing the correct part to boot. When I called the store I purchased the thing from the guy said "oh yeah, that happens all the time." Doh!
posted by Taken Outtacontext at 7:46 AM on May 26, 2002
One quibble: "Americans buy the most sophisticated computers, the coolest digital cameras, the most advanced automobiles, the most versatile cell phones and handheld organizers..."
I don't agree with this at all - I've seen much more sophisticated and cool and advanced electronic devices in Japan and Europe. We're late adopters compared to some other societies.
As for reading the manual - well ... (from the articel) "It's too time-consuming and I'm impatient..."
Doesn't that say it all?
posted by acridrabbit at 7:50 AM on May 26, 2002
I don't agree with this at all - I've seen much more sophisticated and cool and advanced electronic devices in Japan and Europe. We're late adopters compared to some other societies.
As for reading the manual - well ... (from the articel) "It's too time-consuming and I'm impatient..."
Doesn't that say it all?
posted by acridrabbit at 7:50 AM on May 26, 2002
Not to mention that an estimated 40 million US adults are functionally illiterate, and 44% of all American adults do not read one book in the course of a year.
(--U.S. Department of Education)
posted by acridrabbit at 7:58 AM on May 26, 2002
(--U.S. Department of Education)
posted by acridrabbit at 7:58 AM on May 26, 2002
I actually think the biggest problems with manuals is that they're terribly inefficient -- and people wouldn't mind spending more time on them, if so much of that time wasn't spent reading stuff they either already knew; didn't need to know; or didn't understand.
Also, the fact that they're typically badly written is probably more significant than people realize. For instance, the single most important factor in the quality of a technical training course isn't how smart or experienced or knowledgeable the trainer is, but his or her teaching style (according to a couple training associations, at least).
Most manuals are unpleasant and tedious, and they waste too much of your time -- even when the information they contain is actually accurate. Of course people hate using them.
posted by mattpfeff at 8:09 AM on May 26, 2002
Also, the fact that they're typically badly written is probably more significant than people realize. For instance, the single most important factor in the quality of a technical training course isn't how smart or experienced or knowledgeable the trainer is, but his or her teaching style (according to a couple training associations, at least).
Most manuals are unpleasant and tedious, and they waste too much of your time -- even when the information they contain is actually accurate. Of course people hate using them.
posted by mattpfeff at 8:09 AM on May 26, 2002
Sure, many manuals are not great, but many people don't check them at all before calling for help: they think they're too smart to read the manual but suddenly they're too dumb to do anything without step-by-step hand-holding over the phone.
posted by pracowity at 8:26 AM on May 26, 2002
posted by pracowity at 8:26 AM on May 26, 2002
I always read the manual, but not until later, after I've played with it a bit. I'm always hoping to find some little hidden feature I didn't know exsisted.
posted by Mick at 8:38 AM on May 26, 2002
posted by Mick at 8:38 AM on May 26, 2002
I never read manuals simply because it's more fun to find out the hard way
posted by dong_resin at 8:40 AM on May 26, 2002
posted by dong_resin at 8:40 AM on May 26, 2002
Your reasoning for not reading manuals sounds similar to that used by those folks who still refuse to wear seatbelts. That is, citing a few bad incidents to excuse the obvious better alternative.
And I don't believe manuals are exactly meant to be 'read'. Rather they should be perused for significant information relating to the problem at hand, (assembling and turning-on- usually being the first), and those bits read and understood, then other points scanned and noted for re-reference as they come up.
Perhaps your concepts about 'reading' manuals is why you negligently avoid the task?
posted by HTuttle at 8:50 AM on May 26, 2002
And I don't believe manuals are exactly meant to be 'read'. Rather they should be perused for significant information relating to the problem at hand, (assembling and turning-on- usually being the first), and those bits read and understood, then other points scanned and noted for re-reference as they come up.
Perhaps your concepts about 'reading' manuals is why you negligently avoid the task?
posted by HTuttle at 8:50 AM on May 26, 2002
I think we like puzzles and like to try to figure things out on our own. The manual is like having the answers in the back of a magazine. You only check them when you're stuck and can't get help from everybody else in the room.
posted by mikhail at 9:19 AM on May 26, 2002
posted by mikhail at 9:19 AM on May 26, 2002
Apple has almost completely abandoned the concept of manuals. I remember getting my Apple IIc and IIGS way back when and completely ignoring the huge, spiral-bound manuals. Now, hardly any Apple-made product has any instructions whatsoever, and most of them don't really need any.
posted by evanizer at 9:20 AM on May 26, 2002
posted by evanizer at 9:20 AM on May 26, 2002
Ooohhh ... I've got to agree with that article 100%. Have been wrestling with this for years - it is a trend that I think is getting more widespread as the years pass. The thing is, however, (being a capitalist) my own response is not to be pejorative about it ("stupid consumers"), but rather to take it as a market signal about consumer preferences. And what that market signal seems (to me) to say is that product design needs to focus far more fully on what techies would call the "User Interface".
Whirlpool has it right in the article, I think ... "Whirlpool's goal is to design a product "so intuitive that it doesn't need specialized instructions, use and care guides," Jones said."
But you see this in other firms as well. MacIntosh has always had rockin' good designers. Setting up a Mac generally reduces to plugging a couple of cables into clearly marked ports, and turning it on. It is a corporate philosophy (their MP3 player's design is also great).
Biggest point is that traditional design starts with engineers and product designers - and generally only at the end starts to integrate the user into things ... tech manuals are often an afterthought.
In my own business (I design large IT systems for a global firm) I noticed, some time ago, that traditional IT building an n-tier system will have a significant number of database geeks and a goodly number of middle tier coders, but usually only a small team of UI people - to software engineers, the GUI is considered somewhat trivial ... nothing but a thin shell of pretty pictures that covers the real application. However, to the end user, the presentation layer (that trivial thin shell) is the only tier of the application that exists.
The really good companies understand this. They simply accept that virtually no one is going to read the instructions prior to using an eCommerce site. So they build context-embedded help into the app itself ... the questions or functions that everyone has problems with all have little question mark icons next to them - so at the moment a user runs into difficulty, they click the icon and instructions (and often examples) are given. Long applications are broken into several pages, with a JavaScript check after each page (that checks for mistakes, and instructs the user how to correct them).
While this seems simple to do, it really reflects an entirely different kind of design philosophy - the UI people and tech writers are brought into the project from the very beginning (because the help and training functions are built into the application itself), and are considered equal in status to the hard-core coding geeks - and in the really good firms, they not only write instructions while the app is being created, they can actually affect it's architecture ... e.g., when they realize the engineers have created something that makes perfect sense to them, but that will require the end user to jump through a dozen confusing hoops, they can help refine the function (and as the tech writers on MeFi know, engineers are often clueless about what is easy or difficult to end users ... this is often discovered only during the writing of the manuals).
Modern software engineering is moving in this general direction - with the large methodologies all taking the user into account closer to the beginning than to the end of projects ... e.g., the Rational Unified Process, that starts with extensive use-cases prior to the first line of code being written, or the "Extreme Programming" model that includes nearly daily interaction with intended users.
This trend is starting to appear all over manufacturing (whether it is engineering software or physical products), and while I think it will ultimately come to dominate, it does represent a big shift in the thinking of a lot of corporate cultures, and may take some time before it is really widespread. A decade from now, however, what we now call a "User Manual" may not even be shipped with a lot of products.
(Sorry for the long post - this happens to be a topic I dwell on a lot).
posted by MidasMulligan at 9:41 AM on May 26, 2002
Whirlpool has it right in the article, I think ... "Whirlpool's goal is to design a product "so intuitive that it doesn't need specialized instructions, use and care guides," Jones said."
But you see this in other firms as well. MacIntosh has always had rockin' good designers. Setting up a Mac generally reduces to plugging a couple of cables into clearly marked ports, and turning it on. It is a corporate philosophy (their MP3 player's design is also great).
Biggest point is that traditional design starts with engineers and product designers - and generally only at the end starts to integrate the user into things ... tech manuals are often an afterthought.
In my own business (I design large IT systems for a global firm) I noticed, some time ago, that traditional IT building an n-tier system will have a significant number of database geeks and a goodly number of middle tier coders, but usually only a small team of UI people - to software engineers, the GUI is considered somewhat trivial ... nothing but a thin shell of pretty pictures that covers the real application. However, to the end user, the presentation layer (that trivial thin shell) is the only tier of the application that exists.
The really good companies understand this. They simply accept that virtually no one is going to read the instructions prior to using an eCommerce site. So they build context-embedded help into the app itself ... the questions or functions that everyone has problems with all have little question mark icons next to them - so at the moment a user runs into difficulty, they click the icon and instructions (and often examples) are given. Long applications are broken into several pages, with a JavaScript check after each page (that checks for mistakes, and instructs the user how to correct them).
While this seems simple to do, it really reflects an entirely different kind of design philosophy - the UI people and tech writers are brought into the project from the very beginning (because the help and training functions are built into the application itself), and are considered equal in status to the hard-core coding geeks - and in the really good firms, they not only write instructions while the app is being created, they can actually affect it's architecture ... e.g., when they realize the engineers have created something that makes perfect sense to them, but that will require the end user to jump through a dozen confusing hoops, they can help refine the function (and as the tech writers on MeFi know, engineers are often clueless about what is easy or difficult to end users ... this is often discovered only during the writing of the manuals).
Modern software engineering is moving in this general direction - with the large methodologies all taking the user into account closer to the beginning than to the end of projects ... e.g., the Rational Unified Process, that starts with extensive use-cases prior to the first line of code being written, or the "Extreme Programming" model that includes nearly daily interaction with intended users.
This trend is starting to appear all over manufacturing (whether it is engineering software or physical products), and while I think it will ultimately come to dominate, it does represent a big shift in the thinking of a lot of corporate cultures, and may take some time before it is really widespread. A decade from now, however, what we now call a "User Manual" may not even be shipped with a lot of products.
(Sorry for the long post - this happens to be a topic I dwell on a lot).
posted by MidasMulligan at 9:41 AM on May 26, 2002
apple's manuals are fun, they do have them, but they're one fold out page, with pictures and no words. much like the ikea assembly instructions. they're easy, and you don't need 25 languages.
posted by rhyax at 10:37 AM on May 26, 2002
posted by rhyax at 10:37 AM on May 26, 2002
MidasMulligan, I agree with you. If UI/Industrial Designers/tech writers are brought together from the beginning, then the normal outcome is often very different.
I'm pretty tech savvy but in the last few years have been feeling pretty "old" (read feeble?) when I look at new contraptions. They seem to get more complicated (or is it that I am striving for simplicity?).
Went to a discussion a while back with an Industrial Designer who said that having more that seven buttons on something was too much. Apparently, the limit for us humans is about 7 (is this why we have only 7 days a week?). Anymore and we get lost.
posted by Taken Outtacontext at 12:07 PM on May 26, 2002
I'm pretty tech savvy but in the last few years have been feeling pretty "old" (read feeble?) when I look at new contraptions. They seem to get more complicated (or is it that I am striving for simplicity?).
Went to a discussion a while back with an Industrial Designer who said that having more that seven buttons on something was too much. Apparently, the limit for us humans is about 7 (is this why we have only 7 days a week?). Anymore and we get lost.
posted by Taken Outtacontext at 12:07 PM on May 26, 2002
One thing I almost always put in manuals I work on, and which I've noticed a lot of manuals are missing, is an "orientation" chapter that explains the basic design philosophy of the product, its main features and how they're organized, so that a reasonably clever person can just read that and guess where to find the important controls and/or settings. This can be written in a narrative style that draws the reader in, reinforcing their enthusiasm for the product (post-sale marketing!) as well as giving them a mental map for dealing with the product, which makes them believe it's as easy to use as you claimed in the ad. (Of course, this requires that the product is reasonably logically laid out.) From this section you can also point readers to additional information on each concept or feature you mention, which provides easy entry into exactly the features the reader is most interested in.
My very first freelance job included a chapter like that in the outline, and the client vetoed it, saying it was a waste of time. I wrote it anyway, and the client later agreed that it really improved the documentation. I almost always look for such a document when I first get a new, unfamiliar product with even a moderately complex interface.
posted by kindall at 12:11 PM on May 26, 2002
My very first freelance job included a chapter like that in the outline, and the client vetoed it, saying it was a waste of time. I wrote it anyway, and the client later agreed that it really improved the documentation. I almost always look for such a document when I first get a new, unfamiliar product with even a moderately complex interface.
posted by kindall at 12:11 PM on May 26, 2002
I've been a technical writer, web and interface developer and now manage support and maintenance contracts for a software company making specialist scientific applications. So I can say I've seen this problem from several perspectives.
I was going to drone on about the importance of robust development methodologies and iterative development processes that include user requirements from the very beginning. Then I read Midas above and... what he said.
Regardless of particular methodology however, the essence is that the desire to implement user-driven development, has to be championed and implemented organization-wide.
posted by normy at 1:08 PM on May 26, 2002
I was going to drone on about the importance of robust development methodologies and iterative development processes that include user requirements from the very beginning. Then I read Midas above and... what he said.
Regardless of particular methodology however, the essence is that the desire to implement user-driven development, has to be championed and implemented organization-wide.
posted by normy at 1:08 PM on May 26, 2002
Another salient point only vaguely touched on in the article is the never-ending feature creep of products that eventually makes them far too complex to be used without having a solid grasp of technology, or at least the manual. I mean, does a washer really need a separate jeans cycle and towel cycle? Do cell phones really need to do all those other things on top of sending and receiving phone calls? Not always.
This is partly the fault of the manufacturers themselves who have created a need to constantly "improve" products by adding features so that it would seem to the consumer that a washer that might last 20 years ought to be replaced a lot sooner and more frequently. When it gets right down to it, the basic functionality of a lot of products never really changes, and additional features simply obscure the original function.
While tech-savvy folks may be the prime demographic for complex stereo gear, digital cameras, and such, household appliances have a much, much broader base, and as you dilute the knowledge pool across a wide segment of society, featurism is not as desirable as a marketing department full of 20-something geeks might think.
posted by briank at 5:14 PM on May 26, 2002
This is partly the fault of the manufacturers themselves who have created a need to constantly "improve" products by adding features so that it would seem to the consumer that a washer that might last 20 years ought to be replaced a lot sooner and more frequently. When it gets right down to it, the basic functionality of a lot of products never really changes, and additional features simply obscure the original function.
While tech-savvy folks may be the prime demographic for complex stereo gear, digital cameras, and such, household appliances have a much, much broader base, and as you dilute the knowledge pool across a wide segment of society, featurism is not as desirable as a marketing department full of 20-something geeks might think.
posted by briank at 5:14 PM on May 26, 2002
Emphasizing a point made above by many of my (son to be former, perhaps) fellow technical writers: We're the Rodney Dangerfields of the IT profession. At best, we're viewed as the folks who take whatever the rest of the team deigns to give us so that we'll use whatever features Word has to "make it pretty." At worst, we're tits on a bull, frankly. Documentation is nearly always viewed as overhead even when it's paid lip service as a feature.
In fifteen years, I have worked on exactly one six-month project where I actually contributed to product development and participated as an equal. The rest of the time, I've been unable to get the management team to see the advantages of having me at the meetings too.
I got laid off two months ago, and this fall I'll probably go back to school to become a programmer and find out what that side of the conference table is like.
posted by alumshubby at 5:48 PM on May 26, 2002
In fifteen years, I have worked on exactly one six-month project where I actually contributed to product development and participated as an equal. The rest of the time, I've been unable to get the management team to see the advantages of having me at the meetings too.
I got laid off two months ago, and this fall I'll probably go back to school to become a programmer and find out what that side of the conference table is like.
posted by alumshubby at 5:48 PM on May 26, 2002
I'm a sucker for the new and improved product, and often mangle it in an attempt to prove how good I am at using it before I know what the hell it does.
posted by adampsyche at 5:50 PM on May 26, 2002
posted by adampsyche at 5:50 PM on May 26, 2002
CrayDrygu, do you have a beard? -grin
posted by Taken Outtacontext at 6:49 AM on May 27, 2002
posted by Taken Outtacontext at 6:49 AM on May 27, 2002
« Older Cannes film sickens audience | Newer »
This thread has been archived and is closed to new comments
posted by dabitch at 6:27 AM on May 26, 2002