Back around New Year 2000, I was considering how best to replace the Book Reviews at uidesign.net. It seemed that rather than analyse what the authors had to say, it might be better to ask the authors directly - Interviews. So I was left with the next big question, "Who do you ask to do the first Interview?". The new site branding and slogan, "The Webzine for Interaction Designers" provided the answer. It had to be Alan Cooper. As author of two excellent books, "About Face" and last year's "The Inmates are Running the Asylum" he is the founding father of Interaction Design and perhaps its greatest advocate. To my surprise he said yes about a month later. The eventual result was an 80 minute phone call on Friday 11th February.

You don't so much interview Alan Cooper as the whole Cooper Interaction Design media machine. All the questions were submitted in advance for approval. It was to my surprise then that we strayed off the script right at the beginning and never quite regained the plot. The result was a fascinating 80 minutes of conversation which did much to help define what uidesign.net is all about and to lay out the road map for areas that Interaction Design needs to address. In part 1, Alan takes his time to explain exactly what he means by Interaction Design and why it isn't Interface Design and exactly what role Interaction Design plays in the whole gambit of User Centered Design disciplines.

Before the interview started I really thought I had some chance of holding my own with Alan Cooper. I thought I knew a bit about Interaction Design and I could ask some intelligent questions. We had a good script and we had an hour of his time. However, what was intended to be an Interview immediately became an audience with the master. It became difficult to slide in the questions as Cooper began to tear up the rulebook for the technology industry and throw it out. He discusses why Interaction Design is about complete systems architecture and he hits on what's wrong with relational databases; what's wrong with file systems; why Interaction Design is a lot more than Interface Design; and why he really doesn't like Usability much either.

We kicked off with an introduction to uidesign.net and a discussion of the audience and the message...

uidesign.net audience is probably what I would call, "Programmers who realize that programming alone doesn't solve the problem". That realization is the necessary first step to solving the problem. There are programmers who believe that the solution is a programming technique that they haven't been able to learn yet.

That's a problem. It's focusing on the technology alone that has gotten us into this mess and focusing on technology just isn't going to get us out of it.

It's like treating someone with a dependent relationship, the first step in curing someone is that they must admit that they have a problem.

I liked the focus in your book on an industry in denial. I could empathize with that. A lot of stuff that gets written makes me think, "Yeah, these guys are still in denial"

Yeah. And in the web world, it's just as prevalent, if not more so. In the PC world there was a lot of money. You could be in denial and still be having a financial success. In the web world, you can be in utter denial and be having a huge financial success because of all the distorted valuations. It's very easy to hide a bad user experience.

Yes, I'm sure. Investors won't see an advantage in improving a site that is worth 9 billion dollars already?

So tell me, how important was it to be in California in order to make an Interaction Design Consultancy work?

Well that's a good question. I like to think that it wasn't that important but the Silicon Valley Juju goes a long way. There are a lot of people, particularly in the web world who view Silicon Valley as the place where you go to get the answers. California was certainly a contributor [to the success].

The landscape is different today but in 1992 when I began doing Interaction Design Consulting, what really made the difference was that I had firmly established credentials as a software developer. Had I not had those credentials, I could not be doing what I'm doing today.

Designers as a whole tend to come from the world of visual or typographic design, or they come from the academic world of Human Computer Interaction, Usability Professionals, Ergonomics, Human Factors, where basically they are using quantitative methods to document human behavior.

Programmers know how hard they work and they know how difficult their job is. I'm not sure that those visual designers or those usability designers are aware of that. But I'm aware of that. I know that, as I say in the book, you need to have "skin in the game". You have to be committed. Not just prepared to stand on the sidelines and toss their advice in to the guys hitting hard - the programmers.

One of the significant secrets of Cooper Interaction is our willingness to have skin in the game. To get in there and do Interaction Design with the same level of rigor and the same amount of detail that programmers put in to their work. I don't think that Usability Professionals or Visual Designers do that. Simply because they don't have that code cutting background. They don't know what it's like.

So are you saying that Cooper Interaction is capable of specifying requirements for the User Interface to programmers in a way that the programmers really appreciate and it makes their job a lot easier?

Yes. I am saying that but the main thrust is a little more nebulous than that. Programmers are not interested in making change for the sake of it. That means they have to do hard work on those changes. Programmers work very hard but they are very practical, logical people and they hate to make pointless changes.

Something we learned a long time ago is that HCI Professionals tend to guess at things and Visual Designers tend to guess at things. They say, "Well I think this looks pretty". HCI Professionals might look at it and say, "Well people are having trouble with this interaction. So I guess we should move this over here."

