asheraweb.com

Cooper’s Vision

Cooper begins his book citing examples of technology gone wrong. He asks the question, “What do you get when you cross a computer with an X?” He replaces X with an airplane, a camera, an alarm clock, a car, and a bank. In every case the answer to the question is: a computer (Chapter 1)¹.This means that implementation model design, stinginess of information, and impolite, sometimes deadly rationalism rule the interaction between humans and software-based systems. Cooper’s first insight is that because of this “cognitive friction”, high-tech interaction is generally poor. Indeed, one only need look at modern television sets to see that this is the case.

Cooper presents the case of his colleague Ted, who had purchased a new TV set (Chapter 10). Ted became frustrated with the set when it required him to read the manual before he could set and watch it. Cooper uses the goal-directed approach to solve the problem. Ted purchased a TV, and he wanted to watch it, which he wasn’t able to do until he read the manual. Moreover, the requisite of reading the manual made Ted feel stupid, and his personal goal was not to feel so. Cooper’s solution is simple: Allow Ted to watch TV as soon as he turns it on, and let him figure out its other features as he becomes comfortable with it. The TV example is important because televisions are ubiquitous, and it highlights our low standards for the design of common software-enabled devices. There is a strong need for ID, and it is currently lacking in our daily high-tech interactions.

The reason for this lack of good design is twofold. First, programmers control the software with which we interact (Chapter 6). Programmers work in isolation, which means that no one can direct the quality of a software product once the coding has begun. Programmers are also the ones with the most vested interest in the software development process. Any feature or function of an application must be coded by a programmer to come to fruition. Coupled with the fact that most managers in the software business were once programmers and are thus empathetic to them, we have programmers driving from the backseat.

Secondly, programmers tend to have a certain personality type and create a certain culture. They are logical, and for historical reasons put the needs of the computer before that of humans. Programmers revere technical know-how, and expect others to rise to the challenge of understanding how computers work. They revel in solving complex problems, and can believe that an interaction designer is taking away the most fun part of their jobs: the design. This results in programmers resisting interaction designers’ directives, and we get systems designed by programmers: complex, implementation model systems that submit the user to their wishes. In short, we get bad interaction design.

To bring good ID to the mainstream, we need to include designers in the software development process. This can work, and Cooper presents an example to illustrate. Cooper’s ID firm worked with Shared Healthcare Systems Inc. (SHS) to design a broad, complex, healthcare management system (Chapter 14). The design team identified the large size of the project, and thus it was decided to build it in several phases. They also discovered the failing of the previous system (the reason Cooper Interactive was hired by SHS in the first place). The system had a dividing line between two administrative and functional areas, and lack of communication was the cause of the failure.

Interaction design identified crucial planning and design areas of the project, but it only worked because there was widespread adoption of ID by the whole team. The VP of development at SHS had earned the trust and respect of his development team, and he was an adopter of ID methodology and practice. The team followed, and the project benefited.

The success of projects that adopt ID is partly due to the tools and practices of interaction designers. Interaction designers, as Cooper illustrates, use the concept of personas (Chapter 9). Personas are specific, precise, hypothetical individuals for whom a particular interactive system is designed. Personas help identify a realistic skill set for the target users, and get the software development team thinking from the perspective of the software users as opposed to the implementers. They can also be helpful in ending the ever-present feature list haggle. If the primary persona of a system does not need a particular feature, that feature can be safely removed from the list.

Interaction designers also use goal-directed design, which specifies and creates for a persona’s goals. An important separation here is that between goals and tasks. Goals are ends, and tasks are performed to meet those ends. When a web developer builds a website for a client, her goals are to make the client happy and earn money. She builds a design comp in Photoshop, chops it into XHTML/CSS, and sets up a content management system. These are tasks she performs to meet those goals.

Goal-directed design needs to make another separation: that between personal, practical and corporate goals. A persona’s personal goals, to be productive, have fun, and not feel stupid, must come before his practical and corporate goals. This approach creates software that is more human and easy to use. Users of this software are generally happier because their personal goals are being fulfilled, and they are therefore more productive.

Personas and goal-directed design combine to give interaction designers a powerful toolset to help in the creation of powerful and pleasurable software. Pleasurable software makes the customer want to use it, while powerful software exploits the great capacity of computers to perform feats impossible with traditional tools.

If a company can create a product that is both powerful and pleasurable, the result is increased customer loyalty, which translates to revenue. Well designed software also requires less documentation and technical support, which translates to cutting costs. Indeed, ID allows a software company to be more viable, as Cooper demonstrates in the example of Apple Computers. While Apple’s management style has hurt it and almost killed it, its customers are loyal to Apple simply because it excels at design, and they have kept it afloat. In fact, Apple has shown recent gains in market share. Apple is an example of the power of design to translate directly into revenue for a high-tech organization.