Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)

by About Face 3- The Essentials of Interaction Design (pdf)

  Yvon Chounard, famed outdoorsman and founder of outdoor clothing company Patagonia, puts it best when he quotes French writer and aviator Antoine de St.

  Exupéry, who said, “in anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.”

  13_084113 ch08.qxp 4/3/07 6:04 PM Page 155

  Chapter 8: Synthesizing Good Design: Principles and Patterns

  155

  Possess internal coherence

  Good design has the feeling of a unified whole, in which all parts are in balance and harmony. Products that are poorly designed, or not designed at all, often look and feel like they are cobbled together from disparate pieces haphazardly knit together. Often this is the result of implementation model construction, where different development teams work on different interface modules without communicating with each other, or where hardware and software are designed independently of each other. This is the antithesis of what we want to achieve. The Goal-Directed Design process, in which product concepts are conceived of as a whole at the top level and then iteratively refined to detail, provides an ideal environment for creating internally coherent designs. Specifically, the use of scenarios to motivate and test designs ensures that solutions are unified by a single narrative thread.

  Appropriately accommodate and stimulate

  cognition and emotion

  Many traditionally trained designers speak frequently of desire and its importance in the design of communications and products. They’re not wrong, but we feel that in placing such emphasis on a single (albeit, complex) emotion, they may sometimes be seeing only part of the picture.

  Desire is a narrow emotion to appeal to when designing a product that serves a purpose, especially when that product is located in an enterprise, or its purpose is highly technical or specialized. One would hardly wish to make a technician operating a radiation therapy system feel desire for the system. We, instead, want her to feel cautious and perhaps reverent of the rather dangerous energies the system controls. Therefore, we do everything we can as designers to keep her focus on the patient and his treatment. Thus, in place of what we might call desire, the authors believe that elegance (in the sense of gracefulness) means that the user is stimulated and supported both cognitively and emotionally in whatever context she is in.

  The remaining chapters of this book enumerate what we view as the most critical interaction and visual interface design principles. There are, no doubt, many more you will discover, but this set will more than get you started. The chapters in Part I provided the process and concepts behind the practice of Goal-Directed interaction design. The chapters to come provide a healthy dose of design insight that will help you to transform this knowledge into excellent design, whatever your domain.

  13_084113 ch08.qxp 4/3/07 6:04 PM Page 156

  156

  Part II: Designing Behavior and Form

  Interaction Design Patterns

  Design patterns are a means of capturing useful design solutions and generalizing them to address similar problems. This effort to formalize design knowledge and record best practices can serve several vital purposes:

  Reduce design time and effort on new projects

  Improve the quality of design solutions

  Facilitate communication between designers and programmers

  Educate designers

  Although the application of patterns in design pedagogy and efficiency is certainly important, we find the development of interaction design patterns to be particularly exciting because they can represent optimal interactions for the user and the class of activity that the pattern addresses.

  Architectural patterns and interaction design

  The idea of capturing interaction design patterns has its roots in the work of Christopher Alexander, who first described architectural design patterns in his seminal work A Pattern Language and The Timeless Way of Building. By defining a rigorous set of architectural features, Alexander sought to describe the essence of architectural design that creates a feeling of well-being on the part of the inhabi-tants of structures.

  It is this last aim of Alexander’s project that resonates so closely with the needs of interaction designers, and it is the focus on the human aspects of each pattern that differentiates architectural and interaction design patterns from engineering patterns, which are primarily intended as a way to reuse and standardize programming code.

  One important difference between interaction design patterns and architectural design patterns is the concern of interaction design patterns not only with structure and organization of elements but also with dynamic behaviors and changes in elements in response to user activity. It is tempting to view the distinction simply as one of change over time, but these changes are interesting because they occur in response to both application state and human activity. This differentiates them from preor-dained temporal transitions that can be found in mechanical products and broadcast and film media (which each have their own distinct set of design patterns).

  13_084113 ch08.qxp 4/3/07 6:04 PM Page 157

  Chapter 8: Synthesizing Good Design: Principles and Patterns

  157

  Recording and using interaction design patterns

  Patterns are always context specific: They are defined to be applicable to common design situations that share similar contexts, constraints, tensions, and forces.

  When capturing a pattern, it is important to record the context to which the solution applies, one or more specific examples of the solution, the abstracted features common to all of the examples, and the rationale behind the solution (why it is a good solution).

  For a set of patterns to be useful, they must be meaningfully organized in terms of the contexts in which they are applicable. Such a set is commonly referred to as a pattern library or catalog, and if this set is rigorously defined and specified, and sufficiently complete to describe all the solutions in a domain, then it is referred to as a pattern language (though considering the pace of innovation in all types of digital products, it seems unlikely that such a language will stabilize anytime soon) .

  Design patterns are not recipes or plug-and-play solutions. In her book Designing Interfaces, which is a broad and useful collection of interaction design patterns, Jenifer Tidwell provides us with the following caveat: “[Patterns] aren’t off-the-shelf components; each implementation of a pattern differs a little from every other.”1

  There is some temptation in the world of software design to imagine that a comprehensive catalogue of patterns could, given a clear idea of user needs, permit even novice designers to assemble coherent design solutions rapidly and with ease.

  Although we have observed that there is some truth to this notion in the case of sea-soned interaction designers, it is simply never the case that patterns can be mechanically assembled in cookie-cutter fashion, without knowledge of the context in which they will be used. As Christopher Alexander is swift to point out, architectural patterns are the antithesis of the prefab building, because context is of absolute importance in defining the manifest form of the pattern in the world. The environment where the pattern is deployed is critical, as are the other patterns that compose it, contain it, and abut it. The same is true for interaction design patterns.

  The core of each pattern lies in the relationships between represented objects and between those objects and the goals of the user. (This is one reason why a general style guide can never be a substitute for a context-specific design solution.) The precise form of the pattern is certain to be somewhat different for each instance, and the objects that define it will naturally vary from domain to domain, but the relationships between objects remain essentially the same.

  13_084113 ch08.qxp 4/3/07 6:04 PM Page 158

  158

  Part II: Designing Behavior and Form

  Types of interaction design patterns

  Like most other design patterns, interaction design patterns c
