The prevailing notion about instructions is that they are superfluous, and only for those who are unable to understand how to use a particular item or complete a certain process. Often, users won't read instructions at all. For example, Jim Gee argues in his book What Video Games Have to Teach Us About Learning and Literacy that successful video games teach people how to play as they are playing. After all, few people crack open their copy of Halo III or Shadow of the Colossus and read the instruction manual first thing (although I do). Most people pop the game into the console, and then later consult the manual if they have problems.

Instructions get a bad rap for a reason. Many of the stereotypes about them are accurate—they are often confusing and difficult to use. Instructions are frequently poor because they are systems-centered—that is, they are focused on the item or process and not the audience. Instructions that suit the audience's needs, values, and attitudes are going to be much more useful than those that don't. That is why we're doing usability testing in this project, so we can get an idea of how actual users will work with our documents.

Instructions often have one or more of these problems, all of which you should avoid in your projects:

Problem 1:

Instructions do not account for audience. As mentioned above, many instructions take no actual account of who will use them. Recently, my friend Ryan tried to change the oil in a 1986 Plymouth Reliant using instructions that asked him to locate the oil drain plug. Ryan doesn't know much about cars, and didn't automatically know what a drain plug looks like. Unfortunately, there was little in the manual to identify what the drain plug was, what it looked like, or where it was located. (Also, the instructions referred to the part as the oil drain plug, the drain plug, and the plug at different points, which is confusing. The document should have chosen one term and stuck with it to build up consistency.) Ryan ended up loosening many things underneath the car before he found the drain plug. He eventually accomplished the step, but it was time-consuming and exasperating, which of course established a negative frame for his relationship with the instructions for the rest of the process.

The difference between systems-centered and user-centered instructions may be identified in the varying reactions to this story. A systems-centered perspective would hear the story and say: "The process is described correctly, so Ryan must be flawed. He must not have the necessary skills to complete the task." Alternately, a user-centered perspective would state: "The process was much more difficult than it needed to be, so the instructions are flawed. They do not present the material as effectively as they might." That's the difference, and it's crucial. User-centered directions, which are the kind you will be creating, focus on the audience's interaction with the task rather than only the task itself.

To generate user-centered directions, you will want to consider several aspects of your audience groups:

• What are audience expectations? Good directions know how an audience will approach the task. When you get a video game, you are excited to play, so the directions should be aware that this is a fun activity but that it may frustrate some users because, for example, game controllers can be exceedingly complex and contain numerous buttons. Directions also should be aware of genre. People who purchase Halo III or Shadow of the Colossus are a different audience than those that buy Wii Sports or Guitar Hero, and the instructions should suit the audience accordingly. (Indeed, how many of you reading this have no idea what I'm talking about here; just like Ryan, we're all novices at something.) Instructions for changing car oil should account for the fact that the audience is probably dreading the task, a little confused by it, and performing it while underneath an automobile. After all, people who have mastered changing their oil almost certainly are not going to require instructions. Nevertheless, one of the most important things to understand is that often instructions have mixed audiences, but no writing is ever "for anybody." The "general audience" is a myth. Make sure to analyze your audience, context, and purpose and produce a corresponding document.
  
  
• What do audience members already know, and what do they need to know? It's safe to assume that people changing a car's oil already know a little about cars. They probably know that oil is important to the vehicle's function, and they probably know it should be changed periodically. It is likely that they have had their oil changed at a service station, and know about how long the process should take. They won't necessarily know that you need a new oil filter and oil wrench, how to pick out appropriate oil, where the oil drain plug is, how to dispose of the old oil, etc. They also need to know safety warnings about being careful under a car. They don't really need to know how oil works in relation to the overall car system, or how oil is made. So as you're writing instructions, think carefully: What do my audience members already know? What do they need to know? What doesn't matter to them? Many experts who are writing instructions know much more about the topic than the audience, but much of that information is not important for instructions because it's not necessary to the task. Much of the information experts take for granted is vitally important to the task and must be included. You will have to put yourself in the audience's shoes and determine what is necessary and what is not. This is harder than you might think. Chip and Dan Heath discuss something they call the "curse of knowledge" in their book Made to Stick. They state: "Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has 'cursed' us. And it becomes difficult for us to share our knowledge with others, because we can't readily re-create our listeners' state of mind" (20). Importantly, our audience isn't stupid or deficient because they aren't familiar with an item or process that we take for granted. For example, it would be improper for me to view students as flawed because they have not mastered something that I have yet to teach them. Similarly, you will have specialized knowledge that your audience members do not have, but they are not deficient because of this. Rather, it is your task to communicate your knowledge to this audience. In a very real way, if they fail in their task, it is as much your fault as it is theirs—just as if a student does poorly in this class, it is as much my fault as it is the student's.

