The conscious inclusion of design heralded the ascendance of the modern triad of product development concerns identified by Larry Keeley of the Doblin Group: capability, viability, and desirability (see Figure 1-3). If any one of these three foundations is significantly weak in a product, it is unlikely to stand the test of time.
Now enter the computer, the first machine created by humans that is capable of almost limitless behavior when properly coded into software. The interesting thing about this complex behavior, or interactivity, is that it completely alters the nature of the products it touches. Interactivity is compelling to humans, so compelling that other aspects of an interactive product become marginal. Who pays attention to the black box that sits under your desk — it is the interactive screen, keyboard, and mouse to which users pay attention. Yet, the interactive behaviors of software and other digital products, which should be receiving the lion’s share of design attention, all too frequently receive no attention at all.
The traditions of design that corporations have relied on to provide the critical pil-lar of desirability for products don’t provide much guidance in the world of interactivity. Design of behavior is a different kind of problem that requires greater knowledge of context, not just rules of visual composition and brand. Design of behavior requires an understanding of the user’s relationship with the product from before purchase to end-of-life. Most important of all is the understanding of how the user wishes to use the product, in what ways, and to what ends.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 12
12
Part I: Understanding Goal-Directed Design
Desirability
Capability
What do
What can
A successful product
people need?
we build?
is desirable and
viable and buildable
Viability
What will sustain a business?
Designers
Management
Technologists
User model
Business model
Technology model
▶ motivations
▶ funding model
▶ core technologies
▶ behaviors
▶ income/expense
▶ technology components
▶ attitudes & aptitudes
projections, etc
▶ build vs. buy
Product design
Business plan
Technology plan
▶ design schedule
▶ marketing plan
▶ engineering schedule
▶ form and behavior spec
▶ launch plan
▶ engineering spec
▶ distribution plan
User effectiveness &
Sustainable business
Project delivery
Customer adoption
Overall product success
You can apply this to companies who have struggled to find the balance: Novell
Apple
Microsoft
Novell emphasized
Apple has emphasized
Microsoft is one of the
technology and gave
desirability but has
best run businesses
little attention to
made many business
ever, but it has not been
desirability. This made
blunders. Nevertheless,
able to create highly
it vulnerable to
it is sustained by the
desirable products. This
competition.
loyalty created by its
provides an opening for
attention to the user
competition.
experiences.
Figure 1-3 Building successful digital products. The diagram indicates the three major processes that need to be followed in tandem to create successful technology products. This book addresses the first and foremost issue: how to create a product people will desire.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 13
Chapter 1: Goal-Directed Design
13
Planning and Designing Behavior
The planning of complex digital products, especially ones that interact directly with humans, requires a significant upfront effort by professional designers, just as the planning of complex physical structures that interact with humans requires a significant upfront effort by professional architects. In the case of architects, that planning involves understanding how the humans occupying the structure live and work, and designing spaces to support and facilitate those behaviors. In the case of digital products, the planning involves understanding how the humans using the product live and work, and designing product behavior and form that supports and facilitates the human behaviors. Architecture is an old, well-established field. The design of product and system behavior — interaction design — is quite new, and only in recent years has it begun to come of age as a discipline.
Interaction design isn’t merely a matter of aesthetic choice; rather, it is based on an understanding of users and cognitive principles. This is good news because it makes the design of behavior quite amenable to a repeatable process of analysis and synthesis. It doesn’t mean that the design of behavior can be automated, any more than the design of form or content can be automated, but it does mean that a systematic approach is possible. Rules of form and aesthetics mustn’t be discarded, of course, but they must work in harmony with the larger concern of achieving user goals via appropriately designed behaviors.
This book presents a set of methods to address the needs of this new kind of behavior-oriented design, which addresses the goals (Rudolf, 1998) and motivations of users: Goal-Directed Design. To understand Goal-Directed Design, we first need to better understand user goals and how they provide the key to designing appropriate interactive behavior.
Recognizing User Goals
So what are user goals? How can we identify them? How do we know that they are real goals, rather than tasks they are forced to do by poorly designed tools or business processes? Are they the same for all users? Do they change over time? We’ll try to answer those questions in the remainder of this chapter.
Users’ goals are often quite different from what we might guess them to be. For example, we might think that an accounting clerk’s goal is to process invoices efficiently. This is probably not true. Efficient invoice processing is more likely the goal of the clerk’s employer. The clerk is more likely concentrating on goals like appearing competent at his job and keeping himself engaged with his work while
05_084113 ch01.qxp 4/3/07 6:00 PM Page 14
14
Part I: Understanding Goal-Directed Design
performing routine and repetitive tasks, although he may not verbally (or even consciously) acknowledge this.
Regardless of the work we do and the tasks we must accomplish, most of us share these simple, personal goals. Even if we have higher aspirations, they are still more personal than work related: winning a promotion, learning more about our field, or setting a good example for others, for instance.
Products designed and built to achieve business goals alone will eventually fail; personal goals of users need to be addressed. When the user’s personal goals are met by the design, business goals are far more effectively achieved, for reasons we’ll explore in more detail in later chapters.
If you examine most commercially available software, Web sites, and digital products today, you will find that their user interfaces fail to meet user goals with alarming frequency. They routinely:
Make users feel stupid
Cause users to make big mistakes
Require too much effort to operate effectively
Don’t provide an engaging or enjoyable experience
Most of the same software is equally poor at achieving its business purpose.
Invoices don’t get proce
ssed all that well. Customers don’t get serviced on time.
Decisions don’t get properly supported. This is no coincidence.
The companies that develop these products don’t have the right priorities. Most focus their attention far too narrowly on implementation issues, which distract them from the needs of users.
Even when businesses become sensitive to their users, they are often powerless to change their products because the conventional development process assumes that the user interface should be addressed after coding begins — sometimes even after it ends. But just as you cannot effectively design a building after construction begins, you cannot easily make a program serve users’ goals once there is a significant and inflexible code base in place.
Finally, when companies do focus on the users, they tend to pay too much attention to the tasks that users engage in and not enough attention to their goals in performing those tasks. Software can be technologically superb and perform each business task with diligence, yet still be a critical and commercial failure. We can’t ignore technology or tasks, but they play only a part in a larger schema that includes designing to meet user goals.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 15
Chapter 1: Goal-Directed Design
15
Goals versus tasks and activities
Goals are not the same as tasks or activities. A goal is an expectation of an end condition, whereas both activities and tasks are intermediate steps (at different levels of organization) that help someone to reach a goal or set of goals.
Donald Norman describes a hierarchy in which activities are composed of tasks, which are in turn composed of actions, which are then themselves composed of operations. Using this scheme, Norman advocates “Activity-Centered Design”
(ACD), which focuses first and foremost on understanding activities. His claim is that humans adapt to the tools at hand, and understanding the activities that people perform with a set of tools can more favorably influence the design of those tools. The foundation of Norman’s thinking comes from Activity Theory, a Soviet-era Russian theory of psychology that emphasizes understanding who people are by understanding how they interact with the world, and which has in recent years been adapted to the study of human-computer interaction, most notably by Bonnie Nardi.
Norman concludes, correctly, that the traditional task-based focus of digital product design has yielded inadequate results. Many developers and usability professionals still approach the design of interfaces by asking, “What are the tasks?”
Although this may get the job done, it won’t produce much more than an incremental improvement: It won’t provide a solution that differentiates your product in the market, and very often won’t really satisfy the user.
While Norman’s ACD takes some important steps in the right direction by highlighting the importance of the user’s context, we do not believe that it goes quite far enough. While a method like ACD can be very useful in properly breaking down the “what” of user behaviors, it really doesn’t address what should be the first question asked by any designer: Why is a user performing an activity, task, action, or operation in the first place? Goals motivate people to perform activities; understanding goals allows you to understand the expectations and aspirations of your users, which can in turn help you decide which activities are truly relevant to your design. Task and activity analysis is useful at the detail level, but only after user goals have been analyzed. Asking, “What are the user’s goals?” lets you understand the meaning of activities to your users, and thus create more appropriate and satisfactory designs.
If you’re still unsure about the difference between goals and activities or tasks, there is an easy way to tell the difference between them. Since goals are driven by human motivations, they change very slowly — if at all — over time. Activities and tasks are much more transient, since they are based almost entirely on whatever technology is
05_084113 ch01.qxp 4/3/07 6:00 PM Page 16
16
Part I: Understanding Goal-Directed Design
at hand. For example, when traveling from St. Louis to San Francisco, a person’s goals are likely to include traveling quickly, comfortably, and safely. In 1850, a settler wishing to travel quickly and comfortably would have made the journey in a covered wagon; in the interest of safety, he would have brought along his trusty rifle. Today, a businessman traveling from St. Louis to San Francisco makes the journey in a jet aircraft and, in the interest of safety, he is required to leave his firearms at home. The goals of the settler and businessman remain unchanged, but their activities and tasks have changed so completely with the changes in technology that they are, in some respects, in direct opposition.
Design based solely on understanding activities or tasks runs the risk of trapping the design in a model imposed by an outmoded technology, or using a model that meets the goals of a corporation without meeting the goals of their users. Looking through the lens of goals allows you to leverage available technology to eliminate irrelevant tasks and to dramatically streamline activities. Understanding users’
goals can help designers eliminate the tasks and activities that better technology renders unnecessary for humans to perform.
Designing to meet goals in context
Many designers assume that making interfaces easier to learn should always be a design target. Ease of learning is an important guideline, but in reality, as Brenda Laurel notes, the design target really depends on the context — who the users are, what they are doing, and what goals they have. You simply can’t create good design by following rules disconnected from the goals and needs of the users of your product.
Let us illustrate: Take an automated call-distribution system. The people who use this product are paid based on how many calls they handle. Their most important concern is not ease of learning, but the efficiency with which users can route calls, and the rapidity with which those calls can be completed. Ease of learning is also important because it affects the happiness and, ultimately, the turnover rate of employees, so both ease and throughput should be considered in the design. But there is no doubt that throughput is the dominant demand placed on the system by the users and, if necessary, ease of learning should take a back seat. A program that walks the user through the call-routing process step by step each time merely frustrates him after he’s learned the ropes.
On the other hand, if the product in question is a kiosk in a corporate lobby helping visitors find their way around, ease of use for first-time users is clearly a major goal.
A general guideline of interaction design that seems to apply particularly well to productivity tools is that good design makes users more effective. This guideline takes
05_084113 ch01.qxp 4/3/07 6:00 PM Page 17
Chapter 1: Goal-Directed Design
17
into account the universal human goal of not looking stupid, along with more particular goals of business throughput and ease of use that are relevant in most business situations.
It is up to you as a designer to determine how you can make the users of your product more effective. Software that enables users to perform their tasks without addressing their goals rarely helps them be truly effective. If the task is to enter 5000
names and addresses into a database, a smoothly functioning data-entry application won’t satisfy the user nearly as much as an automated system that extracts the names from the invoicing system.
Although it is the user’s job to focus on her tasks, the designer’s job is to look beyond the task to identify who the most important users are, and then to determine what their goals might be and why. The design process, which we describe in the remainder of this chapter and detail in the remaining chapters of Part I, provides a structure for determining the answers to these questions, a structure by which solutions based on this information can be systematically achieved.
The Goal-Directed Design Process
Most technology-focused companies don’t have an ad
equate process for user-centered design, if they have a process at all. But even the more enlightened organizations, those that can boast of an established process, come up against some critical issues that result from traditional ways of approaching the problems of research and design.
In recent years, the business community has come to recognize that user research is necessary to create good products, but the proper nature of that research is still in question in many organizations. Quantitative market research and market segmentation is quite useful for selling products but falls short of providing critical information about how people actually use products — especially products with complex behaviors (see Chapter 4 for a more in-depth discussion of this topic). A second problem occurs after the results have been analyzed: Most traditional methods don’t provide a means of translating research results into design solutions. A hundred pages of user survey data don’t easily translate into a set of product requirements, and they say even less about how those requirements should be expressed in terms of a meaningful and appropriate interface structure. Design remains a black box: “A miracle happens here.” This gap between research results and the ultimate design solution is the result of a process that doesn’t connect the dots from user to final product. We’ll soon see how to address this problem with Goal-Directed methods.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 18
18
Part I: Understanding Goal-Directed Design
Bridging the gap
As we have briefly discussed, the role of design in the development process needs to change. We need to start thinking about design in new ways, and start thinking differently about how product decisions are made.
Design as product definition
Design has, unfortunately, become a limiting term in the technology industry. For many developers and managers, the word has come to mean what happens in the third process diagram shown in Figure 1-1: a visual facelift on the implementation model (see Chapter 2). But design, when properly deployed (as in the fourth process diagram shown in Figure 1-1), both identifies user requirements and defines a detailed plan for the behavior and appearance of products. In other words, design provides true product definition, based on goals of users, needs of business, and constraints of technology.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 6