We hope this book informs you and intrigues you, but most of all, we hope it makes you think about the design of digital products in new ways. The practice of interaction design is constantly evolving, and it is new and varied enough to generate a wide variety of
The design of interaction begins well below the surface of our systems, applications, and hardware. Imagining that we can create a good user experience for our products
after
their internals have been
Our book has a simple
On the surface, this premise sounds quite obvious and straightforward: Make the user 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 either happy or successful—or both?
Most digital products today emerge from the development process like a monster emerging from a bubbling tank. Developers, instead of planning and executing with their users in mind, end up creating technological solutions over which they ultimately have little control. Like mad scientists, they fail because they have not imbued their creations with humanity.
Design, according to industrial designer Victor Papanek, is the conscious and intuitive effort to impose meaningful order . The authors propose a somewhat more detailed definition:
Understanding the user's wants, needs, motivations, and contexts
Understanding business, technical, and domain requirements and constraints
Translating this knowledge into
plans
for artifacts (or artifacts
This definition applies across all design disciplines, although the precise focus on form versus content versus behavior varies by design discipline.
When performed using the appropriate methods, design can provide the missing human connection in technological products. But clearly, the current approach to the design of digital products either isn't working or isn't happening as advertised.
Most digital products are built from an engineering point of view. True, marketing departments are sometimes able to provide requirements, but these often have little to do with what users actually need and have more to do with following the competition, providing feature checklists to IT departments, or making guesses based on user surveys or customer wish lists. None of these approaches take into account the users' goals in any systematic fashion. We'll soon see why goals are so important.
Developers have a different set of imperatives than users, centering on technology and engineering methodology. Meanwhile, marketing departments focus on what
The result of these approaches is,
Figure 1-1:
The evolution of the software development process. Today, design is often an afterthought. It should, instead, happen before any coding or testing begins.
Here are a few examples of why focusing on technology, markets, and tasks alone (instead of designing for users and their goals) results in the kind of software we've all grown to despise.
Software is often rude to the user. It blames the user for making mistakes that are not the user's fault, or should not be. Error message boxes like the one in Figure 1-2 pop up like weeds announcing that the user has failed yet again. These messages also demand that user
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? Why do we care? And what are we OKing, anyway? It is not OK that the program failed!
Software frequently interrogates the user, peppering him with a string of terse questions that he is
Software too frequently assumes that its user is computer-literate. For example, when a user is finished editing a document, he
Software is frequently obscure, hiding meaning, intentions, and actions from the user. Programs often express themselves in incomprehensible jargon that cannot be fathomed by normal users ("How many stop bits?") and sometimes even by experts ("Please specify IRQ.").
Features are hidden behind a veil of
More frequently than you might think, software demands that its users answer tough questions before telling them the effects their answers might have. For example, how can a user possibly decide between a full installation, custom installation, and laptop installation if he isn't told what each of them means in terms of functionality as well as disk space?
If a 10-year-old child behaved like some software programs, he'd be sent to his room without supper. Programs forget to shut doors behind themselves, 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
So what, then, is the real problem here? Why does the technology industry have such a problem with design of interactive products?
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
We'll soon see how to address the issue of understanding users and their behaviors with products.
A second problem affects the ability of
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—
When we think about complex mechanical devices, we take for granted that they have been
The current process of determining what software will do and how it will communicate with the user is today closely intertwined with its construction. Programmers, deep in their thoughts of algorithms and code, "design" user interfaces the same way that miners "design" the landscape with their cavernous pits and
Many programmers today embrace the notion that integrating users directly into the programming process on a frequent basis—weekly, or sometimes even daily—can solve design problems. Although this has the salutary effect of sharing the responsibility for design with the user, it ignores a serious
To understand how to create a