I have a lot of personal experience with reading and writing instructions. I do a lot of things with computers and I very often times have to read instructions on how to accomplish something. Often times, my friends ask me for help with their computer over the phone or IM and I have to give them instructions on how to fix their computer. This reminds me of a scene from the show The IT Crowd. You can watch the episode here:
http://www.channel4.com/video/the-it-crowd/series-1/episode-1/customer-s...
In that scene, the two IT guys are answering calls to help people with their computers. The show makes fun of how computer illiterate some people can be. In this case, Roy is explaining as simply as he can but the person on the other side has no idea what is going on. This part hints at the fact that no matter how good the instructions can be, some people are just incapable of following them. On the other hand, Moss is completely unable to relate to his audience. He speaks as if the person on the other side is an expert in computers – which is a very unrealistic expectation about people who call IT.
One conclusion is that instructions should be written for people who are capable of executing them. Some people feel overwhelmed and do not want to try to understand instructions. Even if you write very clear instructions, they probably won’t follow them. For those people the product or task should be designed in such a way so that it needs as little instructions as possible.
Another conclusion is that the one speaking or writing the instruction should put himself in the shoes of the audience. These are some questions instruction writers should ask themselves: Who is the audience? What does the audience know? What will the audience assume? What is the minimal amount that they need to know in order to accomplish their goals? Doo they understand the terminology in the instructions? Do the instructions look overwhelming?
Good example, but how does it connect with our readings?
I think my comment title gets at the jist of this post. You have provided a neat example of technical instructions in a real-life situation, but I would like to know more about how this example connects to this week's readings and our previous material (as the prompt requests). Can you point to specific elements in our readings that inform our understanding of the example you identify? Also, how does this example help us produce our own technical instructions?
I enjoy your example because
I enjoy your example because I have had some very similar experiences with dealing with people and providing voice instructions. Some of these ideas can certainly overflow into written instructions. It is so extremely important to provide different version of your instructions, one or more for each level of expertise, from novice to advance. The most important thing that should be taken away from this is that you cannot treat people as if they know any of the lingo or technical jargon in relation to what they will be working with. One must balance between ease of use and enough information.
www.JFlitt.com
Good Example
I think your video is a good example of how instructions are can be overcomplicated for a novice. Both men being experts in their field of IT; as the instructor’s blog says they are ‘cursed’. It becomes difficult for them to share their knowledge with others, because they can't readily re-create our listeners' state of mind". From watching I think that the two experts will have to rethink and reorganize how they can process their information to their “audience” (customers). The first person will have to slow down and not get frustrated. The second person, he will have to slow down his thought process and change some of his jargon to be able to relate to the novice.
Zebulon Rouse
What Not To Do
I think that your video accurately captured some perfect examples of how to not go about instructing others. While the first responder was dealing with a person who might be deemed an idiot (let’s be honest, who doesn’t know how to turn on a computer), he should have been more patient. The other person responded in a fashion that plagues many IT documents. He assumed that the person on the other end of the phone was familiar with the computer and quickly started drowning them in jargon. Just like if you use unexplained jargon in instructions, the person on the other end of the phone got frustrated and gave up.