Alan Cooper访谈 2

[huoji]

II Accepting there is a problem

AC 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.


DJA 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"


AC 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.


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


AC Yep. Very true.




III Talking the Programmers' Language

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


AC 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.



DJA 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?


AC 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."


DJA 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.


AC 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.


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


AC Right! Cool is not a good design reason.