CONNECTICUT LIBRARIES
April 2000, Vol. 42, No. 4
Alan Cooper, creator of the Visual Basic programming language and other software products, explains to us "Why High-Tech Products Drive Us Crazy and How to Restore the Sanity." He lays blame squarely on the shoulders of the programmers and software engineers. He sees salvation in better planning and design of software products by "interaction designers."Cooper argues that the software industry is the only major business in the world where the builders of the product, not the owners and managers of the industry, are in control. As a result, the products reflect the interests, preferences, and personalities of the programmers better than they meet the needs, capabilities, and desires of the consumer. This situation intensifies what Cooper calls "cognitive friction." Cognitive friction occurs when the object of our attention operates according to complex rules of behavior that change, even as we learn them.
Physical objects are low in cognitive friction. Their behavior is usually predictable and discernable from their appearance. We may never play the violin like a virtuoso, but we understand how the instrument works. Electronic devices are high in cognitive friction. The same button on your microwave oven may set the time, or it may set the intensity. It depends on which "mode" the machine is in. VCR's, with their non-intuitive controls, continue to stymie countless intelligent humans.
Software is VERY high in cognitive friction. Drag a file from your hard drive to your floppy disk, and you end up with two copies of the file, one on each drive. Drag a file from the "Correspondence" folder on your hard drive to the "Reports" folder on the same drive, and, poof!, the file has vanished from the first folder and reappeared in the second. You can think of other examples where the same action, taken in two different programs, or at two different points within the same program, yield different results.
Programmers create cognitive friction because they "design" for themselves and for others like themselves. Interaction designers understand how to reduce it. Cooper advocates that interaction designers be brought in at the very start of a software project, before any code is written. For, once that process has begun, it is too late!
Writing software is incredibly difficult work. Hiring good programmers is very expensive. Once managers assign programmers to a project, they want them writing code. Most managers cannot understand what the programmers are doing until it is pretty much done. Even if they could read the code and review the programmer's work, the time spent in doing so would destroy any hope of meeting the shipping schedules of most companies and drive up costs.
To save time and avoid boredom, programmers often integrate previously-used code into new programs. If changes need to be made to the program, rarely does the programmer return to "square one." Rather, he adapts what he has already written. As a result, software is "scarred." It contains code that is unneeded, and often includes code that interferes with normal operation.
Programmers, Cooper contends, are resistant to change. He suggests that we think of them as high school "jocks," who never grew out of their macho attitudes. The teenage athletic hero rules by size, strength, and willingness to bully. Once out of high school, however, society civilizes. Winning through physical intimidation no longer works. On the other hand, the teenage "nerd" resists socialization. Adult society rewards his brain power. He remains the same intellectual bully that he was in high school. He resents "input" from non-programmers who do not appreciate the subtle challenges that he faces.
The author makes traditional software development sound like an out-of-control train driven by impossible deadlines, mounting expenses, scarred code, and stubborn software engineers. Braking and steering the runaway is hopeless. Control must come before the train leaves the station: better design for the people who will use the software. Yet, Cooper shuns the term "user-friendly." He feels software professionals endlessly change who this "user" is as it becomes convenient for them to do so. Instead, he and his designers create "personas" with names, personalities, likes, dislikes, specific needs, and skills. His designers, and the programmers they work with, build software for these very "real" personas.
While industry leaders put their faith in interface design and usability testing, Cooper dismisses these as comforting buzzwords. Interface design, for him, means slapping a pretty face on hard-to-use software. Without interaction design, usability testing is a waste, he reasons, because the companies do not know what to test. Consumers, too, bear responsibility for poor software. If the industry had to sell products to the general public, not just to the "computer literate," software would look a lot different.
Cooper is no Luddite. He blames people, not technology for software insanity. His fresh ideas, business-world examples, and insightful anecdotes entertain and convince.
Return to Looking at Books Online