Problem 2:

Instructions do not match real-world experience. Recently my friend Anna (who is married to Ryan) was trying to assemble a fabric dog crate. The crate comes flat in the package and has to be expanded by bending metal bars that snap together to create a frame for the crate. The instructions show that you simply grab the bars, pull them up, and snap them together, and presto, it's done. The problem is that this action looks effortless on the directions but requires a great deal of force in real life, so much so that Anna thought she was doing something wrong or that the crate was improperly manufactured. Eventually, she was able to get the bars together, but it was an unnecessary ordeal. The instructions should match as closely as possible the real world actions of the user. If they don't, users will get confused and angry. Usability testing is one of the best ways to ensure a close connection between instructions and actions.

Problem 3:

Instructions are unappealing and obfuscating. Many people don't read instructions because they're so visually unappealing or intimidating that they don't want to bother with them. These online instructions covering how to solve a Rubik's Cube are monstrous. They are almost impossible to read because of the background and text colors. They are not placed into any kind of ordered sequence—everything is just thrown together in a big mess. They include no diagrams, which are vital to solving the Rubik's Cube puzzle (unless you are Will Smith). In short, it is very unlikely that anyone will use these instructions. People would rather labor on without help than consult something that seems aggressively unapproachable.

So many instructions are this way. They are filled with text that is daunting to the eye. They are full of technical jargon that intimidates the reader. They are not broken up in a logical sequence that is easy to follow. They include no pictures or graphics to aid the reader. They are not cleanly designed in a way that guides the eye. I expect your instructions to be well designed. The ultimate test of good design in instructions is that users want to use them and find them easy to use. One of the better instruction sets I have seen is also one of the silliest: the safety warnings for a dryer featuring a cartoon sketch of a talking appliance telling readers not to let "birds or other critters nest in my vents!" This document is silly, but it catches the eye and promotes comprehension (I obviously still remember what it told me years later). I'm not advocating that all your instructions include cartoon talking appliances, but they should make users want to read them. They should make their information "sticky." If users don't want to read your instructions, they won't, and they will be useless.

To assist with your design process, you will analyze existing instructions sets to get a better sense of what works well and what does not. Also, you will read material about design principles. It's important to remember that design is choice. If you don't cater your format, font, document dimensions and length, etc. to your specific needs, you are letting defaults make your design decisions, which is not user-centered.

A few other quick notes on the project:

Multimedia Elements: Please don't be worried about incorporating multimedia elements if you feel that you don't have the aesthetic or technical ability to do so. You are all savvy with figures, diagrams, images, audio, etc. by virtue of being part of contemporary American culture. Don't be intimidated by working with communicative elements that are not written words. Also, be aware that you are under no obligation to use any particular piece of hardware or software in the production of your instruction sets. Don't be afraid to keep things low-tech if that is more comfortable for you. If you feel better assembling your work with scissors, scotch tape, and a Xerox machine, then by all means do that. The design principles we cover are not tied to particular technologies. (Nevertheless, you should choose your topic in part based upon how technically capable you believe you are to produce appropriate instructions.)

Safety Warnings: Safety warnings are an important part of instructions, so make sure that you include them where necessary. For some of you, it will be life or death information about being careful under a car. For others, it will be cautions about not damaging your computer as you install new software. Whatever the case, safety labels have a tendency to be mocked in mainstream discourse. This article from CNN is a great example of that attitude. Sometimes product warnings are indeed ridiculous and treat users like idiots, which violates the tenets of a user-centered approach. However, they are an important inclusion for user safety and for legal reasons. Most warnings exist because somewhere, somehow, somebody did the thing the warning says not to do. I remember people making fun of the warning label on a Batman costume that said "Warning: Cape does not allow wearer to fly." But somewhere, some kid jumped off his parent's roof wearing the cape (which is doubly flawed, because Batman doesn't fly—at best he glides). Warnings are important for legal reasons, and lawyers and judges are a tertiary audience of instruction sets (and sometimes your company's legal council is a gatekeeper audience). In your own work, make sure to find the right balance between necessary and superfluous information when dealing with safety concerns.

Second Person: Although this instructor blog uses second person (you) frequently, avoid it in your instructions. Instead of saying "You should open the drain valve," just write "Open the drain valve." This seems minor, but it really cleans up the prose and makes things more readable, which is an important goal.

Good luck with the project. Contact me with any questions.