OUR BRAIN REWIRES ITSELF CONSTANTLY
How does the brain learn? Recent brain research has found that the brain adapts to new situations and environmental requirements constantly, mainly by rewiring itself: neurons that formerly fired independently become connected and fire in concert or in opposition, and neurons that formerly participated in one perception or behavior are reused for others. This is known as brain plasticity (Doidge, 2007).
It has been known for over 40 years that infants’ brains are highly plastic: within months of birth, somewhat random collections of neurons develop into highly organized neural networks. However, the degree to which brains remain plastic—that is, reorganizable—into adulthood was unknown until nuclear magnetic resonance imagery (NMRI) and similar brain observation methods became available.
One dramatic example of brain plasticity is the fact that blind people can be taught to “see” by connecting a video camera to an array of tactile stimulators resting on the person’s back. The stimulators touch the person’s back in patterns corresponding to images captured by the camera, vibrating for dark areas of the image but not for light areas. With training, participants in these studies can read, perceive scenes in three dimensions, and recognize objects. Initially, they perceive the stimulation as tactile patterns on their back, but after a while they report it as actually “seeing.”
Brain plasticity is also exemplified by a new approach to stroke rehabilitation. People who have strokes sometimes lose the use of an arm or leg on one side of their body. Recovering use of the limb has traditionally been difficult—often impossible—and stroke victims often learn to compensate by ignoring their bad limbs and relying on their good ones. However, some stroke doctors have recently started placing patients’ good limbs in casts to immobilize them, literally forcing patients to use their bad limbs. Results have been positive. Apparently, the brain reassigns different neurons to the bad arm—for example, allowing it to function again (Doidge, 2007).
The first time or even the first several times we perform an activity, we do it in a highly controlled and conscious manner, but with practice it becomes more automatic. Examples include peeling an apple, driving a car, juggling balls, riding a bicycle, reading, playing a musical instrument, and using an app on your mobile phone. Even an activity that might seem to require our attention, such as sorting good cherries from bad ones, can become automated to the point that we can do it as a background task, with plenty of cognitive resources left over for having a conversation, watching the news on television, etc.
This progression from controlled to automatic raises an obvious question for designers of interactive applications, online services, and electronic appliances: How can we design them so that using them becomes automatic within a reasonable amount of time?
This chapter explains and demonstrates factors that affect how quickly people can learn to use interactive systems. To preview the factors, we learn faster when:
- Practice is frequent, regular, and precise.
- Operation is task focused, simple, and consistent.
- Vocabulary is task focused, familiar, and consistent.
- Risk is low.
We Learn Faster When Practice Is Frequent, Regular, and Precise
Obviously, practice facilitates learning. Here are some details about practice.
Frequency of Practice
If people use an interactive system only rarely—for example, once every few weeks or less—it is hard for them to remember from one time to the next the details of how to use it. However, if they use an interactive system frequently, familiarity develops quickly. Most user-interface designers are well aware of this, and therefore design applications, appliances, and online service differently depending on whether people will use them casually and rarely or intensively and often.
For example, automated teller machines (ATMs) for banks are designed under the assumption that people will not remember much from one usage to the next. They are designed to be simple and to remind people what they do and how they work. ATMs present a short list of anticipated user goals—for example, withdraw cash, deposit funds, transfer funds—then guide users through the steps of the selected task. Airline and hotel booking Web sites are similarly task oriented: “Tell me your goal and I’ll guide you to it.” In contrast, document editing applications, electronic calendars, smartphone texting apps, air-traffic control systems, and online accounting services are designed with the understanding that people will be using them daily—perhaps even minute-by-minute—and will quickly learn and remember details about how to use them.
Regularity of Practice
How long does it take for an activity to become an automatic habit? Lally and her colleagues conducted a study to measure this (Lally et al., 2010). They asked about 100 volunteer participants to choose a new eating, drinking, or physical activity to do every day for at least two months. They monitored the participants and measured how long it took for the new behavior to become automatic—that is, to be executed without conscious thought or effort.
They found that forming automatic habits takes from 18 to 254 days, with more complex activities taking more time. They also found that habits formed faster if practiced regularly—for example, daily. Skipping a practice session now and then didn’t make much difference, but skipping a lot of practice sessions significantly slowed participants’ progress toward habit formation.
Bottom line: If you want the use of your software to become habitual and automatic for users, design it so as to encourage people to use it regularly.
Precision of Practice
Unorganized collections of neurons are noisy: they fire randomly; not in an organized way. When people practice an activity repeatedly, the brain organizes itself to support and control that activity: networks of neurons get trained up to fire in concert. Their firing becomes more systematic and less noisy. This is true regardless of whether the activity is perceptual like identifying a word, motor like skiing, cognitive like counting numbers, or a combination like singing a song.
The more carefully and precisely a person practices an activity, the more systematic and predictable the activation of the corresponding neural network. If a person practices an activity carelessly and sloppily, the supporting neural networks remain somewhat disorganized—that is, noisy—and the execution of the activity will remain sloppy and imprecise (Doidge, 2007).
Stated simply: Practicing the same activity imprecisely just strengthens the imprecision, because the neural networks controlling it remain noisy. To train the neural networks to make the activity precise, one must practice precisely and carefully, even if that requires practicing slowly at first or breaking down the activity into parts.
If efficiency and precision are important for a task, design the supporting software and its documentation to (1) help people be precise—for example, by providing guides and grids—and (2) encourage people to use it purposefully and carefully rather than absentmindedly and sloppily. The following section explains how providing users with a clear conceptual model can support (2). Consistency of keystrokes and gestures, discussed later in this chapter, is also important.
We Learn Faster When Operation Is Task Focused, Simple, and Consistent
When we use a tool—whether it is computer based or not—to do a task, we have to translate what we want to do into the operations provided by the tool. Some examples:
- You are an astronomer. You want to point your telescope at the star Alpha Centauri. Most telescopes don’t let you specify a star to observe. Instead, you have to translate that goal into how the telescope’s positioning controls operate: in terms of a vertical angle (azimuth) and a horizontal angle, or perhaps even the difference between where the telescope is pointing now and where you want it to point.
- You want to call someone who isn’t in your phone’s contact list. To call this person, you have to translate the person into a telephone number and give that to the phone.
- You want to create an organization chart for your company using a generic drawing program. To indicate organizations, suborganizations, and their managers, you have to draw boxes, label them with organization and manager names, and connect them with lines.
- You want to make a two-sided copy of a two-sided document, but the copier only makes single-sided copies. To make your copy, you must first copy one side of each document sheet, take those copies and put them back into the copier’s paper tray upside down, and then copy the other side of each document sheet.
Cognitive psychologists call the gap between what a tool user wants and the operations the tool provides “the gulf of execution” (Norman and Draper, 1986). A person using a tool must expend cognitive effort to translate what he or she wants into a plan based on the tool’s available operations and vice versa. That cognitive effort pulls the person’s attention away from the task and refocuses it on the requirements of the tool. The smaller the gulf between the operations that a tool provides and what its users want to do, the less the users need to think about the tool and the more they can concentrate on their task. As a result, the tool becomes automatic more quickly.
The way to reduce the gulf is to design the tool to provide operations that match what users are trying to do. To build on the preceding examples:
- A telescope’s control system could have a database of celestial objects, so users could simply indicate which object they want to observe, perhaps by pointing to it on a display.
- Telephones with contact lists allow users to simply specify the person or organization they want to call, rather than having to translate that to a number first.
- A special-purpose organization chart editing application would let users simply enter the names of organizations and managers, freeing users from having to create boxes and connect them.
- A copier that can make double-sided copies allows users who want such copies to simply choose that option on the copier’s control panel.
To design software, services, and appliances to provide operations matching users’ goals and tasks, designers must thoroughly understand the user goals and tasks the tool is intended to support. Gaining that understanding requires three steps:
- Perform a task analysis.
- Design a task-focused conceptual model, consisting mainly of an objects/actions analysis.
- Design a user interface based strictly on the task analysis and conceptual model.
Describing in detail how to analyze users’ goals and tasks is beyond the scope of this book. Entire chapters—even whole books—have been written about it (Beyer and Holtzblatt, 1997; Hackos and Redish, 1998; Johnson, 2007). For now, it is enough to say that a good task analysis answers these questions:
- What goals do users want to achieve by using the application?
- What set of human tasks is the application intended to support?
- Which tasks are common, and which ones are rare?
- Which tasks are most important, and which ones are least important?
- What are the steps of each task?
- What are the result and output of each task?
- Where does the information for each task come from?
- How is the information that results from each task used?
- Which people do which tasks?
- What tools are used to do each task?
- What problems do people have performing each task? What sorts of mistakes are common? What causes them? How damaging are mistakes?
- What terminology do people who do these tasks use?
- What communication with other people is required to do the tasks?
- How are different tasks related?
Once these questions are answered—by observing and/or interviewing people who do the tasks that the tool supports—the next step is not to start sketching possible user interfaces. The next step is to design a conceptual model for the tool that focuses on the users’ tasks and goals (Johnson and Henderson, 2002, 2011, 2013).
A conceptual model of an application is the one that the designers want users to understand. By using the application, talking with other users, and reading the documentation, users build a model in their minds of how to use it. Hopefully, the model that users build in their minds is close to the one the designers intended. That is more likely when designers explicitly design a clear conceptual model as a key part of their development process.
A conceptual model describes abstractly what tasks a user can perform with the system and what concepts they must be aware of to complete them. The concepts should be those that came out of the task analysis, so the conceptual model is focused on the task domain. It should include few, if any, concepts for users to master that are not in the target task domain. The more direct the mapping between the application’s concepts and those of the tasks it is intended to support, the less translating users will have to do, and the easier the tool will be to learn.
In addition to being focused on users’ tasks, a conceptual model should be as simple as possible. Simpler means fewer concepts. The fewer concepts a model has for users to master, the better, as long as it provides the required functionality. Less is more, as long as what is there fits well with users’ goals and tasks.
- In a to-do list application, do users need to be able to assign priorities of 1 to 10 to items, or are two priority levels, low and high, enough?
- Does a Search function need to allow users to enter full Boolean expressions? If it allowed that, would a significant number of people use it? If not, leave it out.
- Does a ticket machine in a train station need to be able to offer tickets for train routes other than the routes that this station is on?
In most development efforts, there is pressure to add extra functionality in case a user might want it. Resist such pressure unless there is considerable evidence that a significant number of potential customers and users really need the extra functionality. Why? Because every extra concept increases the complexity of the software. It is one more thing users have to learn. But actually it is not just one more thing. Each concept in an application interacts with most of the other concepts, and those interactions result in more complexity. Therefore, as concepts are added to an application, the application’s complexity grows not just linearly, but multiplicatively.
For a more comprehensive discussion of conceptual models, including some of the difficulties that arise in trying to keep them simple and task focused while providing the required functionality and flexibility, see Johnson and Henderson (2002, 2011, 2013).
After you have designed a conceptual model that is task focused, as simple as possible, and as consistent as possible, you can design a user interface for it that minimizes the time and experience required for using the application to become automatic.