an be hierarchically organized from the system level down to the level of individual interface widgets. Like principles, they can be applied at different levels of organization (and as with design principles, the distinctions between these different levels are sometimes quite fuzzy):

  Postural patterns can be applied at the conceptual level and help determine the overall product stance in relation to the user. An example of a postural pattern is

  “transient,” which means that a person only uses it for brief periods of time in service of a larger goal being achieved elsewhere. The concept of product posture and its most significant patterns are discussed at length in Chapter 9.

  Structural patterns solve problems that relate to the arrangement of information and functional elements on the screen. They consist of views, panes, and element groupings discussed briefly in Chapter 7.

  Behavioral patterns solve wide-ranging problems relating to specific interactions with functional or data elements. What most people think of as widget behaviors fall into this category, and many such lower-level patterns are discussed in Part III.

  Structural patterns are perhaps the least documented patterns, but they are nonetheless in widespread use. One of the most commonly used high-level structural patterns is apparent in Microsoft Outlook with its navigational pane on the left, overview pane on the upper right, and detail pane on the lower right (see Figure 8-1).

  Organizer

  Overview

  index to objects

  manipulation of objects

  Detail

  display of content or

  attributes of individual objects

  Figure 8-1 The primary structural pattern used by Microsoft Outlook is widely used throughout the industry, across many diverse product domains. The left-vertical pane provides navigation and drives the content of the overview pane in the upper right. A selection in this pane populates the lower-right pane with detail or document content.

  13_084113 ch08.qxp 4/3/07 6:04 PM Page 159

  Chapter 8: Synthesizing Good Design: Principles and Patterns

  159

  This pattern is optimal for full-screen applications that require user access to many different kinds of objects, manipulation of those objects in groups, and display of detailed content or attributes of individual objects or documents. The pattern permits all this to be done smoothly in a single screen without the need for additional windows. Many e-mail clients make use of this pattern, and variations of it appear in many authoring and information management tools where rapid access to and manipulation of various types of objects is common.

  Building up a mental catalog of patterns is one of the most critical aspects of the education of an interaction designer. As we all become aware of the best parts of each other’s work, we can collectively advance the interaction idioms we provide to our users, and by leveraging existing work, we can focus our efforts on solving new problems, rather than reinventing the wheel.

  Notes

  1. Tidwell, 2006, p. xiv

  13_084113 ch08.qxp 4/3/07 6:04 PM Page 160

  14_084113 ch09.qxp 4/3/07 6:04 PM Page 161

  9

  Platform and Posture

  As you’ll recall from Chapter 7, the first question to answer as you begin to design an interactive product is, “What platform and posture are appropriate?” The platform can be thought of as the combination of hardware and software that enables the product to function, in terms of both user interactions and the internal operations of the product.

  You’re undoubtedly familiar with many of the most common platforms for interactive products, including desktop software, Web sites and Web applications, kiosks, in-vehicle systems, handhelds (such as cameras, phones, and PDAs), home entertainment systems (such as game consoles, TV set-top boxes/tuners, and stereo/home theater systems), and professional devices (such as medical and scientific instruments). Looking at this list, you also may notice that “platform” is not an entirely well-defined concept. Rather, it is shorthand to describe a number of important product features, such as the physical form, display size and resolution, input method, network connectivity, operating system, and database capabilities.

  All of these factors have a significant impact on the way the product is designed, built, and used. Choosing the right platform is a balancing act, where you must find the sweet spot that best supports the needs and context of your personas and fits within the business constraints, objectives, and technological capabilities.

  14_084113 ch09.qxp 4/3/07 6:04 PM Page 162

  162

  Part II: Designing Behavior and Form

  A product’s posture is its behavioral stance — the way it presents itself to users.

  Posture is a way of talking about how much attention a user will devote to interacting with the product, and how the product’s behaviors respond to the kind of attention a user will be devoting to it. This decision, too, must be based upon an understanding of likely usage contexts and environments.

  Posture

  Most people have a predominant behavioral stance that fits their working role on the job: The soldier is wary and alert; the toll collector is bored and disinterested; the actor is flamboyant and bigger than life; the service representative is upbeat and helpful. Products, too, have a predominant manner of presenting themselves to users.

  A program may be bold or timid, colorful or drab, but it should be so for a specific, goal-directed reason. Its manner shouldn’t result from the personal preference of its designer or programmer. The presentation of the program affects the way users relate to it, and this relationship strongly influences the usability of the product.

  Programs whose appearance and behavior conflict with their purposes will seem jarring and inappropriate, like fur in a teacup or a clown at a wedding.

  The look and behavior of a product should reflect how it is used, rather than the personal taste of its designers. From the perspective of posture, look-and-feel is not solely an aesthetic choice: It is a behavioral choice. Your program’s posture is part of its behavioral foundation, and whatever aesthetic choices you make should be in harmony with this posture.

  The posture of your interface dictates many important guidelines for the rest of the design, but posture is not simply a black-and-white issue. Just as a person may present herself in a number of slightly different ways depending on the context, some products may exhibit characteristics of a number of different postures. When reading e-mail on a Blackberry during a train ride, a user may devote concentrated attention to interactions with the device (and expect a commensurate experience), whereas the same user will have significantly less attention to devote if she is using it to look up an address while running to a meeting. Similarly, while a word processor should generally be optimized for concentrated, devoted, and frequent user attention, there are tools within the word processor, like the table construction tool, that are used in a transient and infrequent manner. In cases like this, it is worthwhile both to define the predominant posture for a product as a whole and to consider the posture of individual features and usage contexts.

  14_084113 ch09.qxp 4/3/07 6:04 PM Page 163

  Chapter 9: Platform and Posture

  163

  Platform and posture are closely related: Different hardware platforms are conducive to different behavioral stances. An application running on a mobile phone clearly must accommodate a different kind of user attention than an educational program running on a game console.

  In this chapter we discuss appropriate postures and other design considerations for several platforms, including desktop software, Web sites and applications, kiosks, handhelds, and appliances.

  Designing Desktop Software

  We use the term “desktop software” as a catchall phrase referring for applications that run on a modern PC. Generally speaking, interaction design has its roots in desktop software. While historically there have been designers grappling with issues related to complex behaviors on a variety of technical platforms, i
t has been the personal computer that has brought these complex behaviors to every desktop. As a result, much of what you’ll find in this book is grounded in what it takes to effectively serve human needs with desktop software. In more recent history, this understanding has been expanded to encompass the Web, large and small devices, and other embedded systems, which we discuss later in the chapter.

  When defining the platform of your product, clearly you must go beyond the term

  “desktop” to consider what the appropriate operating system, database, and user-interface technology are for your product. While it is considerably outside the scope of this book to assess each of these technical aspects of the desktop platform, it is absolutely critical that these decisions be analyzed in regard to whether they will support the needs of users. Furthermore, as all design is a conversation with materials, it is also important to understand the limitations and opportunities associated with each of these fundamental technologies.

  In many organizations, platform decisions, particularly those regarding hardware, are unfortunately still made well in advance of the interaction designer’s involvement. It is important to inform management that platform choices will be much more effective if made after interaction designers complete their work.

  Decisions about technical platform are best made in concert with

  DESIGN

  principle

  interaction design efforts.

  Desktop applications fit into four categories of posture: sovereign, transient, and daemonic . Because each describes a different set of behavioral attributes, each also