When I was presented with the opportunity to interview Donald Norman, I was delighted. Moreover, I had recently read a few chapters of his work-in-progress, The Invisible Computer, and was already integrating its tenets into my own systems development lifecycle. But Donald Norman is not an EPSS practitioner per se. Among many other activities, he helps to design things that - as his book title suggests - make us (consumers) smart. Among the many things that contribute to making us not-so-smart are the complexities of the personal computer as a do-everything device and the so-called continuous improvement of software embodied in new versions having more and more features - which really means more and more complexity. These are some of the common concerns of Don Norman and EPSS practitioners, which provides the backdrop for our conversation.

Gary: In your opinion what is wrong with today's software?

Don: At one level I don't think anything is wrong with the software. Much of it does a pretty good job considering the environment in which it has to work. Obviously there's a lot of just plain bad software but what I'm impressed with is how much is done reasonably well that on the whole I can use it to can get my job done without too much effort and too much pain. And I really believe that the pain in the problem has to do with the environment and the PC, and in the business environment in which software developers are forced to operate but not with any particular thing that they are doing wrong.

Gary: You made a comment that strikes close to home: "Blame and train does not solve the problem." That's where we all started in EPSS. The Information Technology (IT) departments would keep the training people out of the picture until the very last minute, when the problems of poor design were thrown over the fence to be "solved" with training. Of course, it doesn't work.

Don: It's actually worse than that. I've heard many stories in which the software designers are not allowed to talk to the customers. There is a belief that you have to carefully determine the specifications, then write them down, get agreement with customers, then hand them to the software team to implement. I believe that one of the reasons you hear "let's not have the software team talk to the customers" is because, in their experience, that leads to disasters such as ever-changing system specifications. If you believe in this linear ("waterfall") method of software development then it's probably quite appropriate to segregate the different players. The U.S. government not only believes in it but enforces it through the bidding process. Quite often the person who writes the specifications is not allowed to bid on the writing of the program. This enforces the complete separation of people and the time of these actions. Fundamentally these are completely inappropriate ways of developing software.

Software design is not a science where you can sit down beforehand to establish the parameters and then design. It requires experimentation and iteration. The problem with asking customers for the specifications is that they are not actually sure what specs they need. Moreover, if you do a good job with the software it will change the way they do their job and therefore the specs developed beforehand are no longer appropriate. We must substitute an iterative software design in which we work with the customer closely, try to understand what their work practices are, do a very rapid prototype of a system that we believe handles their issues, and try it out. It may just be a paper and pencil prototype, but it's the best we can do quickly. We may learn that it is what the customer wanted but in fact it does not meet their needs. We go back and redesign. We do this throughout the software cycle, ideally doing major redesigns in the early stages and only minor redesigns toward the end of the cycle. But you have to do it through continual interaction with the intended use, and that also means with the intended user. You still do requirements gathering, only in a mode that overlaps the software design phase.

Gary: In the performance centered design practice we talk about structuring tasks in ways that people actually perform their work. Is that consistent with your notion of creating representations (metaphors and visualizations that are abstractions of reality) in the user interface that match the way people perform tasks?

Don: Yes, the representations match the way people think and the tasks that have to be done. At issue, of course, is that if you're designing a new software system you will change the way people perform their tasks. It isn't just to do things that match the way people perform their tasks today, it's to match the way they will be doing them with the new system - which gives them new capabilities. Again the technique is to quickly try them out as much as you can before the system is implemented.

Gary: You said in your new book that we need to create a symbiotic, complementary strategy where the human being and the computer come together. Is this what you mean by system design not for the way people do their work today, but for the way that they will do their work?

Don: Right, and finding the right mix. The person will be doing certain things and the machine will be doing certain things. All too often what we do is try to figure out what the existing work practices are and try to automate the ones we know how to automate and leave people with the rest, which is usually the absolute wrong mix of activities for a person.

Gary: What are your feelings about the trends of the last few years in re-engineering?

Don: I believe that re-engineering was really intended to rethink the work practices and recognize that you can often redesigned them to accomplish the same goal more efficiently and to better fit the way people prefer to do their work. For example, instead of having many departments in a company where each one does a small but specialized aspect of a job, change it so that one person handles as much of the complete job as possible. Inefficiency occurs with the handing off. However, re-engineering has been primarily used as a way of downsizing the organization not because you figured out a more efficient way of doing things but strictly as an excuse to cut the number of people on the payroll. What re-engineering has turned into is not what I would advocate.

