Today’s readings on technical documents were a constant reminder of how much I dread reading technical instructions. I will admit I usually take a stab at a product and if necessary then consult the technical document only to find myself more frustrated. So the idea of learning about these is a little enthralling, a little… Once again we refer back to many of our readings of how important it is to cater to your audience. If you don’t put yourself in their shoes, your document is probably only really catered to you and ultimately sucks like most technical documents.
Reading the instructors blog made me feel a little better about myself. I was glad to hear that someone else out there agrees I’m not a complete idiot just because I’m not an engineer who can magically assemble things right out of the box with horribly written instructions that ultimately lead me to bang my head on the wall and deal with horrible customer service (a whole other problem in the industry). Leading myself and others on to feel like a complete idiot is downright frustrating! As chapter 19 states anyone who writes these sorts of documents needs to think of what your readers need to know, how they will use that information, and the contexts in which they will use it. Context! If I’m trying to assemble something, please tell me where these different holes I’m supposed to be putting the bolt into are. Not just screw the continuum transfunctioner (Dude Where’s my car) into the flux capacitor! Ohh, and by the way, please tell me what the heck these parts are! Maybe a diagram might help, preferably a diagram that matches the actual up to date parts. I can’t think of how many times I’ve come upon an assembly document that contains what appears to be a previous older model of a product! Assume we’re all novices and appropriately write your document that way. I don’t believe there’s such a thing as too much information in a technical document. If it’s documented correctly (appendices, diagrams, table of contents, etc) the information you want can be found quickly and the information you don’t want (probably already know) can easily be skipped over.
So all in all, treat me as a novice you ohh so lovable technical document writers, I won’t be offended. I’ll actually really appreciate the change! Give me tables, figures (that are actually accurate and readable), appendices, table of contents, references, definitions, etc. Consider what the heck I might be using this document for and take in all of those accounts. If it’s not appropriate for these set of instructions at least point me in the right direction, just not customer service please! I hope someone here might one day write technical documents and start a revolution to turn me away from this constant frustration!
User-centered approach
You're right about instructions. I'm just repeating Instructor Blog #4, but why would you want to make the person you are instructing feel stupid - especially if it's your product you are trying to explain?
I think the approach to instructions-writing that treats uninformed users as idiots is downright idiotic. I like the oil-changing example. The process-centered logic suggests that the user who doesn't understand is stupid. But really, changing the oil is one of the most basic things you can do to a car other than fuel up. So if you are experienced enough to be able to recognize parts of the engine without any help, would you really need instructions for changing your oil? I doubt it. Whoever made those instructions clearly ignored the need to understand the needs of your audience on the most basic level: Would an expert need instructions? No! So why cater your instructions to an expert?
In your example, though, forget about identifying the audience, it sounds like you just had some bad instructions.
I like your style
I'm in total agreement with your arguments concerning the ease of use, or lack there of, of instructional documents. There certainly is a grey area that should be kept in mind when creating these works with the novice user in mind, as seen in countless, often ridiculous products on the market today, but for the most part I think almost everyone (including engineers!$@) don't enjoy wasting unnecessary amounts of time assembling a finished product. I, as well, enjoy simple pictures and diagrams to make the experience as "enjoyable" as possible. I think if technical writers keep this in mind, which is essentially the user-centered approach, then they will end up creating instructional documents that are much more to the pleasing of the specific audience.
Usabilty testing
By reading your response, I think we both have looked at the exact same set of instruction documents at one point in time. I’m talking about the same inadequate written instructions that are unclear, lacking helpful diagrams and important context. In addition, forgetting to crater to a specific audience. Why would a company want to do this?
It’s vital while writing the instruction documents not to make your customers feel like an idiot. In my experience I tend to see more problems with instructions booklets relating to “real world experience”. Referring to Instructor Blog #4 on the dog crate example, it’s frustrating to not be able to relay the instruction context to the product. I can not count the number of times this has happen to me. The usability testing is an essential process as well in creating technical instructions.
Thinking on the same level
It seems all instructions manuals are worthless. I have always wondered if they are so excited to finally have something to sell that they write the instruction manual while driving to bank on Friday to cash their checks, or if they just don’t care because they know most people don’t read them. My favorite is when you are putting something together that has a lot of bolt, nuts, washer, etc, and they use dashed lines to tell you what all goes together. They always seem to pick the perfect angle to maximize the amount of parallel lines crossing each other. This also stresses the importance of usability tests, sometimes when you’ve been a design engineer for 20+ years it’s hard to bring yourself down to the level of a normal person. I think a lot college professors fall into this category, especially engineering. I think that’s why it is so much easier to learn from friends or a TA.
The infamous dashed lines
I hate those darned dashed lines! I too feel like they purposely place them to make them near impossible to interpret. I always find myself trying to visualize the product thinking, 'OK, so this line goes to the back, or wait does it go to the front side!' You are absolutely right about usability testing. They need to test these out with people who don’t have anywhere near the mindset of whoever created these products and documents. This way it’s totally unbiased, and the common idiot like me I guess, can figure these out. Like the reading outlined, it’s sometimes hard put yourself in a previous mindset in order to understand your audience. This is the point where you need to bring in other subjects to test your work.
test on audience first
I like your comment about companies being more concerned with getting their product to market rather than customer satisfaction. The company probably writes the instructions, checks it for errors and calls it good. I doubt that most instructions are even evaluated by a third party or by a focus group. If focus groups were used to check instructions before the product went to market, companies could cut back on lackluster manuals. However, this is probably rarely done because of the cost and time it would take. Like you said, they are more concerned about turning a profit. Maybe they should consider returning customers, or lack thereof.
New Model, Same Manual
I also hate it when companies release a new version or model of a product and then assume the old user manual will provide enough information to still complete the task. I've run into this countless times, and it just creates unneeded frustration. Even though technical documents like extensive user manuals are expensive and time consuming to create, a good manual can create a good "interaction" with the user of the manual, and can actually add value to your product. For example, a user setting up a home DVR system for the first time, if the instructions provided are clear and he is easily able to set it up, he could recommend your companies' DVR over another companies' simply because of the ease of use.
The Dreaded Instructions
Instruction manuals can be a real hit or miss. It normally seems that instructions assume that you already know everything about the product or you know nothing about it at all. This has led to countless times where I have been frustrated to the point where I have had to call the dreaded customer service. If the companies who had made these instructions had followed all of the guidelines set forth in the reading I would not have had this issue. Just once, I would like to get done putting something together and go man what a great set of instructions.
Good product & Good manual = Great Product
I think this is why its so important to write instructions in a useful and helpful way. If the instructions don't do a good job explaining what to do people are only going to get frustrated. I know many people wouldn't bother with customer service depending on what it is they bought. Its almost easier to just return the product than to talk to many customer service places. I agree that if a good product came with a good manual I think you've just created a great product.
-Chris
I hear you!
I certainly understand where you're coming from. I couldn't believe it when I tried to put together an entertainment unit that the instructions consisted of four pictures when the box had five different screws and multiple brackets. At least the eight steps to put it together were printed in five languages (very helpful use of space). I find it so frustrating that manufacturers never consider their audience when creating instructions.
The readings from the employment project will really help me to complete these instructions. By using the 5 W's like is says to in Chapter 20, I will put myself in the shoes of those who will actually be reading the instructions I'm writing.
Mike Sheridan
Perfect Articulation
Matt here has perfectly articulated the reasons Jeremy and I caution against the idiot approach. The idiot approach, while making the expert feel better, runs the risk of alienated (or worse, harming) the earnest but novice user attempting to learn new technology or a new process.