Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 8
Definition
Requirements
Functional & data needs, user
Presentation
Document
Requir
Describe necessary
mental models, design imperatives,
User & Domain
User & Domain
capabilities of the
product vision, business
Analysis
Analysis
product
requirements, technology
Elements
Information, functions,
Check-ins
Define manifestations
mechanisms, actions, domain
Design
of information
object models
Framework
& functionality
Framework
Object relationships, conceptual
Design overall
groupings, navigation sequencing,
structure of user
principles & patterns, flow,
experience
sketches, storyboards
Design Framework
Key Path &
How the design fits into an ideal
Validation Scenarios
sequence of user behaviors, &
Describe how the
accommodates a variety of likely
persona interacts with
conditions
Presentation
the product
Design Vision
Detailed design
Appearance, idioms, interface,
Check-ins
Document
Refine & specify details
widgets, behavior, information,
Design
Form &
visualization, brand, experience,
Refinement
Design
Behavior
language, storyboards
Specification
Refinement
Design
Maintaining conceptual
Collaborative
Revision
modification
integrity of the design under
Design
Form &
Accommodate new
changing technology constraints
Behavior
Design
Support
constraints & timeline
Specification
Figure 1-6 A more detailed look at the Goal-Directed Design process.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 25
Chapter 1: Goal-Directed Design
25
Goals, not features, are the key to product success
Developers and marketers often use the language of features and functions to discuss products. This is only natural. Developers build software function by function, and a list of features is certainly one way to express a product’s value to potential customers (though this is clearly limiting, as well). The problem is that these are abstract concepts that only provide limited insight into how human beings can be effective and happy while using technology.
Reducing a product’s definition to a list of features and functions ignores the real opportunity — orchestrating technological capability to serve human needs and goals. Too often the features of our products are a patchwork of nifty technological innovations structured around a marketing requirements document or organization of the development team with too little attention paid to the overall user experience.
The successful interaction designer must maintain her focus on users’ goals amid the pressures and chaos of the product-development cycle. Although we discuss many other techniques and tools of interaction in this book, we always return to users’
goals. They are the bedrock upon which interaction design should be practiced.
The Goal-Directed process, with its clear rationale for design decisions, makes collaboration with developers and businesspeople easier, and ensures that the design in question isn’t guesswork, the whim of a creative mind, or just a reflection of the team members’ personal preferences.
DESIGN
Interaction design is not guesswork.
principle
Goal-Directed Design is a powerful tool for answering the most important questions that crop up during the definition and design of a digital product:
Who are my users?
What are my users trying to accomplish?
How do my users think about what they’re trying to accomplish?
What kind of experiences do my users find appealing and rewarding?
How should my product behave?
What form should my product take?
How will users interact with my product?
How can my product’s functions be most effectively organized?
How will my product introduce itself to first-time users?
05_084113 ch01.qxp 4/3/07 6:00 PM Page 26
26
Part I: Understanding Goal-Directed Design
How can my product put an understandable, appealing, and controllable face on technology?
How can my product deal with problems that users encounter?
How will my product help infrequent and inexperienced users understand how to accomplish their goals?
How can my product provide sufficient depth and power for expert users?
The remainder of this book is dedicated to answering these questions. We share tools tested by years of experience with hundreds of products that can help you identify key users of your products, understand them and their goals, and translate this understanding into effective and appealing design solutions.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 27
2
Implementation Models
and Mental Models
The computer industry makes frequent use of the term computer literacy. Pundits talk about how some people have it and some don’t, how those who have it will succeed in the information economy, and how those who lack it will inevitably fall between the socioeconomic cracks. Computer literacy, however, is nothing more than a euphemism for forcing human beings to stretch their thinking to understand an alien, machine logic rather than having software-enabled products stretch to meet people’s ways of thinking. In this chapter, we discuss how a poor understanding of users and the specific ways they approach digital products has exacer-bated the computer-literacy divide, and how software that better matches how people think and work can help solve the problem.
Implementation Models
Any machine has a mechanism for accomplishing its purpose. A motion picture projector, for example, uses a complicated sequence of intricately moving parts to create its illusion. It shines a very bright light through a translucent, miniature
06_084113 ch02.qxp 4/3/07 6:01 PM Page 28
28
Part I: Understanding Goal-Directed Design
image for a fraction of a second. It then blocks out the light for a split second while it moves another miniature image into place. Then it unblocks the light again for another moment. It repeats this process with a new image 24 times per second.
Software-enabled products don’t have mechanisms in the sense of moving parts; these are replaced with algorithms and modules of code that communicate with each other. The representation of how a machine or a program actually works has been called the system model by Donald Norman and others; we prefer the term implementation model because it describes the details of the way a program is implemented in code.
User Mental Models
From the moviegoer’s point of view, it is easy to forget the nuance of sprocket holes and light-interrupters while watching an absorbing drama. Many moviegoers, in fact, have little idea how the projector actually works, or how this differs from the way a television works. The viewer imagines that the projector merely throws a picture that moves onto the big screen. This is called the user’s mental model , or conceptual model.
People don’t need to know
all the details of how a complex mechanism actually works in order to use it, so they create a cognitive shorthand for explaining it, one that is powerful enough to cover their interactions with it, but that doesn’t necessarily reflect its actual inner mechanics. For example, many people imagine that, when they plug their vacuum cleaners and blenders into outlets in the wall, the electricity flows like water from the wall to the appliances through the little black tube of the electrical cord. This mental model is perfectly adequate for using household appliances. The fact that the implementation model of household electricity involves nothing resembling a fluid actually traveling up the cord and that there is a reversal of electrical potential 120 times per second is irrelevant to the user, although the power company needs to know the details.
In the digital world, however, the differences between a user’s mental model and the implementation model are often quite distinct. We tend to ignore the fact that our cellular telephone doesn’t work like a landline phone; instead, it is actually a radio transceiver that might swap connections between a half-dozen different cellular base antennas in the course of a two-minute call. Knowing this doesn’t help us to understand how to use the phone.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 29
Chapter 2: Implementation Models and Mental Models
29
The discrepancy between implementation and mental models is particularly stark in the case of software applications, where the complexity of implementation can make it nearly impossible for the user to see the mechanistic connections between his actions and the program’s reactions. When we use a computer to digitally edit sound or to create video special effects like morphing, we are bereft of analogy to the mechanical world, so our mental models are necessarily different from the implementation model. Even if the connections were visible, they would remain inscrutable to most people.
Represented Models
Software (and any digital product that relies on software) has a behavioral face it shows to the world that is created by the programmer or designer. This representation is not necessarily an accurate description of what is really going on inside the computer, although unfortunately, it frequently is. This ability to represent the computer’s functioning independent of its true actions is far more pronounced in software than in any other medium. It allows a clever designer to hide some of the more unsavory facts of how the software is really getting the job done. This disconnection between what is implemented and what is offered as explanation gives rise to a third model in the digital world, the designer’s represented model — the way the designer chooses to represent a program’s functioning to the user. Donald Norman refers to this simply as the designer’s model.
In the world of software, a program’s represented model can (and often should) be quite different from the actual processing structure of the program. For example, an operating system can make a network file server look as though it were a local disk. The model does not represent the fact that the physical disk drive may be miles away. This concept of the represented model has no widespread counterpart in the mechanical world. The relationship between the three models is shown in Figure 2-1.
The closer the represented model comes to the user’s mental model, the easier he will find the program to use and to understand. Generally, offering a represented model that follows the implementation model too closely significantly reduces the user’s ability to learn and use the program, assuming (as is almost always the case) that the user’s mental model of his tasks differs from the implementation model of the software.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 30
30
Part I: Understanding Goal-Directed Design
Implementation Model
Represented Models
Mental Model
reflects technology
worse
better
reflects userís vision
Figure 2-1 The way engineers must build software is often a given, dictated by various technical and business constraints. The model for how the software actually works is called the implementation model. The way users perceive the jobs they need to do and how the program helps them do it is their mental model of interaction with the software. It is based on their own ideas of how they do their jobs and how computers might work. The way designers choose to represent the working of the program to the user is called the represented model, which, unlike the other two models, is an aspect of software over which designers have great control. One of the most important goals of the designer should be to make the represented model match the mental model of users as closely as possible. It is therefore critical that designers understand in detail the way their target users think about the work they do with the software.
We tend to form mental models that are simpler than reality; so if we create represented models that are simpler than the actual implementation model, we help the user achieve a better understanding. Pressing the brake pedal in your car, for example, may conjure a mental image of pushing a lever that rubs against the wheels to slow you down. The actual mechanism includes hydraulic cylinders, tubing, and metal pads that squeeze on a perforated disk, but we simplify all that out of our minds, creating a more effective, albeit less accurate, mental model. In software, we imagine that a spreadsheet scrolls new cells into view when we click on the scrollbar. Nothing of the sort actually happens. There is no sheet of cells out there, but a tightly packed data structure of values, with various pointers between them, from which the program synthesizes a new image to display in real time.
Understanding how software actually works always helps someone to use it, but this understanding usually comes at a significant cost. One of the most significant ways in which computers can assist human beings is by putting a simple face on complex processes and situations. As a result, user interfaces that are consistent with users’
mental models are vastly superior to those that are merely reflections of the implementation model.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 31
Chapter 2: Implementation Models and Mental Models
31
User interfaces should be based on user mental models rather
DESIGN
principle
than implementation models.
In Adobe Photoshop, users can adjust the color balance and brightness of an illustration using a feature called Variations. Instead of offering numeric fields for entering color data — the implementation model — the Variations interface shows a set of thumbnail images, each with a different color balance (see Figure 2-2). A user can click on the image that best represents the desired color setting. The interface more closely follows his mental model, because the user — likely a graphic artist — is thinking in terms of how his image looks, not in terms of abstract numbers.
Figure 2–2 Adobe Photoshop has a great example of software design to match user mental models. The Variations interface shows a set of thumbnail images, varying color balance and brightness by adjustable increments. A user can click on the image that best represents the desired color setting. This image then becomes the new default for more varied thumbnails. The interface follows the mental model of graphic artists who are after a particular look, not a set of abstract numerical values.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 32
32
Part I: Understanding Goal-Directed Design
If the represented model for software closely follows users’ mental models, it eliminates needless complexity from the user interface by providing a cognitive framework that makes it evident to the user how his goals and needs can be met.
DESIGN
Goal-directed interactions reflect user mental models.
principle
A user’s mental model doesn’t necessarily have to be true or accurate, but it should enable him to work effectively. For example, most nontechnical computer users imagine that their video screen is the heart of their computer. This is only natural because
the screen is what they stare at all the time and is the place where they see what the computer is doing. If you point out to a user that the computer is actually a little chip of silicon in that black box sitting under his desk, he will probably shrug and ignore this pointless (to him) bit of information. The fact that the CPU isn’t the same thing as the video display doesn’t help him think about how he interacts with his computer, even though it is a more technically accurate concept.
Most Software Conforms to
Implementation Models
It is much easier to design software that reflects its implementation model. From the developer’s perspective, it’s perfectly logical to provide a button for every function, a field for every data input, a page for every transaction step, and a dialog for every code module. But while this adequately reflects the infrastructure of engineering efforts, it does little to provide coherent mechanisms for a user to achieve his goals.
In the end, what is produced alienates and confuses the user, rather like the ubiquitous external ductwork in the dystopian setting of Terry Gilliam’s movie Brazil (which is full of wonderful tongue-in-cheek examples of miserable interfaces).
User interfaces designed by engineers follow
the implementation model
User interfaces and interactions designed by engineers, who know precisely how software works, quite often lead to a represented model that is very consistent with its implementation model. To the engineers, such models are logical, truthful, and accurate; unfortunately, they are not very intelligible or effective for users. The majority of users don’t much care how a program is actually implemented.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 33
Chapter 2: Implementation Models and Mental Models
33
A good example of a digital product that conforms to implementation models is the typical component home theater system, which requires the user to know exactly how all of the components are wired together in order to switch, say, between viewing a DVD and tuning a cable TV channel. In most products, users need to switch video sources, and sometimes even switch between multiple remote controls, to access the functions they need simply to watch their television. A more mental-model-centered alternative, adopted by some newer products, is to keep track of the component configuration in the remote, so that the user can simply pick “Watch TV,” and the remote sends the appropriate commands to the TV, cable box, DVD