Gary: You advocate the shift from technology-centered designs to human-centered software designs. Traditional methods of requirements gathering where there's limited contact with performers and with the business owner tends to lead to more technology-based requirements than human-centered ones. How might we change the process so that we can still capture the engineering but not lose the human being in the process?

Don: The process I prefer is to start out with a requirements document that does not spell out the answers but spells out the issues. You start off stating what the goals of the project are, what people should be able to accomplish in a certain amount of time and in a certain number of steps.

Gary: This is a true performance improvement orientation. Traditionally, this performance improvement orientation was limited to transaction cycles, keystrokes and other technology-centered measures.

Don: Yes. Then, as you enter the design phase you figure out how to transform the requirements into specifications, but you do that by the method I analyzed above, working closely with the intended users. In consumer sales, there are three - sometimes four - groups of people who need to work together. First, user-experience people, the second marketing, and the third technologists; the fourth is manufacturing. In internal corporate software design there probably isn't marketing but you have the user-experience and the technologists.

Gary: Actually, if we thought about having to market software internally, we might be better off. We have a default assumption of internal captive users. And since they have little or no discretion over software "purchases", we ignore their preferences. In the consumer marketplace, we can't.

Don: That's right.

Gary: So you're suggesting that we try to get all of those groups together at the statement of the compelling business need....

Don: ...and the design team ought to consist of representatives of those groups, but you don't want the design team to be too big. Marketing tells you what really sells, what people are willing to pay and what their usage patterns might be; and user-experience tells you about point-of-sale attractiveness in the design and a lot about the day-to-day usability of the product, and technologists tell you what's possible, what it is going to cost, and what the time factors are. Those three are often opposing requirements and the end design is a tradeoff among them. That's why they ought to be equal partners. In my user-experience group I include the people who do the documentation, who write the specifications, the people who do the field studies, the people who do the rapid prototyping, graphics design, and rapid testing.

Gary: Those who you mentioned last are where 70-80% of the practitioners in performance-centered design come from - documentation specialists, instructional designers, and interface and graphics designers who started out developing learning materials on computers and realizing that instructional elements had to be embedded in the interface. In this regard, do you see things like the wizards and cue-cards that are present in popular computer applications as addressing human factors?

Don: The real questions is, why are they necessary? It seems to me that if the software were properly designed they wouldn't need to be there in the first place. They seem to be necessary because of the complexity of the systems. My goal is always to remove the system complexity in the first place. Then you won't need wizards and guides and help systems.

Gary: Amen. Unfortunately a lot of design happens as a result of business owners observing what is on the market and inferring from them lists of requirements such as the wizards, embedded training, and cue cards. This is unfortunate because what we really need are applications with interfaces that meet the business and human needs without all of these add-ons.

Don: That's what I was referring to earlier when I talked about the poor environment in which software developers are forced to work. In my case the marketing people come and tell us what the competition is offering so we should offer the identical list, plus a bit more. So the way you make money is by selling new software to people who might have been perfectly happy with their old software. The new software has to have everything the old software had, plus something new that you can argue they should buy -- which guarantees to make it more complex.

Gary: In your chapter "What's wrong with the PC?" you note that the home has a number of specialized appliances which, with the exception of setting the clock on the VCR, are easy to master and easy to use. Are you suggesting that the PC could be simplified to, say, a number of instances of it that are more like appliances?

Don: Yes. Actually, the reason you have trouble setting the clock on the VCR is that it's a bad design. You should really ask yourself why you have to set it in the first place. You don't really want to record a channel at 3PM, you want to record a show. The goal is to simply specify the name of the show you want to record, and let the system take care of the rest. That's the way in which I look at problems. When somebody says, "How can you solve this problem?" I step back and say, well, why is that a problem? Maybe we should just get rid of that as a problem in the first place.

Gary: On the issue of putting the right people on the design team, you talk about Thomas Edison and the errors he made. Are you suggesting that he may not have made mistakes, such as manufacturing the cylindrical phonograph record, had he included the right people on his team?

Don: No, the problem was that he was first and foremost a technologist and therefore analyzed what he thought to be the best technological features of a device, and then insisted on providing it. He put too little weight on the user's plight. The cylindrical phonograph record was a superior methodology to the disc, cylinders are really clumsy things to handle and store, whereas discs are really very simple. Those were the beginnings of the market considerations that Edison was insensitive to. Adding more people to his team would not have made any difference. Certainly the issues were pointed out to him over and over again.

