If No One Reads the Manual, That’s Okay
Most people take time off during the holidays, so if you don’t, you end up mostly sitting alone at work, wondering why you’re not taking time off too. I wanted to follow Penelope Trunk’s advice about pursuing your pet projects while working during the holidays, but instead I was trying to finish a project with an end-of-year deadline.
The project I’m working on is critical, but it has only about 3 to 4 users, most of whom are already familiar the application. One of the users even drives the design. The manual I’m writing, which is nearly 200 pages, is mostly a safety measure for business continuity planning. I don’t expect anyone will ever read it.
It’s a project I managed to procrastinate for months, working on other projects, even outside the scope of my regular assignments. The main deterrent, I believe, was my perception that no one needed the manual. The users seemed to be getting along fine without it.
And so as the year ticked to a close, instead of learning more about Mediawiki and screencasting and After Effects, I spent my time updating a 200-page manual that I don’t think anyone will ever read. It will be printed out, three-hole punched, and placed in a binder to collect dust on a shelf.
The idea that “no one reads the manual” is certainly not new. But despite this accepted truism, most of us don’t entirely believe it. I think we always have an imagined audience in mind when we write. I often imagine a confused user searching for questions in the help, or a new employee printing out the manual and reading it, making notes in the margins and going step by step through tasks a manager marked. I imagine a user familiar with an application suddenly dumbfounded on a specific screen, clicking help and scanning for answers.
I need this fantasy about the way my manuals are used because without it, there’s no motivation to write.
Charles Hurwitz, a technical writer in Israel, recently had an experience that confirmed the idea that no one reads the help. Charles writes,
Early on in my tech writer career I had the eye-opening experience of walking into an engineer’s office and seeing a multi-volume set documentation on his bookshelf still covered in shrink wrap. I thought to myself that after all the months work on the manuals he should at least have the common human decency to take off the shrink wrap. It’s like buy a painting and hanging it with the painted side facing the wall. Since then when people ask me what I do I tell them I write books that nobody reads. (It’s Official–Nobody Reads the Manual)
In his post, Charles also references a survey by Gadget Helpline that found 64% of men and 24% of women don’t read the manual before calling support (Gadget Problems Divide the Sexes).
It’s not just a matter of putting the manual gently aside. Users actually despise long manuals. Ron Jeffries writes, “Your customer hates big manuals. He has shelves and boxes full of them just like you do.” (Manuals in Extreme Programming).
I believe the discomfort of reading a 200-page manual compares with the pain a dentist administers when removing a tooth, or the frustration an IRS writer creates when he or she makes a long, complicated tax booklet users will have to figure out.
Joel Spolsky, a programmer and web entrepreneur, says,
Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done. (Designing for People Who Have Better Things To Do With Their Lives)
When I interviewed Mike Hughes several months ago for a podcast, he said the conclusion of most studies about how people use help is that they don’t actually use help.
Some writers still find hope in the rare instances when users will consult the help. Sheila Fahey of Cherryleaf explains: “When things go wrong and it matters to the user, they will seek assistance. They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it.” (If no-one reads the manual, then why bother?)
Looking at help this way is seeing the help as an emergency kit in a car. People won’t normally need the emergency kit, but when you’re stranded on the side of the road in the middle of nowhere and hungry and cold, you will use it. You will break it out of the plastic wrap and actually use it.
Flipping Sides
Not many writers consider the positive aspects of users not reading the manual. If you do a lousy job on the manual, or if some SME discovers typos and inaccuracies, you can just laugh it off by saying no one really reads the manual anyway.
But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it’s probably going to tank on the market and you’ll soon be out of a job anyway.
Also, if so many people are consulting the help, you probably aren’t contributing enough on the design/usability side of your technical writing role. Remember that you’re part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that’s a good thing.
No One Knows
Knowing exactly how often help is used and by whom is hard to measure. If your help is entirely online, you can measure basic hits easily enough. But if it’s distributed in print, you can’t really know.
For example, on Christmas day, my sister-in-law was putting together a fish tank and filter for her boyfriend. (By the way, a Betta fish is a cool present to give someone.) Installing the pump and filter was confusing. Was the pump supposed to be above or below the waterline? Was it supposed to be making that humming noise?
At one point, just as she and other family members were getting frustrated, one person jeered, I can’t figure it out, and there’s no manual at all!
More people get frustrated assembling things on Christmas than on any other day of the entire year. It’s a day manuals are both cursed and blessed. But in this scenario, no doubt the company that created the filter was unaware of the frustrated user stuck without a manual. We’re often in the same position of ignorance about our users.
If you think about it, the technical writer is in an unusual role. Users hate the presence of manuals as much as they hate missing manuals. They despise lack of detail yet curse length. If no one reads the help, your position lacks value. If everyone reads the help, you’re on a sinking ship. Ideally, you want the user interface to be simple enough not to need help. But the more you contribute to this user interface simplicity, the less you’re needed.
Conclusion
As the year closes and the project manager is off skiing and the developers are playing video games and the quality assurance engineer is organizing his closet, I’m pounding out the last topics of a 200-page manual that I will soon deliver to a group of users who will smile and thank me for the manual, knowing they don’t have to read it or critique it anymore, but can just put it proudly on their shelf, or maybe even in a storage box.
If I find out, through feedback or on-site visits or other means, that they don’t ever read the manual, that they have never actually opened the manual beyond the table of contents, that’s okay. I hope they never have to.
Tom:
I think this is your best post of the year (and you’ve had many good ones in 2009)! This one resonates with me — and I’d wager — just about everyone who celebrates gift giving this holiday season. That’s quite a feat in the world of technical communication, where what we do is a mystery to most common folk (and almost always really boring) So, kudus for crafting such a valuable article with a wide potential audience. It’s insightful, informative, interesting, and, as usual, right on the money!
Scott Abel
The Content Wrangler
scottabel@mac.com
Scott, thanks for the comment. I appreciate your feedback. I’m trying to integrate more story into my writing, so if there are any trends for the coming year, that’s it.
The problem as I see it is that we’ve failed to provide well-designed and comprehensive manuals or help files that provide all the information users need when they need it. In your *Flipping Sides* section, you say
[q]“But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it’s probably going to tank on the market and you’ll soon be out of a job anyway.
Also, if so many people are consulting the help, you probably aren’t contributing enough on the design/usability side of your technical writing role. Remember that you’re part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that’s a good thing.”[/q]
In the case of relatively simple applications that are intended to do only a couple simple tasks, the programmers should be able to make them intuitive enough that the users don’t need to RTFM. But to say that all applications can be simplified to that level is nonsense.
However, over the years, I’ve documented a lot of incredibly powerful and complex industrial applications. Even when I’ve threatened the programmers and/or engineers with my *Official Technical Writer’s 2×4®* and gotten them to resolve lousy interface designs, these applications are so powerful and have so many complex controls that no amount of user interface tweaks can make them intuitive. It just ain’t possible. The customers buy these applications because they’re so powerful and complex… they can make them do what they want but only if they can find out how changing the settings of the embedded controls affects their results.
Thanks Mike. I agree that some apps can’t be made intuitive enough to discard the manual. Most robust applications can’t, as you say. If that’s the case, I would try to move as much of the help into the interface as possible (through CSH popups or something similar). If that doesn’t work, and the only recourse is a long manual (or tons of videos and other help material), then yes I would hope the customer reads/watches that help prior to calling support.
My main point in this post (which prob. didn’t come across too well given the other comments) is that rather than complaining about how no one reads the help, we should celebrate the UI wins when users don’t have to read the manual to figure out the product.
Tom, I disagree… it is NOT okay. I understand the goal – a good interface shouldn’t need documentation but the reality is a very different thing. So if we know software requires certain information in order to use it effectively AND we also know no one is reading the manuals, why on earth are we still writing them? Shouldn’t we, as an industry, have awakened by now? You’re right, users are as frustrated with lack of information as they are daunted by a guide’s length but instead of singing the damned if you do, damned if you don’t lament, I think we should be channeling our energies toward new ways of delivering technical information.
It bugs me when we do things we know are a waste of time simply because well, that’s the way it’s always been done. I went off on a tangent and posted a rant on my blog.
Patty, thanks for writing a post in your response. By the way, if you link back to my post in your post, an excerpt of your post will automatically appear here (this is called a trackback).
I agree that manuals aren’t the ideal format and that we should look for the kinds of help materials that users want. There isn’t a magic answer for that one, though. Some prefer one kind of help, others prefer another format, some hate them all, and so on. But help that appears directly in the interface is probably the most helpful.
My main point here is that if only 10 percent of users read the manual — and you aren’t deluged with support calls — then celebrate. It means the software is intuitive enough that users can just figure it out. If you’ve been participating in prototype reviews and other UI designs, then you’re part of a team that has successfully created an intuitive product. We don’t need everyone reading the help.
Thanks! Still learning the blogging ropes… And thanks for sparking such lively debate.
http://writetrends.wordpress.com/
Here’s the link… better late, as they say.
I hate to be the party pooper. This is definitely not your best post, Tom! I do not feel it is “okay” by any means if no one reads the manual. Why would you have a manual in the first place if you know no one is going to refer to it in the long run? Don’t you think as technical communicators it is our responsibility to make stakeholders realize the importance of documentation? I have regular review meetings with the blokes out here, so they know technical communicators are equally responsible for the quality of products they are churning out month after month.
Hi Rahul,
I hear what you’re saying.
I don’t expect people to read my guides but when they do I want it to be correct. That’s my job. Is the doc doing its job?
I’m not Ernest Hemingway or Dan Brown. If they don’t read it, no probs.
Ivan
Wow, Tom. In a quiet week, you probably didn’t expect such a lively reaction to your article.
I’m with Patty on this one. If the manual really were like an emergency kit in a car, then — yes — I’d be just as happy if no one ever needed to read it.
But the manual isn’t like an emergency kit. By your own admission it’s something that, if it were used, could prevent a lot of costly support calls. So, as Patty says, we have to find a way to give this information to the users in a format in which they’ll want to receive it: a knowledge base, a context-sensitive help system, whatever.
Hi Tom
You have many valid points, but I agree with Patty. I think you present many generalizations about manuals. I have written, or rather edited, manuals of 400-700 pages. They were not meant to be read cover to cover. They were actually what some call data sheets that described the electrical specifications of chips for the semi-conductor industry. Some engineer putting that chip inside a router needed to know everything that could be done with that chip – or what consequences there were. I think what a chip does is very, very simple, but the technology behind it is very, very complex. The massive manuals (only delivered as PDFs) were meant to be studied, but probably by a team and probably only in certain sections. Bits would probably be printed out for reference at a workbench.
That is a manual completely unrelated to what could be a reference card for that fish tank styled in Lego or IKEA fashion.
We’re back to “it depends”.
Also, we all have different job experiences. Some cannot get a seat at the table when specifications are discussed. Either those companies are blind to the potential of a technical communicator, or the technical communicator needs help breaking through this glass ceiling. I sense that more and more technical communicators are aware of their skills, but so many employers are still decades behind in their mindsets.
We need a grassroots revolution to educate the employers and the employees. It is happening, but much patience is still needed, along with an awareness that one size will not fit all and is not wanted by all.
Karen, I liked your comment. You’re right about the “it depends” clause. The semi-conductor chip versus the Ikea legos are quite different situations.
Re not having a seat at the table with design, another valid point. Strangely, with some projects I have that seat and with others I don’t. It depends on the project manager and my initiative to get involved in that project.
Tom: One thing I’ve learned from my blogging and social networking experiences is that if you get a lot of reaction (especially, passionate reaction over a holiday period), you know you’re onto something. And, you are. (You should see the emails and instant messages I got from some of your readers after I promoted this link via Twitter and Facebook this morning.)
There is nothing wrong with our customers not reading the manual. What wrong is that we believe it’s important. Who cares what technical communicators think? I care about the customer! And, customers don’t want to read. They may be required to read — in certain circumstances — but I’d wager to guess that majority do not want to.
Of course, in the world of consumer products, choices are made often on price, then on usability. When a product is poorly designed, many customers will step up to the next best product (witness the success of the iPhone over the sub-par mobile devices that we used prior to Apple changing the mobile communications market by designing a far superior smart phone product at a higher price point). It doesn’t matter how fabulous the documentation for those shitty little phones was (press the “2″ key three times to display the letter “F”), the product sucked. And so, the market is dying.
This is also true for manuals/documentation, which is part of the product, and therefore, part of the problem. It’s a dying part of the product IMHO. Sure, there are exceptions, but for the most part, the manual is dead. There are better ways to get information and consumers gravitate to the ones that are easiest and less stressful. Phone support seems fastest and is often why people use this method first, even when the manual is open and right next to them. It’s only when the telephone support experience sucks that they give up on this option. However, increasingly, users are using search engines to find answers. I can’t count how many times in the past week I found an answer to a product question by searching the web and landing on a blog post or social media thread dedicated to my exact challenge. It was fast, accurate, and fixed my problem. What do I need the manual for again?
What we need to do is get over our addiction to the idea that the manual is as important as we think it is. It isn’t. I’m sure many disagree with me, but I’m accustomed to it. Bring it on!
[Tom insert -- Note from sponsor: For a side-related tangent on addiction, see drug addiction statistics.]
What I’d like to see are technical communicators step up to the plate and admit that 1) it’s time to develop some new skills, and 2) that our industry is woefully unprepared to meet the challenges we face today. Why aren’t we talking about delivering content as a service through widgets, social networks, mobile devices and Apps? Why aren’t we developing systems that put HELP at the forefront of the system, not the HELP CONTENT we write? Why not allow users to help one another and to participate in the documentation process? Why not make the content shareable, tweetable, embeddable? Why are we not allowing users to tell us what they want and need? Why are we talking about manuals when most technical communication departments are still creating unstructured content using tools designed for word processing and desktop publishing? Why aren’t we using component content management systems to create personalized content on demand? Why aren’t we using controlled vocabularies to help avoid ambiguity and the resulting challenges terminology-related issues add to the mix (including increased support calls, customer dissatisfaction, unnecessary risk, expense, blah, blah, blah etc.)? And, why aren’t we educating our shareholders about the importance of video — the most successful way to SHOW someone HOW to DO something?
For those of you who believe manuals are important — I know you’re reading this now — why haven’t you moved to eBook format? eBooks are interactive manuals that actually provide value to end-users. They allows us to embed 3D graphics, video, search, links, etc. and when viewed on a mobile device, a laptop, smart phone, kiosk, etc. — basically any device connected to the internet — they allow users to look up terms they don’t understand, communicate with others, share information, etc. And, they offer all sorts of benefits that paper manuals don’t. For instance, they remember the last page you were on when you stopped reading. They allow you to add bookmarks, to highlight passages, add annotations, etc. and share that data with others. Oh, and when created according to industry standards, they repaginate themselves based on the device on which the content is being viewed.
There are so many good reasons to kill the manual and move to eBooks, that it astounds me that we are still arguing about manuals at all.
Of course, preparing content to be output into meaningful formats like interactive eBooks means breaking the old paradigm and moving to a topic-based architecture (DITA), using an extensible markup language (XML), managing the content in a central repository (a component content management system), and using semantic information (metadata) to help us manage, assemble and deliver information products of value for our customers on the fly, regardless of the device type on which they choose to access our content.
That said, I’m sure I have some manual-loving, desktop publishing-worshipping, style guide-driven tech commers foaming at the mouth. Can’t wait to hear their arguments, although I think their time would be better spent learning new skills than defending their old school views.
Did I just say that with my outside voice? I’ve got to learn to control myself.
Happy Holidays!
Scott Abel, The Content Wrangler
+1 (760) 550-9321 scottabel@mac.com
blog: http://www.thecontentwrangler.com
community: http://thecontentwrangler.ning.com
twitter: http://www.twitter.com/scottabel
friendfeed: http://friendfeed.com/thecontentwrangler
facebook: http://www.facebook.com/scottpatrickabel
linkedin: http://www.linkedin.com/in/scottabel
businessweek: http://bx.businessweek.com/profile/scott-abel/sabel755/
TED: http://www.ted.com/profiles/view/id/377368
Intelligent Content 2010
The Magic Behind Intelligent Content
Feb. 25-26, 2010 * Palm Springs, CA
http://www.intelligentcontent2010.com
Couldn’t have said it better, Scott.
Scott, thanks for the impassioned reply. I really agree with your point that technical writers place too much emphasis on the manual and in highlighting issues with users not reading it. It’s really a projection of our own shortcomings with audience analysis and poor choice of help format rather than the user’s problem.
All too often, we write manuals because project managers request them, and we lazily say okay, one manual coming up.
I usually don’t create a long manual as my main deliverable. As I said in my post, this manual is mainly for business continuity. That said, I want to transition it to a wiki so that it doesn’t become stale. (I would have started it on a wiki except that the technology for the platform I wanted wasn’t available at the time.)
Thanks again for your comment. You add a lot to the discussion. Reading your reply makes me feel like I’m behind the times — it reminds me of all the things I need to be doing.
Hi Tom, Hi Scott,
<What wrong is that we believe it’s important
Quite a few TWs I know have/had hopes of becoming real writers, such as novelists, screen-writers, reports and ended up in tech docs. But life doesn't always work out as we'd hope and they end up stuck in a career that doesn't satisfy them.
It's often these types that get the most irritated that no-one reads their docs, or when they find typos in others texts.
That's just life. I try to take the barbed comments when they arise and remembers what's really eating them.
When I have the patience/strength to remember this, I just let it go.
Ivan
Manufacturers have recognized the problem that no one is going to sit down with a manual when they first take their shiny new printer/camera/whatsit out of the box. Pretty much every piece of equipment I’ve gotten in latter years has come with a quick-start guide of some sort that outlines on one page (sometimes a poster-sized one) how to get the thing up and running. I’ve also noticed that manufacturers of hardware devices have been putting big stickers directly on the device that will say something to the effect of “Stop! Load the software before you try plugging this thing in!”. Both of these strategies are designed, obviously, to reduce user frustration and of course to reduce the number of calls to tech support.
I particularly notice the phenomenon that you’re writing about — the manual that no on reads — when I unpack some device whose interface is so familiar that it’s hard to imagine the person who needs a manual for it. We recently got a new mixer, for example, which duly came with instructions for how to insert the beaters, how to plug the thing into the wall, and how to turn it on. (The real excuse for the manual, it seemed to me, was the multiple pages of warnings about how not to use it underwater and so on.) Then there are also instructions for things that just don’t need instructions, which I occasionally feel moved to blog about, e.g.:
http://www.mikepope.com/blog/DisplayBlog.aspx?permalink=2135
Overall, I actually agree that the ideal documentation is a perfect user interface. Some things, tho, cannot be made so obvious that there’s no need for any docs. As we know.
Mike, the example of the dog collar instruction is hilarious. Thanks for adding the link to this discussion.
I agree that manuals are becoming almost a legal requirement simply to cover certain bases, rather than to provide instruction to users. If a product has a manual, people feel more at ease, regardless of how bad the manual or that choice of help material may be.
Love this post. It made me think about the early days of my career when I wrote technical documentation at a software company.
I remember thinking to myself, “There is no way people are reading this.” But I also remember thinking that the precise nature of the language of manuals is lovely and poetic and made me think differently about language. (I still think about click vs. click on and button vs. icon, etc).
In hindsight, I think that forcing everyone at the company to talk in precise language so the technical writer can translate it is actually good for everyone. We all think harder about what we write when there is a (proverbial) tech writer in the background saying “that’s jargon” or “that won’t make sense to anyone but you”.
So, maybe it doesn’t matter that people don’t read most technical documentation. Maybe what matters is that the tech writers make everyone better at their jobs, and maybe at their lives, because they think more about what they are doing and how to say it.
Penelope
Penelope, I didn’t know you were once a technical writer. That’s cool to learn.
Your comment about improving the overall language that a company uses within a product is certainly worthwhile. I think a lot of the confusion in software interfaces comes precisely from our word choices for buttons, labels, error messages, and other interface components. I hadn’t thought as much about that contribution that technical writers make, so thank you.
Also, thanks for reading my blog.
Great post, Tom.
You make a good point: Sometimes it’s not so much about the audience as the situation. “Why am I writing this?” is as important a question as “For whom am I writing this?” Both affect our expectations.
When we write for someone who’s never seen our company’s product before and has to demonstrate proficiency with it before going home for the day, it’s bad if that customer won’t read the manual, tutorials, or help.
But your disaster recovery/business continuity scenario sets different expectations. It’s more like buying insurance; you hope you’ll never need it. If something truly awful happens, though, the manual is there to tell people what to do. And if nobody ever needs to read it, we offer a prayer of thanks.
Karen, thanks for your comment. I like your point about focusing on the who instead of the what. That focus indirectly makes us pay attention to the what, but only in the context of the who (i.e., what they want).
Pingback: Hone writing skills or specialize? | just write click
I love this post because it really fires the debate “should we write documentation for documentation’s sake?” plus it’s worth considering that the more you give people to read the more time and money is wasted, particularly if that information is voluminous and unwieldy.
People ring support because they want quick answers to software issues that prevent them from achieving their organisational goals. Show me a manual that stays in shrink wrap in a support department.
I think the issue requires consideration of context before we tar everyone with the same brush. In our organisation the reference manual is read by support and cheat sheets are distributed regularly when support call volume indicates a need for training.
To apply Einstein’s quote: “Everything should be made as simple as possible, but not simpler. So Keep it simple: Meet the need at the right time in the right place with the right doco. No simpler.
Http://thetechwriter.posterous.com
Cheers
Nikki Ward
Nikki, thanks for joining in the discussion here. I liked your comment that no manual stays in shrink wrap in a support department. Someone needs it, and that person usually ends up helping others.
I’ve been in tech comm a long time, and I’ve been married just as long time to the guy I’ve always considered my “Exhibit A” for how most guys read manuals: He reads the first couple of paragraphs, flips through a few pages, looks at the illustrations, and says, “Hey, I can do that!” Then, if he starts having trouble, he calls me and says, “Look at the manual and tell me what to do next!
This taught me to put the most important warnings on the cover or in the first couple of paragraphs, and to make everything else as simple and succinct as possible. (Then one of the kids could read the instructions to him!)
I learn a lot from watching my wife read manuals. She puts such immense trust in their accuracy and completeness — and then when there’s something wrong in the manual, she can hardly believe it. I find her trust kind of funny, because I know that software manuals have as many bugs as the applications they describe.
Hi again
Just to chime in with another angle. Our profession is not just about “manuals” – it’s whatever it takes, so yes, more intuitive interfaces, videos, etc. must be considered.
Not everyone writes about “things” or software. Writing policies and procedures is also in our field. That leads to this horror story shared by @cybertext on Twitter today: http://boagworld.com/reviews/vimeo. Maybe I am being a dreamer here, but a strong tech writer could have provided much better clarity in the Terms and Conditions section. OK, if Vimeo has feeble policies, blame management, not the writer, but could the text be clearer, easier to grasp – before someone paid good money for a service they would ultimately be denied?
Legalese is definitely an area that could do with some TLC from technical communicators.
I think this also chimes with what Margaret says. Boy, when I signed hundreds (felt like it) of documents to get my mom into the nursing home, I could have used a clear heading on each page: This is if your mom needs X, this is when your mom does Y, this is when your mom is eligible for Z, and so on. I could deal with the small print later (which I never did).
Text abounds in legal-type docs and there is plenty of room for improvement. Please!
Thanks once again for bringing up this topic. It is nice to see a flourishing discussion where we can all learn.
When you have your documentation on the Web, and it’s instrumented with analytics software, you can tell what parts of the manual people actually read. In the case of After Effects, it turns out that a lot of people do read the manual—some pages far more than others.
Open reply to all who’ve posted comments…
Thank you!
I’m actively engaged right now in expanding my skill set to include alternative methods of information delivery. Working with new formats like screen casts on YouTube, posts on GoogleGroups, Facebook and Twitter, and so on. Beyond the very cool way we were able to agree/disagree without coming to (virtual) blows, I’m so grateful to you all for including links to additional material. I’m absorbing it all like a sponge.
Thank you again,
Patty
Pingback: Blue Mango Blog » Writing 200 Page Manuals That No One Will Read is Insane
My sister never reads the manual. She never buys anything for her house or kids that comes with a manual. “I don’t have time to read,” she says.
If her husband buys something that comes with a manual, she usually makes him take it back, unless she never has to look at the manual and never has to read it. It must be simple enough to not need a manual.
I told her she was making my occupation, well, rather extinct. She smiled and agreed that, yes, in her household, my job of tech writer would rapidly morph into that of baby sitter. Still, I adore my sister. Sigh.
Tom, this is an interesting post with a lot of provocative comments.
I especially zeroed in on Karen’s second set of comments. While software support certainly dominates our industry, I have known a number of tech writers and editors who have never documented software. They work in diverse industries such as science, medicine, policy, law, and certain types of training. The manual–or whatever form their content takes–is often required reading. It might explain how to perform an essential job task or it might prevent accidental death.
I agree with comments that we have to keep our skills fresh, but I also believe that we have come to regard social media and other trends with an esteem that’s beginning to border on parody. I say this as a user of many social media sites and tools. When I need software help, I actually turn to online help first, and many of the tools I use have excellent help that’s blended with local and online content. Beyond that, I enter an error message string (or some equivalent) in a search box and hope for the best.
I also note the increasing emphasis on video-based learning and dissemination, and I am in favor of it. I happen to be a lynda.com subscriber because I like video-based learning for certain applications. But video-based learning is not a one-size-fits-all solution. Information seekers and learners have varying styles of reception, and some of them prefer to simply read, whether it be a manual or a web page. Although tech writers should certainly be able to capture and edit screen video, I disagree that they need to aspire to the level of “multimedia producer,” as you stated in a recent post. True mastery of the video medium requires a high degree of training, skill, and visual talent. I have used many screen video tools and have created Flash animation, but I’m no visual artist. And my work has never required more than a basic level of knowledge of video.
I simply think that our industry’s emphasis on tools and trends is taking us farther and farther away from the true reason why many people don’t read our stuff:
Because it’s badly written.
http://www.vanarsdall-infodesign.com/2009/05/31/paving-the-road-to-a-user-utopia/
Much material is badly written, I agree, but I believe that’s only a part of the story. People’s attention spans reach only as far as their latest Twitter post. I don’t know anyone else besides my wife who has read “War and Peace” cover to cover. People don’t want to make the time to read. And when they do read, they really aren’t reading. They are glancing and skimming. Headlines and subheads only. They bore easily. They can’t sit still long enough to read. We have left the MTV Generation in the dust. This is now the Twitter Generation.
If you start to think that nobody reads the documents anyway, why should you bother – then I think you will be tempted to deliver a bad product (document). At the end of the day it is my pride to make the best document I can do. So this is why I care about rules and regulations, about terminology, about standardization, to bring everything into an appealing design and to keep deadlines.
Today I’m head of a larger technical documentation department and my goal is to give the customers a document, which makes the product even better and also to improve processes and the content to save money for the company who pays my salary. This is my personal goal and I try to reflect this to my colleagues. So at the end of the day, we all know that most of our documents will not be read, but there is never a discussion about this. We don’t waste our time for something we cannot change anyway. We sit together and discuss how we can improve the documents and processes. And I can tell you at the end of the day we are happy and don’t have a personal crisis when we look back to what we have or haven’t achieved in 2009.
The reason I believe no one reads the documentation is because that is what I have been told by the people I work with. Customers would rather call support and talk with a live person than thumb through a 200-page guide. Who can blame them?
Would you rather pick up the phone and call the 800 customer service number and talk to someone who can solve your problem right away, or at the very least make you feel better?
Or would you rather try to solve the problem yourself by reading/skimming/glancing through a manual that is at least 200 pages long?
It’s your choice.
Pingback: The Slow Word movement for technical documentation? « ffeathers — a technical writer’s blog
Thought-provoking blog post, Tom, that takes an old technical writing debate “No one reads the manual” and makes it interesting in a William Carlos William’s command about poetry “Make it anew! way…so I guess we can call this post poetry.
My own answer when someone says, “No one reads manuals! is “Really? Ever hear of the “Dummies” manuals? Millions and millions of people have paid hundreds of millions to buy them…and they’re all manuals. So someone still not only reads manuals, but they are willing to pay money to read them.”
As for continuity of operations manuals as a type of manual, they are critically important and, sadly as you say, often ignored.
This is not new.
In the 1980s I used to go to emergency operations centers in various states. I would examine the emergency plans and continuity of operations plans to see if they were up-to-date. I’m not sure I remember any still being in shrink wrap…but most had layers of dust fall off when I removed them from the shelf. So it goes…
One EOC I inspected at that time was in Salt Lake City. The
Great Salt Lake then rose as it has every 60 years for the past 10,000 years, and flooded the city. The locals understood disaster planning and recovery and did a first-rate job of directing the flood waters down to Lake Provo.
Continuity of operations manuals are like insurance…it seems to be human nature that no one pays attention to them until the disaster occurs. Then, they either contribute enormously to a successful and quick recovery…or they are out-of-date and useless and only contribute to the problem.
Although a written continuity of operations plan is necessary, I did participate recently in moving a continuity of operations manual from paper to digital (video and brief screen descriptions in a DVD format) for an organization that faces a high threat level. As they only had a five person training staff, we produced the DVDs as a way for them to reach the other 40,000 members who are located in all 50 states.
You might want to consider reposting and recreating your continuity of operations manual in a DVD format to make it more useful to more people as well. The new DVD we created was very well received by the users.
Although most will never read the full 440-page continuity of operations manual, all have been trained, individually or in groups, on the DVD material.
At a minimum, all now have a memory stick in their USB drive that they keep current and can easily take to the new continuity of operation center to get up and running quickly, which is the purpose of any continuity of operations plan.
Continuity of operations plans are like the Bible: For what is to be known by reading it, everyone should but few do. Yet, the old saying, “You may be the only Bible most people read.” still holds true. So, too, with a continuity of operations manual.
Please remember that there is SO MUCH technology out there that does not appear in any UI but that must be documented to be utilized. APIs, hardware setup, assembly instructions, etc.
Oh, here we go again with technical writers spouting unscientific evidence. Why not just ask MIss Cleo (“Call me now, 1-900-XXX-XXXX) for proof of the importance of the manual.
Let’s be clear, purchasing books has nothing to do with reading them, nor understanding what’s in them … nor worshipping them.
Sales figures do not equate to readership, understanding, comprehension, enjoyment or anything other than revenue generation. Period. End of story.
I purchase books for people all the time. I do so because I want them to read the books and because I love (yes, even me) books. I also think they make great gifts. Alas, the largest segment of shoppers on Amazon.com at Christmas are gift-givers like me. We use psychic power to determine what our gift recipients might enjoy. And, more often than not, I’d wager we are wrong.
I say this because like the unopened shrink-wrapped manuals mentioned earlier, I myself have an entire bookshelf of unread books. So do my friends. When I visit their homes, I see my gift books on their shelves. I can’t help but pull them off the shelf and see if they’ve ever been cracked open. Usually, the answer is no. They are in “near perfect” condition, ready to be sold on Half.com or Ebay.
Even when I buy books for clients — books that I know for a fact have the answers to their questions in them — they don’t read them. Oh, they display them. But, they apparently osmosis works with books. Just sit that book close enough and pray the knowledge jumps off the pages and into their brains.
Alas, it’s frustrating. Some technical communicators — and many other communication professionals — just don’t get it. People want the easiest path to the destination whether it’s to the coffee shop when they drive their car, or to a web page when they are clicking hyperlinks to find information, or when they are shopping at the mall.
Sure, it’s important to differentiate between what’s required of someone at their job (operational knowledge) and what consumers of content desire (product information, directions to a destination, etc.). But just because knowledge is required, doesn’t mean that manuals are important. I can teach a cashier to run a register at a supermarket. That may be a better way than making them read “Cash Registers for Dummies” or some manual created in house or by the cash register manufacturer — or both.
Let’s move past our addiction to avoiding change and embrace the fact that science is needed to help guide our decisions as professional communicators.
In my world, manuals are dead. I don’t want them. I don’t need them. All I need is well-designed products and answers to questions, solutions to challenges. I don’t care how I get them as long as you (the maker of the good or service) makes it easy for me to get the information I desire, when, where, and how I need it.
Anyone else?
Scott Abel
The Content Wrangler
We seem to have diverged here from the Tom’s original post and from what I replied to. In no way was I talking about just manuals… I was talking about documentation in general, no matter how it’s delivered and I believe that was Tom’s point as well.
Having said that, I did write an article ten years ago that was published in Intercom and reprinted in TC Forum, advocating for the continuation of printed manuals. You may read it if you like at http://www.writestarr.com/PrintedDocumentation.pdf . Of all the responses I received to that article, not a single one disagreed with me.
However, the larger issue here is that we can’t make the customers actually read the documentation (manual, online help, wiki, etc.). But if they do, we damned well ought to make sure they can find the answer they need so we don’t have to have someone answer their phone call. The delivery mechanism is irrelevant… any one of them can deliver complete documentation in a manner that makes it easy to find the answer to a question.
And your point is, Scotty, that because you have stopped reading manuals, everyone should? Open-minded of you, boyo.
Bruce:
I enjoyed your reinterpretation of my comment; humorous, but not very accurate. Let me sum it up for you. My point is, from a business perspective (I’m a business person first, a writer second), we should evaluate whether we need manuals or not. Many times, I’ll wager, there’s a better way to provide the information.
The manual will continue to be valuable only if we change it to meet the needs of the users and the reality of how people actually desire to consume information. And, it won’t be created, managed, or consumed in the way we have been doing so for the past two decades or longer. It’s gonna change whether we like it or not.
Scott Abel
The Content Wrangler
These words, Scotty, are yours, not mine:
“In my world, manuals are dead. I don’t want them. I don’t need them.”
Thus, I believe I interpreted your words correctly.
If you had bothered to read my entire original post before you launched into your ad hominum diatribe you would have noted that I made the point first that manuals can often be (better) handled in other ways. That is why I spent half the post recommending that Tom use a DVD medium for his continuity of operations manual.
You posit that you are a business person first. I thought the first attribute of any successful business person is the ability to listen rather than to ridicule and insult, which is what your post’s bleed. Here is just one example in your original post: “Oh, here we go again with technical writers spouting unscientific evidence. Why not just ask MIss Cleo (“Call me now, 1-900-XXX-XXXX) for proof of the importance of the manual.”
Unlike your dialectic in the second post, I stand by my original point that there is still a time and a place for manuals. God is not dead and manuals are not dead no matter how many of the chattering classes proclaim otherwise in whatever new media.
For example, if you wanted to know if you were HPV positive, the FDA regulations state that any medical instrument used by a health care provider must have a manual and procedures for both the software and hardware.
Why? Because health consumers need results that are positive, not false positive, and only procedures and manuals that go through a rigerous quality control process ensure accurate results and that no false positive results are given.
I wrote a manual for a medical instrument that detects HPV and that manual is being used today by technicians who operate and repair the unit. By doing so, doctors are able to confirm that a woman who gives a sample is either negative or positive.
Or…take nuclear power plants. The Nuclear Regulatory Commission requires accurate, quality-control tested, manuals that ensure safe operation of all nuclear power plants.
Or…complex weapons systems used by the military that depend on well written and accurate manuals. There are hundreds of thousands of manuals that meet this need.
I worked on a biohazard detection system manual for an anthrax detection unit that is now deployed to hundreds of post offices and embassies. I wrote a “store of knowledge” manual that includes hundreds of procedures all the software, hardware and internet installation, operation and integration material necessary to make sure American’s and others are never exposed to mail-borne anthrax again. This manual is used by technicians who operate and maintain the unit.
I agree with you that the manual must change and evolve to meet an ever-changing market. Most manuals I write these days integrate as many figure and picture pages as text. My children respond more to visual information than I do because they have grown up with digital media all around them. As I write for a younger audience like them I make sure I use the media they like to use. I also incorporate visual media when I can, including in the volunteer civil defense work I do in my county.
But you are the one who said, “manuals are dead” and I could not disagree more. I work with DVDs, write for technical journals, create videos and use whatever visual media that gets the job done. I also create manuals when the need is there and it is the most appropriate tool for the job. I can assure you the need is there because I make a good living doing so.
Manuals are written and printed in the thousands each year because they meed a need. You many not like it but they do. As Kurt Vonnegut said” “So it goes.”
An aside: When Kurt Vonnegut was asked at Harvard when delivering a commencement speech, “What is the secret to good technical writing?” (he was a technical writer for GE before he became a famous author) he said, “Never use a semi-colon!” Consider that his advice, not mine, Scotty.
WTTW: DITA has jumped the shark…but the Content Wrangler is pretty nifty.
I love it. All I have to do is be a little provocative and the conversation gets much more interesting. Manipulating readers of blogs is fun — and easy — and can create the type of discussion that is occurring here. Kudus for taking time to add your comments Brucey.
As someone who started in pharma (and will be speaking at the Drug Information Association conference this year about the changing nature of communication), I couldn’t agree more that these industries are required to create all kinds of documents, many of which could be called “manuals”. And, I also agree that other regulated industries are still creating them.
But, manuals as they have existed in the past are dying (if not dead in many industries already).
I’m not sure what you are talking about with regard to DITA, however. It’s the most successful XML standard to date and being adopted in all sorts of industries — including in regulated ones where they first created their own standards, but are now moving away from those when a topic-based architecture is needed.
Thanks for engaging me. I ridicule and insult to get readers excited and motivated. I see it worked – again!
Scott Abel
The Content Wrangler
DITA is dead.
Look at how many DITA courses there were at past STC conferences and how many there are today. The latest software and media technology has passed it by. That the federal bureaucracy is finally looking into it is the ultimate proof.
I’ve worked at two major corporations that looked into whether DITA was worth the staff time and cost. Both decided it wasn’t. And these are companies that use CMMI and Six Sigma but they found DITA too great an investment in time and money for too little a return.
When you say, “,,,with regard to DITA, however. It’s the most successful XML standard to date…” if you were intellectually and ethically honest, you would let readers know that you are a self-proclaimed DITA “evangalist” whose company makes more money the more writer’s who adopt your DITA orthodoxy. Your view is obviously tainted and DITA-centric.
Don’t be so quick in your self praise, Non-Abel. Your original claim was that manuals are “dead.” You did some quick backtracking add finally say, “manuals as they have existed in the past are dying.” That is a completely different point and far from your extreme original post.
When you say, “Manipulating readers of blogs is fun — and easy” I would suggest that it is your DITA customers that you are manipulating. I’m only responding to your blog posts and loose nothing. They, in contrast, lose business.
Kudos to you for being manipulative enough to figure out that although the private sector has had it with DITA (for example, perhaps you could provide actual data about how many companies tried, and abandoned, DITA) the feds will always throw money your way for yesterday’s technology. Again, congrats at being so manipulative on so many levels, even the national one.
I was going suggest the “manuals are like insurance” analogy, but someone beat me to it! So another analogy: it’s like roadside recovery (like the AAA in the USA, the AA in the UK and the ADAC in Germany). It needs to work when called upon and the customer needs to feel they might just need it at some stage in the future. If there’s little chance of needing it or the cost doesn’t justify the reward, then people won’t pay. Ditto manuals.
Pingback: Getting users to read the documentation by Communications from DMN
Pingback: Who cares if they read it or not? | one man writes
In the case of relatively simple applications that are intended to do only a couple simple tasks, the programmers should be able to make them intuitive enough that the users don’t need to RTFM. But to say that all applications can be simplified to that level is nonsense.
But the question I’m asking myself is if someone is actually creating the user manual? Yes, some poor sod is handed the low priority and low status task of creating the user manual. Too many manuals are a shame to the products they are supposed to describe. When we talk about whole product concept and the experience is the product, remember the user manual.
Yes, many users don’t read the manual. But why is that? Is it that they’ve learned the hard way that this is in most cases just wasted time?
@Anna Forss –
Yes, I am that poor sod, by your definition, but I like to think I do good job. I wouldn’t say, at least in my case, that creating the user documentation is low-status or low-priority. Granted, writing the documentation may not be as high-profile as developing the applications themselves, but I like what I do. I enjoy it. I like clarifying things, learning things, and organizing information. I think in any other life I would have been a librarian.
Craig, thanks for your comment. Any other life a librarian? Interesting. I never thought of the crossover before. I always imagined librarians had time to sit and read books all day in the library. A few years ago, my aunt changed her career from law to library science. Unfortunately she ended up teaching library patrons how to do basic tasks on the library computer all day, so she switched back to law.
I understand how she feels. Last time I was in the UPS Store, trying to send a package, the sole counter attendant spent all her time showing a slightly older person how to send an email. This included checking his SENT folder and COPYING himself. What normally took 5 minutes took 20. The librarian now teaches basic computer science rather than the Dewey Decimal System. Who knows Dewey anymore?
I have found that a dedicated writer can reverse the trend of users not reading the documentation—given a few years, a few product release cycles, and a platform.
When I started working on After Effects Help for Adobe, nearly everyone said that no one read the manual. Now, after a few years of embedding myself with the engineering team, directing users to online Help through my blog and forums, and generally refusing to accept that assessment, I can say that people do read the manual.
My point is that we as technical writers have to advocate for ourselves and our work. We must point people to the documents for the answers to their questions. And we we must keep doing it until people get the message. If we just write something and then hope passively that someone reads it, we’re doomed.
Todd, I agree that a good manual for After Effects is probably something a lot of people read. It’s interesting that you mention After Effects. I was trying to get a copy of After Effects for screencasting, and offered to trade a year of advertising space in my sidebar for a copy. But I never got found the right person. You wouldn’t be able to pull any strings for me, would you?
Tom
Anna, I’m not entirely sure I understand your question. Are you asking why people bother to write manuals when most users feel the manual is a waste of time? It’s true that generally people dislike manuals. At the same time, people dislike lack of a manual even more. Probably at the heart of the matter is the user’s discomfort in learning. Learning something new takes a person out of his or her comfort zone, requires too many neurons to fire in their brain, and overall represents work.
Some people may read manuals, but, quite frankly, no one wants to (except a few tech writers who are likely critiquing the manual and spotting errors so they can later report them to the publisher — lol).
Here’s some recent data to add to the discussion. It’s not a big group nor is it an academic study, but in a show of hands at the Intelligent Content Conference this past week in Palm Springs, these numbers held true (give or take a percentage point or so).
64% men / 24% women don’t read manual w/computer before calling support. You’d be surprised how many who did call in, had failed to turn the device on or plug in it. Give it a read.
Report: http://bit.ly/byQsY0
I think I’ve seen this study before (see this comment here). But surely whether someone reads the manual depends a lot on the program and the user group. For general tech gear you buy at Best Buy, the user’s patience is probably a lot thinner than a specialty program that you need to use at your job.
By the way, it’s interesting to see this thread start up again. It was dormant for at least a month until yesterday.
It is kind of an underground joke around my company that while my guides and manuals are required — and everyone says they’re great — no one reads them. No one wants to read them, either. They are contractually obligated to be delivered, but they rather like phone books. You never open your phone book until you really need to.
I find that perspective comforting when I’m not 100% proud of the help.
I am proud of the guide I write and what I accomplish as a Lone Technical Writer.
But let’s face it. No one reads the manual or guide unless they MUST. It is a fact of life.
I write guides for that one user who has a problem in the wee hours and needs a solution NOW. That’s the person I’m aiming for.
We such as this site presented and this has provided myself some sort of inspiration to succeed for some reason, so thank you.
Today while searching for content on the University document. I simply wanted to state nice article and good ability as a copywriter. I really hope to be of the same quality one day. Thanks
Pingback: Principles for Organizing Print Material [Organizing Content #21] | I'd Rather Be Writing