On the surface, this premise sounds quite obvious and straightforward: Make people happy, and your products will be a success. Why then are so many digital products so difficult and unpleasant to use? Why aren’t we all happy and successful?
Digital Products Need Better
Design Methods
Most digital products today emerge from the development process like a creature emerging from a bubbling tank. Developers, instead of planning and executing with a mind towards satisfying the needs of the people who purchase and use their products, end up creating technologically focused solutions that are difficult to use and control. Like mad scientists, they fail because they have not imbued their cre-ations with humanity.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 4
4
Part I: Understanding Goal-Directed Design
Design, according to industrial designer Victor Papanek, is the conscious and intuitive effort to impose meaningful order. We propose a somewhat more detailed definition of human-oriented design activities:
Understanding users’ desires, needs, motivations, and contexts
Understanding business, technical, and domain opportunities, requirements, and constraints
Using this knowledge as a foundation for plans to create products whose form, content, and behavior is useful, usable, and desirable, as well as economically viable and technically feasible
This definition is useful for many design disciplines, although the precise focus on form, content, and behavior will vary depending on what is being designed. For example, an informational Web site may require particular attention to content, whereas the design of a chair is primarily concerned with form. As we discussed in the Introduction, interactive digital products are uniquely imbued with complex behavior.
When performed using the appropriate methods, design can provide the missing human connection in technological products. But clearly, most current approaches to the design of digital products aren’t working as advertised.
The creation of digital products today
Digital products come into this world subject to the push and pull of two, often opposing, forces — developers and marketers. While marketers are adept at understanding and quantifying a marketplace opportunity, and at introducing and positioning a product within that market, their input into the product design process is often limited to lists of requirements. These requirements often have little to do with what users actually need or desire and have more to do with chasing the competition, managing IT resources with to-do lists, and making guesses based on market surveys — what people say they’ll buy. (Contrary to what you might suspect, few users are able to clearly articulate their needs. When asked direct questions about the products they use, most tend to focus on low-level tasks or workarounds to product flaws.) Unfortunately, reducing an interactive product to a list of hundreds of features doesn’t lend itself to the kind of graceful orchestration that is required to make complex technology useful. Adding “easy to use” to the list of requirements does nothing to improve the situation.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 5
Chapter 1: Goal-Directed Design
5
Developers, on the other hand, often have no shortage of input into the product’s final form and behavior. Because they are in charge of construction, they decide exactly what gets built. And they, too, have a different set of imperatives than the product’s eventual users. Good developers are focused on solving challenging technical problems, following good engineering practices, and meeting deadlines. They are often given incomplete, confusing, and sometimes contradictory instructions and are forced to make significant decisions about the user experience with little time or background.
Thus, the people who are most often responsible for the creation of our digital products rarely take into account the users’ goals, needs, or motivations, and at the same time tend to be highly reactive to market trends and technical constraints.
This can’t help but result in products that lack a coherent user experience. We’ll soon see why goals are so important in addressing this issue.
The results of poor product vision are, unfortunately, digital products that irritate, reduce productivity, and fail to meet user needs. Figure 1-1 shows the evolution of the development process and where, if at all, design has historically fit in. Most of digital product development is stuck in the first, second, or third step of this evolution, where design either plays no real role or it becomes a surface-level patch on shoddy interactions — “lipstick on the pig,” as one of our clients once referred to it. The design process, as we will soon discuss, should precede coding and testing to ensure that products truly meet the needs of users.
In the dozen years since the publication of the first edition of this book, software and interactive products have certainly improved. Many companies have begun to focus on serving the needs of people with their products, and are spending the time and money to do upfront design. Many more companies are still failing to do this, and as they maintain their focus on technology and marketing data, they continue to create the kind of digital products we’ve all grown to despise. Here are a few symptoms of this affliction.
Digital products are rude
Digital products often blame users for making mistakes that are not their fault, or should not be. Error messages like the one in Figure 1-2 pop up like weeds announcing that the user has failed yet again. These messages also demand that the user acknowledge his failure by agreeing: OK.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 6
6
Part I: Understanding Goal-Directed Design
Programmers
Build /Test
Ship
Managers
Programmers
Initiate
Build /Test
Ship
Managers
Programmers
QA
Designers
Initiate
Build
Test
“Look
Ship
& Feel”
Managers
Designers
Programmers
QA
mandate
specs
code
product
feasibility
bug
input
Initiate
Users
Design
feedback
Build
report
Test
Users
Ship
Figure 1-1 The evolution of the software development process. The first diagram depicts the early days of the software industry when smart programmers dreamed up products, and then built and tested them. Inevitably, professional managers were brought in to help facilitate the process by translating market opportunities into product requirements. As depicted in the third diagram, the industry matured, testing became a discipline in its own right, and with the popularization of the graphical user interface (GUI), graphic designers were brought in to create icons and other visual elements. The final diagram shows the Goal-Directed approach to software development where decisions about a product’s capabilities, form, and behavior are made before the expensive and challenging construction phase.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 7
Chapter 1: Goal-Directed Design
7
Figure 1-2 Thanks for sharing. Why didn’t the program notify the library? What did it want to notify the library about? Why is it telling us? And what are we OKing, anyway? It is not OK that the program failed!
Digital products and software frequently interrogate users, peppering them with a string of terse questions that they are neither inclined or prepared to answer:
“Where did you hide that file?” Patronizing questions like “Are you sure?” and “Did you really want to delete that file or did you have some other reason for pressing the Delete key?” are equally irritating and demeaning.
O
ur software-enabled products also fail to act with a basic level of decency. They forget information we tell them and don’t do a very good job of anticipating our needs. For example, the feature-rich Palm Treo smartphone doesn’t anticipate that a user might want to add the phone number of someone who has just called to an existing contact. It doesn’t take a lot of research or imagination to deduce that this is something that many users will want to do, but nevertheless one is forced to go through a complicated maze involving copying the phone number, navigating to the contact in question, and pasting into the appropriate field.
Digital products require people to think like computers
Digital products regularly assume that people are technology literate. For example, in Microsoft Word, if a user wants to rename a document she is editing, she must know that she must either close the document, or use the “Save As...” menu command (and remember to delete the file with the old name). These behaviors are not consistent with the way a normal person thinks about renaming something; rather, they require that a person change her thinking to be more like the way a computer works.
Digital products are also often obscure, hiding meaning, intentions, and actions from users. Programs often express themselves in incomprehensible jargon that cannot be fathomed by normal users (“How many stop bits?”) and are sometimes incomprehensible even to experts (“Please specify IRQ.”).
05_084113 ch01.qxp 4/3/07 6:00 PM Page 8
8
Part I: Understanding Goal-Directed Design
Digital products exhibit poor behavior
If a 10-year-old child behaved like some software programs or devices, he’d be sent to his room without supper. Programs forget to shut the refrigerator door, leave shoes in the middle of the floor, and can’t remember what you told them only five minutes earlier. For example, if you save a Microsoft Word document, print it, and then try to close it, the program once again asks you if you want to save it! Evidently the act of printing caused the program to think the document had changed, even though it did not. Sorry, Mom, I didn’t hear you.
Programs often require us to step out of the main flow of tasks to perform functions that should fall immediately to hand. Dangerous commands, however, are often presented right up front where unsuspecting users can accidentally trigger them. The overall appearance of many programs is overly complex and confusing, making navigation and comprehension difficult.
Digital products require humans to do the heavy lifting
Computers and their silicon-enabled brethren are supposed to be labor-saving devices, but every time we go out into the field to watch real people doing their jobs with the assistance of technology, we are struck and horrified by how much work they are forced to do to manage the operation of software. This work can be anything from manually keying values from one window into another, to copying and pasting between applications that don’t otherwise speak to each other, to the ubiquitous clicking and pushing and pulling of windows around the screen to access hidden functionality that people use every day to do their job.
Why are these products so bad?
So what, then, is the real problem? Why is the technology industry generally so inept at designing the interactive parts of digital products? There are three primary reasons: ignorance about users, a conflict of interest between serving human needs and construction priorities, and the lack of a process for understanding human needs as an aid to developing appropriate product form and behavior.
Ignorance about users
It’s a sad truth that the digital technology industry doesn’t have a good understanding of what it takes to make users happy. In fact, most technology products get built without much understanding of the users. We might know what market segment our users are in, how much money they make, how much money they like to
05_084113 ch01.qxp 4/3/07 6:00 PM Page 9
Chapter 1: Goal-Directed Design
9
spend on weekends, and what sort of cars they buy. Maybe we even have a vague idea what kind of jobs they have and some of the major tasks that they regularly perform. But does any of this tell us how to make them happy? Does it tell us how they will actually use the product we’re building? Does it tell us why they are doing whatever it is they might need our product for, why they might want to choose our product over our competitors, or how we can make sure they do? Unfortunately, it does not.
We’ll soon see how to address the issue of understanding users and their behaviors with products.
Conflicting interests
A second problem affects the ability of vendors and manufacturers to make users happy. There is an important conflict of interest in the world of digital product development: The people who build the products — programmers — are usually also the people who design them. Programmers are often required to choose between ease of coding and ease of use. Because programmers’ performance is typically judged by their ability to code efficiently and meet incredibly tight deadlines, it isn’t difficult to figure out what direction most software-enabled products take.
Just as we would never permit the prosecutor in a legal trial to also adjudicate the case, we should make sure that the people designing a product are not the same people building it. Even with appropriate skills and the best intentions, it simply isn’t possible for a programmer to advocate effectively for the user, the business, and the technology all at the same time.
The lack of a process
The third reason the digital technology industry isn’t cranking out successful products is that it has no reliable process for doing so. Or, to be more accurate, it doesn’t have a complete process for doing so. Engineering departments follow — or should follow — rigorous engineering methods that ensure the feasibility and quality of the technology. Similarly, marketing, sales, and other business units follow their own well-established methods for ensuring the commercial viability of new products. What’s left out is a repeatable, predictable, and analytical process for transforming an understanding of users into products that both meet their needs and excite their imaginations.
When we think about complex mechanical devices, we take for granted that they have been carefully designed for use, in addition to being engineered. Most manufactured objects are quite simple, and even complex mechanical products are quite
05_084113 ch01.qxp 4/3/07 6:00 PM Page 10
10
Part I: Understanding Goal-Directed Design
simple when compared to most software and software-enabled products that can be compiled from over one million lines of code (compare this to a mechanical artifact of overwhelming complexity such as the space shuttle, which has 250,000
parts, only a small percentage of which are moving parts). Yet most software has never undergone a rigorous design process from a user-centered perspective.
In the worst case, decisions about what a digital product will do and how it will communicate with users is simply a byproduct of its construction. Programmers, deep in their thoughts of algorithms and code, end up “designing” product behaviors and user interfaces the same way that miners end up “designing” the landscape with cavernous pits and piles of rubble. In unenlightened development organizations, the digital product interaction design process alternates between the accidental and the nonexistent.
Sometimes organizations do adopt a design process, but it isn’t quite up to the task.
Many programmers today embrace the notion that integrating customers directly into the development process on a frequent basis can solve human interface design problems. Although this has the salutary effect of sharing the responsibility for design with the user, it ignores a serious methodological flaw: a confusion of domain knowledge with design knowledge. Customers, although they might be able to articulate the problems with an interaction, are not often capable of visualizing the solutions to those problems. Design is a specialized skill, just like programming. Programmers would never ask users to help them code; design problems should be treated no differ
ently. In addition, customers who purchase a product may not be the same people who use it from day to day, a subtle but important distinction.
This doesn’t mean that designers shouldn’t be interested in getting feedback on their proposed solutions. However, each member of the product team should respect the others’ areas of expertise. Imagine a patient who visits his doctor with a horrible stomachache. “Doctor,” he says, “it really hurts. I think it’s my appendix. You’ve got to take it out as soon as possible.” Of course, a responsible physician wouldn’t perform the surgery without question. The patient can express the symptoms, but it takes the doctor’s professional knowledge to make the correct diagnosis.
To better understand how to create a workable process that brings user-centered design to digital products, it’s useful to understand a bit more about the history of design in manufacturing and about how the challenges of interactive products have substantially changed the demands on design.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 11
Chapter 1: Goal-Directed Design
11
The Evolution of Design in
Manufacturing
In the early days of industrial manufacturing, engineering and marketing processes alone were sufficient to produce desirable products: It didn’t take much more than good engineering and reasonable pricing to produce a hammer, diesel engine, or tube of toothpaste that people would readily purchase. As time progressed, manufacturers of consumer products realized that they needed to differentiate their products from functionally identical products made by competitors, so design was introduced as a means to increase user desire for a product. Graphic designers were employed to create more effective packaging and advertising, and industrial designers were engaged to create more comfortable, useful, and exciting forms.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 5