Textbooks and popular treatments of HCI usually touch on learnability. The learnability of a system includes two important parts: how easily new users can learn to carry out common tasks and, once a task has been learned, how easily users can improve their performance.

There are obvious differences between software environments and the real world, and these show up in learning. For example, last year during an extended stay in California I learned how to skate with inline skates. (I can now manage to stay upright most of the time, though I'm far from being good.) My first step was putting on the equipment. Lacing up the skates was surprisingly complicated, because the eyelets are in an unusual pattern. It took some experimentation to figure it out: "Is this right? No, the ends aren't long enough to reach these holes. . ." In contrast, the latches that help hold my ankles in place were straightforward. By working the latches back and forth, it's easy to see how they fasten, even if they are unfamiliar at first. My wrist guards were another story. These are open-fingered gloves holding a piece of curved metal to protect my hands if I fall. I first put them on the wrong way, so that my wrists were bent slightly forward, not realizing that force on my palm would have bad consequences for the rest of my hand. Because it was difficult to move my wrists around naturally with the gloves on backwards, I was able to notice and correct my mistake. My students offer similar examples, though sometimes with less clear resolution:

I have a bucket in my dorm room to hold laundry supplies. The lid looks like any other lid, except that to take it off, you first have to fold the edge outward and upward to unlock it. There are instructions on the lid, but they're so small you can't really see them. If someone is ever with me when I need to get something from the bucket, I ask them if they'll open it for me. Hardly anyone figures it out. When they give up, I show them how it works.

Several HCI concepts can play into an explanation of equipment use: affordances, constraints, and forgiveness, to name a few. What about the learning process, beyond the starting point? In learning to skate, I watched other (much younger) people skating around me and tried to match their general movements. Once in a while I asked someone's advice. I practiced simple techniques until they became second nature, and I found that simple actions sometimes led directly to more complicated ones.

Contrast my experience to learning a new software application. I'm usually alone in my office. Sometimes I can ask my colleagues questions, though I rarely do. Like most people, I hate to read instruction manuals. A final difference is that practice, by itself, is much less effective for learning in software environments than it is in the real world. That is, while I can learn to recognize icons and find menu items more quickly, my increased familiarity with some sequence of actions doesn't usually open me up to new possibilities unless I deliberately start experimenting.

When my students recount examples of poor design in the real world, these rarely have to do with physical, continuous learning experiences like skating. More often, the examples describe cases where step-by-step prescriptions go wrong, especially when technology is integrated awkwardly into a task.

At my job in a department store, you first pay for large items at the register and then you pick them up in a delivery area. In the delivery area, there's a machine that scans your receipt, asks you a few questions ("Is this your order?"), and then sends a message to the warehouse for the right items to be brought out. It's dead easy. Customers find it annoying, though, mainly because they don't take the time to read the instructions about what they need to do.

The difference between learning to skate and learning to use an unfamilar computer system can be described in terms of what Lucy Suchman has called "situated action". The basic idea is that if we try to understand a task in some abstract form (in the extreme, someone might ask, "How much--or rather, how little--would a robot need to know to execute this task?") we can easily lose sight of context that makes the task hard or easy for people to carry out. Our activities are usually situated in some context: the context of a specific physical situation or locale, a more general work context, a social context, a play context, and so forth. Context influences our actions, sometimes much more than decision making in the abstract might.

How can these ideas influence interface design? No detailed design guidelines have come out of this work, but the message that designers should be sensitive to context is clear. Consider the receipt-scanning example: After having paid for some item (a social interaction with the cashier), a customer arrives at a warehouse entryway with an unfamilar computer standing in the corner. I'm always a bit nervous about using "someone else's" computer, even if it's a public kiosk, and I doubt I'm alone in this. We might improve the interaction by thinking about how people learn new activities, even an activity like skating. We might imagine customers watching a looped video or a sequence of signs with pictures that demonstrates the process (just as I watched other skaters). Customers might use a telephone handset or microphone, connected to a simple voice recognition system, to ask questions about the process (just as I asked advice of others). If other customers were going through the same process, they could watch each other. None of these solutions can completely replace a human to handle problems, just as having a human trainer is usually best for learning, but their concessions to context should help.