"We can create powerful and pleasurable software-based products by the simple expedient of designing our computer-based products before we build them. Contrary to popular belief, we are not already doing so."
According to Cooper, the computer industry is "in denial." Computer systems are extremely hard to use, yet many computer professionals are convinced that some incremental advance in technology such as voice recognition or artificial intelligence will soon fix the situation. The problem is deep-seated, however, based on product development that gives short shrift to design, often even skipping it entirely or (just as bad) leaving it until the very end, when things are too far developed to make any genuine changes to a product. We are fed systems that run efficiently but do not solve our problems, and then we are convinced that the real problem is our lack of understanding (we are not "computer literate" enough). The products we use may be carry executive many specific tasks with a great deal of precision, but they are often quite unhelpful.
The reason, says Cooper, is quite simple: "It is the engineers who are running the show." Managers of projects are "typically either hostage to programmers because they are insufficiently technical, or they are all too sympathetic to programmers because they are programmers themselves."
The industry is also infected with "dancing bearware." This is the result of building features into software simply because it can be done. We may complain about the features, but the technology-driven developer will point out how impressive it is that the computer can actually perform such functions. "The bear is really a terrible dancer, and the wonder isn't that the bear dances well but that the bear dances at all." In order to design products that really meet out goals, however, one must recognize that additional features are often a liability. The more a piece of software can do, the harder it is to figure out, even to perform the most basic functions. We should aim to simplify our systems, rather than make them more complex, simply because the latest technology allows us to do so.
Cooper used to be a software engineer, but in 1992 he stopped programming. He began focusing instead on "interaction design," which is concerned with how software should be behave and interact with us, rather than how its inner-workings should operate. Cooper argues that addressing interaction design as a separate discipline from programming is essential, since they require radically different ways of thinking about problems and situations. "Programming is such a difficult and absorbing task that it dominates all other considerations, including the concerns of the user."
Rather than simply blaming this situation on the programmers, we should take action to build design into product development from the very beginning of the process. Programmers provide an extremely complex and valuable service, but they are not, nor should they be expected to be, experts on how to conceptualize software in a way that is intuitive and even pleasurable to those most likely to use it. There are three major areas of concern for a new product:
Though he touches on the first two, the main thrust of Cooper's book is how to address the third consideration.
One of the biggest enemies of the interaction designer is "cognitive friction," which is "the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem permutes." Computers create a great deal of cognitive friction, since we often cannot tell what action to take next in order to accomplish a given goal, and we are often surprised to find that some action we thought was appropriate actually results in some horribly undesirable state of affairs. In contrast, "playing a violin is extremely difficult, but low in cognitive friction," since its behavior is quite predictable.
Creating a coherent, helpful product that minimizes cognitive friction involves more than simply creating "shopping list of features. A shopping bag filled with flour, sugar, milk and eggs is not the same thing as a cake." Much more important than features are goals. These goals should be as closely aligned as possible with the actual goals of the intended end users, forming the basis for what Cooper calls the method of "Goal-Directed Design." Cooper advocates the creation of "hypothetical archetypes of actual users," called "personas," and designing for them. The personas should hopefully be as true to life as possible, though it is more important for them to be fully fleshed out as individuals (so that they seem like real people to the designers). The basic idea behind this method is that one "will have far greater success designing for one single person" than try to hedge one's bets by creating a watered down product that intends to fit the needs of all possible people (and thus fails to adequately meet the needs of anyone).
Cooper's goal-directed design method has been fairly influential in recent years, particularly the idea of using personas in the early stages of design. Some advocates of more traditional research and design methodologies are quite skeptical of his approach, however, since personas are based on numerous guesses about potential users that have no little or no empirical justification. Others feel his approach to design does not give sufficient attention to the usability testing that should be conducted after a product's development has begun. It is also important to note that Cooper runs a consulting business, which specializes in goal-directed interaction design. The cynical reader could see the entire book as simply an advertisement for his company's services.
This book raises some extremely important points, however, particularly for a reader not already familiar with the literature on human-computer interaction (HCI). It introduces critiques of system-centered design (present in that literature for some time), in a quite readable and often entertaining way. Cooper also knows quite a bit about the computer industry, as reflected in many of his examples.
Thinking in terms of the goals and activities of a specific, hypothetical person can be a very helpful exercise when considering what sort of ICT, if any, might be appropriate to a given situation. More important than his specific methodology, however, are Cooper's arguments about the need to free one's self from the system-centered thinking of a software engineer. Blaming difficulties with ICTs on their users is both irresponsible and unproductive. ICTs should be adopted only if they can meet the goals of those involved. We must train ourselves to stop assuming that ICTs are both inherently difficult and inevitable, and that it is our job to conform our goals and activities to them.
» Next: Edtechnot.com