Interaction Design: The
What is Cooper Interaction Design? What is your role?
I have been a product inventor and designer for many years. For most of those years, I had to write the code to make my designs become real. In 1992 I stopped all programming and offered my design services to others. Two years later, I had more business than I could handle. My wife, Susan Cooper, a software industry marketing executive, joined me full time, along with designer Wayne Greenwood. We have been growing ever since.
Today, I fill the role of President, which means that I oversee all of our business and design operations and strategy. As we grow, however, I find my direct involvement decreasing, and I spend more time teaching, writing, and speaking. We now have many talented designers who use our proprietary Goal-Directed design method to better effect than I ever could.
Programmers always do design. However they design PROGRAMS, not products. They design programs in such a way that they run efficiently on digital computers and can be easily controlled by other engineering professionals.
The design we do is very different. We are less concerned about execution efficiency (although we assure that it is not ignored) than we are about assuring that normal human users will not be frustrated with the product.
We design the product from the outside in, rather than from the inside out. We call ourselves "interaction designers" because we are primarily concerned with the program's behavior with respect to human users. Often, this means interface design, but behavior is never limited just to the screen.
The design that programmers do will always be compromised by a powerful conflict of interest. They must decide between accommodating the user and accommodating their own ease of programming. They can never be expected to make an impartial call, and their design will always force the user to compensate for weaknesses in the code, rather than the other way around.
Most software, including web sites, behaves very rudely to human users. Programmers tend not to notice this, and just insist that users become more "computer literate." Many non-technical managers don't realize that there is another, better way, so they allow the bad interaction to persist. It is typically no more difficult to construct easy-to-use, friendly software than it is to create surly, ill-tempered software. All it takes is some thoughtful design done BEFORE programming begins. Programming is to concrete as design is to forms for pouring concrete. Once the coding process begins, the effectiveness of design is attenuated a thousand-fold.
In early 1988 I invented a visual programming language called Ruby that I sold to Bill Gates. Ruby had a very well-developed direct-manipulation engine, but had a very weak programming language. However, I designed the language in such a way that it could be easily upgraded. Bill exchanged the entire language with his then moribund QuickBasic product, and Visual Basic was born. I like to say that "I did the visual, and Microsoft did the Basic."
One of the most impressive lessons from VB is the power of a good design. Almost every programming tool available today uses the interaction paradigm first established with Visual Basic. While the underlying languages--the techy, programmer part--changes from product to product, they all look and work the same. What's more, the visual programming tool is now embedded in every Microsoft Office component and in many third party applications.
One other lesson: If you examine the history of Microsoft's products, you will find several failures and many, many huge successes. But you will find very few products that were clearly, obviously successful in their very first release. Visual Basic is a notable exception to that pattern. The very first version of VB was a huge commercial and critical success, despite how technically weak it was compared to its current incarnation. I attribute this to the fact that VB was DESIGNED, whereas most all other Microsoft products are just programmed (Microsoft will claim that they have been designed, but, referring to your first question, there is a big difference between PROGRAM design and PRODUCT design.).
MS Windows, for example, was bad enough to be the laughing stock of the industry for the first five years of its life. It took five major releases before the laughter subsided. MS Word, for another example, wasn't generally considered a successful product until it had undergone several major revisions. Those revisions are a LOT more expensive than a few months of design.
The main purpose of About Face was to raise the awareness of the software industry. I wanted programmers--and other concerned industry professionals--to see that there was a whole new side to software development issues. The book is by no means a comprehensive discussion of user interface techniques, but I gave it a thorough enough coverage of the state of the art to show that I wasn't just slinging random ideas around.
But the core of the book was a new way of thinking about human interaction that I introduced for the first time. Ideas like the abolition of all error messages, removing all confirmation dialogs, and utterly obliterating the annoying and useless "Save Changes?" concept were among the most important. I wanted developers and designers to see that it was possible to get enormously improved results by taking some radical new approaches to interaction design.
When the book first appeared in 1995, many programmers thought that I was crazy for asserting that there should be no such thing as a "Save" function represented in the interface. They claimed that it was theoretically wrong, technically impossible, and morally repugnant. Yet, today, in 1999, the most exciting new software-based products are the Palm Pilot, Microsoft Outlook, and the World Wide Web, NONE of which have the concept of "Save" as part of their interface. I consider this to be a vindication of at least a portion of my book.
Of course, there are similar examples of programs that use other of the book's radical ideas to their distinct advantage. In the book I spoke at length of the importance of an "undo" function. The "Back" button on your Web browser is doubtlessly the most appreciated control it has, and in most situations, it behaves exactly as an "undo" button would.
Most software interacts with human users in
about the same way that a
As I pointed out above, shipping a good product on the first version instead of on the third or fourth version can save a lot of money. What's more, those first badly designed, hard to use interfaces can alienate people. Yes, people might use your badly designed product if it is the only way to get their work done, but they won't have much loyalty to you or your product, and that makes you very vulnerable to competition.
Design is also an excellent tool for gaining control of the product development process. Most development managers don't really know what their product will look like until the programmers hand it to them. The only tools they have for controlling development is a list of features and a due date. That's like having to order dinner in a restaurant from just a shopping list and a time limit. A proper design is a detailed description of what the product will be when it is done. Knowing that, it is much easier to get to "done" faster, cheaper, and with fewer wasted steps.
Most programmers and development managers merely accept as an unavoidable aspect of software that users must be trained; that they must become "computer literate." I do not believe that this is true. However, by accepting this false assumption, you deny any person unwilling or unable to become "computer literate" from the benefits of using computers. In the past, this merely meant that those people could not become computer professionals. Today, however, computers are dominating EVERY industry, and those non-computer-literate people will soon be shut out of the mainstream of society. This is brutal, unfair, and unnecessary.
For one example, consider shopping. Five years ago, everyone shopped in their local stores and only a very few purchases were made with computers. Today, just a few percent of all items are bought using computers, but certainly you can see with the rapid acceptance of ecommerce--and the obvious advantages it brings--that soon the overwhelming majority of goods will be bought and sold over the Internet. If a person is not a skilled computer user then they will be forced to purchase things the old-fashioned, slow, expensive way. It is the same phenomenon that makes groceries in ghetto stores more expensive and of lower quality than similar goods in affluent stores. This assumed need for "computer literacy" is really driving a social and economic wedge into our society. It is hard for all of us computer-savvy, computer enthusiasts to see the damage we are doing, but it is there, and it is growing.
The Web is really good at making easy processes easier. A simple, static catalog on the Web is typically much better than that same catalog printed on paper. However, as we move to Web-applications with sophisticated functionality and complex data, we find that the more difficult tasks are actually HARDER to do on a browser platform. I have no doubt that we will inevitably reach some minimum acceptable level of pain with such products, but by applying interaction design techniques, we can turn those experiences from merely bearable to really enjoyable.
We have applied our standard interaction design methods the design of complex Web applications and have had significant improvements in usability. Those improvements are identical to what we regularly achieve with desktop, industrial, or kiosk software.
The answer is simple: Historically, we have not used interaction design to create pleasing, helpful, comfortable software, and that bad tradition has been inadvertently brought to the Web. In the excitement of the California Gold Rush of 150 years ago, the 49ers inflicted some of the world's worst pollution on the environment. In California, we are still trying to recover from that tragic lack of foresight and responsibility. We are at a similar moral crossroads today. Are we willing to be abusive of people for the opportunity to find the Mother Lode?
I will try to sell you my new book, instead. It is called "The Inmates are Running the Asylum" and will be published in April  by Macmillan Computer Publishing. The book expands on the ideas that you have asked about in this interview. It gives concrete examples showing how interaction design can improve the software development process and the products and Web sites that result from them. Make no mistake about it: Web sites are software just like any other software program. They have a small amount of new functionality, and many special limitations. However, those limitations are very temporary, and within a few years there will be no difference between traditional software and Web-based software.
[Note: The book Alan mentions above looks very interesting. I took a look at Amazon's Book Description, and it sounds like a winner. The price is right too, only $15 - John]
That happy, loyal users and likable, easy to use products can be easily created today without significantly greater cost than otherwise.
Browsers are not the only way to realize the
benefits of the Internet.
(This interview was conducted via email by John S. Rhodes)
Read another popular interview: CGI and Web Site Usability
Recommend this WebWord.com interview to a friend.
you want to know when new interviews go online,
subscribe to the WebWord.com Usability Newsletter!
© 1999 by John S. Rhodes. All rights
Do not reproduce or redistribute any material from this document,
in whole or in part, without explicit written permission from John S. Rhodes.