After finishing this week’s readings, I had a hard time trying to figure out the real importance of Chapter 19 about technical descriptions in relation to instructions. It came to me that instructions are really descriptions of a process. Even with this I think Chapter 20 did a great job of underlining steps and process for good instructional writing. One thing Chapter 20 mentioned to do is to provide feedback throughout the process to ensure the reader they are doing everything correctly. It really bothers me to be putting something together and think “I guess that’s how it’s supposed to look,” and ends with me realizing it was wrong and then having to go back and fix it. I know when I do a long homework problem that I will stop halfway through to check it before I keep compounding on my mistakes.
I also think the instructor blog did a great job of pointing out where most instructions fail and things to avoid, especially the mistake of assuming your reader is an idiot. I think this is exemplified in the troubleshooting section of manuals. How many people have looked at the troubleshooting guide for a stereo? It normally describes a problem, such as no sound from the speakers, and some earth shattering way to fix, like turn up the volume, make sure the unit is plugged in, and make sure it is turned on. Do we really need to consider them that novice? Personally I would like two sets of instructions, one for a novice, and one for someone with more experience. I have noticed this somewhat when installing software; many times you will have to option to custom install (experts only), or the general install (recommended for most users). With internet and technology it shouldn’t be too hard to simply post two sets on the web for all users. I have even struggled reading some instructions that are overly simple, it’s almost like I need to turn off my brain and just follow them word for word. I don’t mean to come off like I know everything and don’t struggle with tasks because trust me I do, but sometimes it seems like it’s faster and less of a pain to just wing it.
Heavy instruction booklets scare people away..
I agree with what you said in the first paragraph about providing feedback throughout the ‘put-together’ process so the user knows what it is supposed to look like. One problem with that is the fact that adding pictures or other forms of feedback to ensure a proper process also adds girth to the instructions. This effect was one of the problems discussed in the readings about how instruction booklets that seem thick and large are often daunting even before they are opened. It seems there is a fine balance between effective instructions and too much information.
Dumbing Down
I think you made some really interesting points in your second paragraph, concerning the dangers of treating the user as if he or she is an idiot. I have also experienced several instances of trouble shooting, especially with electronics, in the past where I've been asked the dumbest, most obvious questions like "is the modem turned on?" or "have you inserted the cd?". It can really be stressful, and sometimes I've gone through entire troubleshooting runs without anything other the simplest, most common sense questions being asked. I agree that in some instances the creator gets it just right, as in the instance of installing certain programs (as you mentioned), and this is certainly relieving. I think that a similar strategy, involving possibly multiple difficulty level instructions or troubleshooting guides, could possibly prove worthwhile for other applications as well.
Two Sets of Instructions
I think your idea of having two set of instructions would be very beneficial. All of our readings warned against writing as though your reader is an idiot but what if some of the readers truly are idiots? It would be nice if we did not have to worry about this but I am sure almost all of us know of at least one person who never ceases to amaze us with what they are incapable of doing. By having two set of instructions, both the idiots and the regular users will be catered to. Another benefit of this would be if a person was not an idiot but just entirely unfamiliar with a process in the instructions. The dumbed down version of the instructions would allow them to seek further clarification without having to call technical support.
Avoiding "The Idiot Approach"
One of the reasons that we caution against the "idiot" approach is because your documents, beyond conveying information, create users as users. That is, how a user operates the technology or approach a task is structured, in part, by the instructions themselves. For example, how you work as a writer is being structured by the advice and feedback that Jeremy and I offer you: we are shaping you as writers just as technical writers shape individuals as users. All this is to say that you are responsible (and, to a certain extent, liable) for how users behave in accordance with the instructions you have created.
I would call your attention to Matt's post, as it nicely encapsulates why we preach against this approach.