Edison was also investigating alternating current (AC) motors and generators, but he decided that direct current (DC) was superior - so he insisted on delivering DC to the homes. In the end he was to lose out. It wasn't because he didn't know or because of the technological challenge. He was a technologist, and he shouldn't have been making business decisions.

Gary: My developers often get stuck on a problem that presents the greatest challenge and the greatest satisfaction to solve, even if it's irrelevant to the ultimate system goal. That's why I've always felt that the right mix of people on the team - the human factors engineer, the educator, et. al. - can serve to pull the technologist back from such challenges.

Don: Yes, but having the mix is only a part of the solution. It is really valuable to have people who are not involved in the product at all come and look it over periodically, but not the same people over and over. Once you've worked with something for a while you come to understand it and to like it and think there's no other way, or you're satisfied with the way you've met this particular challenge. It's very difficult to let go of your pet ideas.

Gary: You've suggested that there's a certain amount of variety that's necessary to keep people from making errors that come with too much repetition. On the other hand, the need for simplicity is a theme throughout as you note how terribly complex software is becoming. How do you reconcile these two views in the design of software?

Don: You have to realize that the software is not the end result, but a tool that allows you to accomplish work. You want the interest to come from the work itself, not from the use of the tool. Ideally you want a tool that's invisible, that doesn't get in the way. I don't think that making the tool interesting is the correct approach. It's making the work interesting.

Gary: Do you believe that day-one performance is achievable? Performance-centered system designers often say that they design in order to scoop people off the street, sit them in front of their systems, and have them performing immediately. What is your response?

Don: No, I'm concerned about that. The critical thing is that complexity is governed by the task that is being performed and not by the tools, and today it is often the tools that take up the learning time. What I would like is that the tools require minimum training, but that doesn't mean you can take someone off the street and have them do the job right away. My goal is not to have zero training, but to have one-time training. If I don't quite understand a computer system immediately but when someone explains or shows me, my response is, "Yes, I see...of course...." and I never have to have it explained again.

With software the tools that are available are limited, namely you have to make visible on a screen, with keyboard or pointing device, what the actions are, what the results will be, what you should do, what is possible at any given time. It's not clear to me that we can ever really hope to have complete obviousness. But it should be done in a way that isn't so arbitrary that I have to have it explained to me over and over and over again.

Gary: But sometimes a checklist is in order. I don't remember how to change the brake pads on my car or re-tile the bathroom, but I've done both with checklists.

Don: A checklist is an admission of complexity, that there are things that can be skipped or missed or done in the wrong order. It would be nice if the task itself constrained the ordering, but yes, the point you are making is correct.

Gary: In closing, is there something in software that you've seen that has impressed you and something that has disappointed you lately?

Don: Lately I've been using the Palm Pilot, and I thought that they worked through the usage model quite nicely. I like to contrast the Palm Pilot with the Apple Newton, which is superior technology. Apple worried a lot about what chip they should use, the operating system, and making it truly object-oriented. It has advanced programming concepts in it that makes it easy to do a large number of things; it has a far superior screen, and fairly good handwriting recognition. What they neglected to think about was why anyone would ever want it. The Palm Pilot is inferior technology, it's hard to read, the back light is a joke, the processor and operating system are very simple, BUT they learned a lot about why somebody would want this - and did a fantastically good job. I use my Palm Pilot every day. I have three or four Apple Newtons at home...rusting.

Also, I've been using Lotus Notes, and let me tell you that I think it's a horrible system. It's very difficult to do the simplest thing. There are agents and templates of various sorts, and I just don't know how to use them or what to do with them. So we have a big support staff, which has got to be sign of bad software. Lotus Notes, to my mind, is not made for normal users. I've had this conversation with a fair number of people at Lotus, including Ray Ozzie, who invented it in the first place - and so far no one has disagreed with me. A problem is that the Lotus development division has essentially zero contact with the world-class experts in the research division. And notice that whenever you go to high tech conferences and talk to high tech people, they always use paper and pencil to take notes.

Gary: I've seen Ted Nelson, the father of hypertext, wandering around conferences with a pad and pencil dangling from his neck for quick note-taking.

Don: We always thought Ted was smart.

Gary: And that's a perfect way to sum up what we've been saying. Technology needs to reflect the best practices of doing work effortlessly.