Yes. I know what you mean. The programmers get jerked around producing 5 or 6 alternatives, so that the bosses or customer can make a choice. There is resentment to this because the programmers feel that the design should have been done properly the first time.

Right!

Designers and traditional HCI Professionals, because they have never written code, they just don't know that. And they don't have a sensitivity for it.

I think that's a much bigger deal.

If you can say, "Here's the right idea", and somehow through a track record you can show that you know it's the right idea, then programmers will bend over backwards to make it happen for you. It's not about the ability to specify the design in programmers language, although that's a nice thing, it's a valuable thing, its an appreciated thing. The more precisely you can specify something, the better it will be rendered by the programmers.

The most important thing is that I am saying, "People who haven't coded, jerk the chain of programmer's". People who understand the programming process and come at it from a developer's point of view, don't do that.

We walk into a client and we say, "We're going to make a presentation and we're going to lay out our design". And we're usually doing this in front of management, marketing people and programmers. Programmers will say, "Why do you do it like that? Why do you not do it like this?" They never ask stupid questions. A programmer will always ask a good piercing important question. You can't look at the guy and say, "well we thought it would be a good idea", or "well we guessed it should be like this", or "we had 10 people try it and 7 of them liked it that way". Programmers know that is bogus!

We look at programmers and we say, "Because of this truth", "Because of this fact, we know this is better".

We tell our design team, that when they go into a meeting with a client, they should know at least 2 reasons why they made any one design decision. If you don't have at least 2 good reasons, then don't try to defend that design. It's not about preferences.

So it's not enough for a designer to turn around to a programmer and say "It's cool!"

If you have a good design rationale, if you know that people are going to be searching for information in this place and this is an appropriate way to present choices to them and all other things being equal then presenting it in a cool way - I'm all for it - but there are all sorts of cool things which are cool the first time but the 10th time you use them, you hate them. So what you have to do is to say, "Who is going to use it?", "Is this going to be used by somebody once?" You can do cool stuff in a kiosk that someone is going to walk up to once and use just that once. That's OK.

If someone is going to sit down in front of it and use it 10 times per day for the next 3 years then you have got to get that "cool stuff" out of there because it's just going to get in the way.

We believe that good design is self-evident.

So that you can look at it and say, "Yeah. That is superior"

If you as a developer do not see that it's superior then you are probably not going to build it. Regardless of what rationale or what orders you are given from management.

I'd like to explore this point that good design is self evident. I often wonder whether the general public are able to follow when designers make a leap forward rather than just a minor increment. Their initial reaction to such radical changes is often negative because they are conservative and don't understand.

I wondered if you followed the debate about the development of the Swing Look and Feel ?

I confess that I didn't follow it.

To give you some background, the Organic L&F tried to follow advice from Don Norman and Edward Tufte. It was a very flat and clean looking design. No 3D. Minimal on screen clutter. The approach was arguably the better and more promising design but it was too radical. What Sun ended up with was Metal, which was kind of a compromise Windows look with Sun Corporate colors.

I don't consider that Interaction Design. Look and Feel stuff is Interface Design. It's all very stylistic. It's the color that you paint your walls. Interaction Design is about the Architecture. It's what kind of building are we building. What functions does it support. What are the shapes of the rooms and the walls and ceilings. What is the infrastructure. What kind of elevators. What kind of cooling and heating. That's Interaction Design.

Jerry Weinberg wrote about this a long time ago in "The Psychology of Computer Programming". What language is best? The language that you like best! So what's the best indentation method? The indentation method that you like best. And what's the best L&F? The L&F that you like best.

This just doesn't address the significant issue, which is Interaction Design! What does it [ the system ] do? How does it communicate? How does it behave? These are the fundamental issues.

Let's look at database queries. You issue a query to a database. It hands you back a solution set. This is a technology that's known. What we do is that we debate about how to have little dialog boxes to submit queries and display solution sets. That is interface design!

People generally don't ask fundamental questions like "In a situation, where I have a particular User, who is trying to accomplish a task, who is trying to achieve a goal, what are the appropriate methods of information retrieval for that person?" Would it be a query and solution set as the way to solve the problem. That is an Interaction Design question. It's one that is not often asked. But is the type of question that we ask here [at Cooper Interaction Design]. It's a very very different approach than asking "What should the dialog box look like".

So this is the key point about Interaction Design - it's Architecture - and everything else is merely Interior Decoration or Construction?

