Chapter 1: Goal-Directed Design

Our book has a simple premise: If achieving the user's goals is the basis of our design process, the user will be satisfied and happy. If the user is happy, he will gladly pay us money (and recommend that others do the same), and then we will be successful as a business.

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?

Digital Products Need Better Design Methods

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 themselves) whose form, content, and behavior is useful, usable, and desirable, as well as economically viable and technically feasible

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.

The design of digital products today

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 drives press attention, on feature lists, and on what people say they will buy. Users, when asked direct questions about the products they use, tend to focus on low-level tasks—contrary to what you might suspect, few users are consciously aware of or are able to clearly articulate their goals.

The result of these approaches is, unfortunately, software that irritates, reduces productivity, and fails to meet user needs. Figure 1-1 shows the evolution of the software development process, and where, if at all, design has 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 bad interactions—"lipstick on the pig," as one of the authors' clients referred to it. The design process, as we will soon discuss, needs to precede coding and testing to ensure that products truly meet the needs of users.

click to expand
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 RUDE

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 acknowledge his failure by agreeing: OK.

click to expand
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 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.

SOFTWARE MAKES UNWARRANTED ASSUMPTIONS

Software too frequently assumes that its user is computer-literate. For example, when a user is finished editing a document, he closes it, and the program asks if he wants to save it. The technology behind this issue is not trivial. It has to do with the capability of the CPU to directly address information stored on random-access magnetic media—but how is the novice user to know that?

SOFTWARE IS OBSCURE

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 menus and dialogs and windows. How can the user know that the answer lies in the help system if he can't find the help system? Even when the user finds the right dialog, he might find it populated with terse abbreviations, obscure commands, and inscrutable icons.

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?

SOFTWARE EXHIBITS INAPPROPRIATE BEHAVIOR

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 accidentally trigger them. The overall appearance of many programs is overly complex and confusing, making navigation and comprehension difficult.

So what, then, is the real problem here? Why does the technology industry have such a problem with design of interactive products?

We're ignorant 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 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.

We have a conflict of interest

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 those designing a product are not the same people building it. It simply isn't possible for a programmer to advocate for the user, the business, and the technology at the same time.

We lack 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, 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 simple when compared to most software and software-enabled products that can sport in excess of 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.

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 enormous tailing piles. The software interface design process alternates between the accidental and the non-existent.

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 methodological flaw: a confusion of domain knowledge with design knowledge. Users, 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 differently.

To understand how to create a workable process that brings user-centered design to software, we need 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.




About Face 2.0(c) The Essentials of Interaction Design
About Face 2.0(c) The Essentials of Interaction Design
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 263

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net