Chapter 10 contrasted the "automatic" processes that our brain uses to carry out well-learned activities with the conscious, highly monitored, controlled processes that we use to solve novel problems and perform calculations. Automatic processes consume little or no short-term memory (attention) resources and can operate in parallel with each other, while controlled processes place high demands on short-term memory and operate one at a time (Schneider & Shiffrin, 1977).

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 and more automatic. Examples include peeling an apple, driving a car, juggling balls, riding a bicycle, reading, playing a musical instrument. 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 under the following conditions:

Operation is task-focused, simple, and consistent

Vocabulary is task-focused, familiar, and consistent

Risk is low

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:

Imagine that you are an astronomer. You want to point your telescope at the star Alpha Centauri. Most telescopes don't let you just specify what star you want 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.

Assume you have a telephone that doesn't have speed dial. To call a 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.

Cognitive psychologists call the gap between what a tool user wants and the operations the tool provides "the gulf of execution" (Norman & Draper, 1986). A person using a tool must expend cognitive effort to translate what she wants into the tool's available operations and vice versa. That cognitive effort pulls the person's attention away from her 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 examples above:

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 speed dial 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.

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:

This is a very interesting topic. A lot of psychology and human factors go in to this.
The introduced technics must be just a slice of what the hole book has to offer since I bet there's some craftmanship involved when designing UI and that is in touch with the creative side of the designer. I wonder who the best designers are and where are they? Apple?
Though UI isn't just of looks and feels but also related with functionality and operability... that's not artistry... Looks like technology and art, psychology and science melt together in the design of User interfaces... cool don't you think?!