Yes. Yet the word Architecture is problematic. To come back to the database example, the query and solution set is based on setting a series of arguments for the search and then returning a subset of records that satisfy the arguments. This is the classic query and it's the reasonable thing to do if you're doing Operational Data Processing. If you're a human being who is trying to make sense of that Fire Hose of data coming at you, that query may in fact be obscuring the answer. This is the search engine problem where you get 4 million hits and you refine it down and you get 800,000 hits and you refine it down and you get 50,000 hits and you narrow it down and you get no hits.

The query tool is a very powerful one if you are trying to match invoices with purchase orders but it's a very poor tool when you have a human being who is trying to find out about adverse toxic reactions between drugs when intermixed.

Right! So it's Technology rather than the Goal.

I guess I've written about my own experience with the Seat Reservation System on Air New Zealand [Sept99]. The problem there was the optimistic locking mechanism in the database and how that exposed itself in the interface. I realize that you've written about this too and Seat Reservation Systems seem to be a pet hate or yours?

[laughing] Yeah, Seat Reservation Systems have been around a long time and they are a great resource but they are the kind of thing that only a trained user can use effectively. If you've had the experience of talking with a travel agent, you clearly get the sense that the travel agent is not finding the right stuff for you. Well that's a clear indication that they don't know how to work the travel system, not because they don't understand the travel business.

The point is that, if you are a Visual Designer, or if you are an HCI Professional, or even programmers you tend to approach things from the point of view of saying, what are the technological tools at your disposal. You say, Oh, I have a relational database. Therefore, I can issue a query and I can get back, in a batch mode, a solution set of a reduced number of choices.

You might have a real world situation where you have someone who walks into a library and searches based on a Dewey Decimal Categorization System number and then wants to see a list of related books. The query system fundamentally disallows this.

There is this whole class of human behavior which is not supported by the relational database query paradigm.

I'm not saying that this is a bad paradigm but pretty much all data retrieval in computer systems is based on that relational database query and solution set model. Because it's easy, programmers say, "Well that's how you do it" and it never occurs to them to ask whether this is the way that people want to look for information.

So is it the case that Technologies and their limitations are not well understood and people expect far too much from a technology that was never designed for the purpose?

You have to be careful here. I believe that in the Industrial Age we had technology. Technology had firm limits dictated by physics. Steel is a wonderful building material. It's so wonderful that I can build skyscrapers and bridges with it. But what you can't do is say, "Steel is so Wonderful that I'm going to build a bridge across Lake Michigan out of 500lbs of steel".

Right! But you can do this with software. Or at least you can try?

You got it!

In the Information Age, in the Digital Age, the limitations are not imposed by the fundamental characteristics or the physics of our devices. We have computers that go plenty fast but if there is a limitation then you just buy a few hundred thousand more and make them work in parallel.

What we are limited by is our imagination. We built databases, and big companies like Oracle who build giant relational databases tell the world, this is how information is stored, this is how it is massaged and this is how it is retrieved.

This is like saying all bridges are 30 feet long and formed into a truss. Well in the physical world if all you had was wood then that is true.

A programmer comes at a problem from the point of view that there are only 3 numbers: 0, 1 and infinity. So a programmer says, well if I'm going to create a database, then I will create a technology that will support an infinite number of records. That's the way they think about construction. But what if you're building a name and address book to run on your Palm Pilot?

You will never have more than a couple of thousand entries. All that incredible efficiency, all that factoring out of common information and storing things in little fields, is really good when you have to have billions of records. A friend of mine designs data stores for companies like Wal-Mart and he deals with a billion records per day. He has issues like how do you normalize everything? How to make everything fail safe? Applying that technology to 5 or 6 hundred names in a Palm Pilot is inappropriate.

On the Other Hand, the designers say that it doesn't have to be a massive redundant, fail over system, but they still use the same basic model, of a database with fixed length fields, key searched. Why can't I logically group things? I can categorize things. I can say, here is a name that belongs in my list of business names, here's another which belongs in my list of personal names, but I have lots of names that need to be in both lists. I'm not allowed to do that because the Interaction Designer didn't think in terms of what Goals is the human going to try and accomplish. Instead they looked at the problem from the point of view of "What technology am I given".

Right. And it may well be the case that the Interaction Designer was brought in at the end and told, "This is the data model, and this is the type of query it supports" and then there is not much that they can do.

The no.1 thing that you can do to create a better product is to bring the Interaction Designer in early.

What you'll find is that Visual Designers brought in too early will freak out. An HCI Professional brought in sufficiently early will freak out because they have nothing to do, nothing to measure. They don't know how to design software which actually solves problems.

A real Interaction Designer will rub their hands with glee and say, "Oh Boy! We have an opportunity to do something really good here"

Continued...