In-Depth
Simplify Web Development with Visual Studio 6.0
Web Builder is reborn.
The paradox of Alan Cooper becomes apparent when you enter his conference room. There on the credenza is a picture of Alan with Bill Gates at Windows World, next to a plaque honoring Alan as a "Windows Pioneer" and as the "Father of Visual Basic," the most popular development language in the world. Alan developed Ruby, purchased by Microsoft and used as the foundation for Visual Basic 1.0. Paul Freiberger and Michael Swaine, in their history of Silicon Valley,
Fire in the Valley (Berkeley: Osborne/McGraw-Hill, 1984), credit Alan with creating the first shrinkwrapped software package. Despite this legacy, calling Alan a programmer today would earn you a tongue lashing and strong protests that what he does is not programming at all, but something totally different: software design.
Download the code
for this article
Design as practiced by Cooper Interaction Design (CID), the Palo Alto, California firm that Alan co-founded in 1993, places the user first—ahead of the preferences and conveniences of the software designer. Whether it's designing development tools for Elemental Software, mouse configuration software for Logitech, or in-flight computer systems for Sony, Cooper Interaction Design breaks down assumptions, challenges tradition, offends programmers, and creates applications that have a unique way of interacting with end users. Development Exchange Editor and Producer Matt Carter sat down with Alan and CID principal interaction designer Wayne Greenwood for an in-depth look at how Cooper creates methodologies that try to bring development to another, more user-friendly level.
Cooper on the Differences Between Traditional Software Design and Design for the Web
"First off I think that there's no difference between Web design and any other software design. I mean, it's like saying, 'I'm a house painter. I paint stucco. Don't ask me to paint wood—I paint stucco.' I mean, what's the difference? For wood, you may need to use a primer that's unnecessary for stucco, but the skills are the same. Although the tools may vary, it's only in a minor way. I think that there are a lot of people who don't get that, who think it's fundamentally different, and it's not. It's gotten to the point now where a lot of people want me to rewrite my book, About Face (IDG Press), so it's about Web design. That's like saying 'rewrite your book on painting so it's got a lot of wood in it.' It's about principles, and they are the same in software design and Web design. It turns out that what this is about is interaction design.
The Evils of "Submit"
"I have a big problem with Web design paradigms. Web sites have 'submit' buttons, and they have 'submit' buttons because of the limitations of the existing designs, and the fact that people aren't looking at different ways to accomplish user interaction beyond 'submit.' Much of these limitations come from what I call the 'invasion of the lightweights.'
"This is nothing new. Programmers have always been up against the invasion of the lightweights. First you had the machine-language programmers who looked down their noses as the assembler programmers, then assembler programmers looked down their noses at C programmers. Then, the C programmers looked down at Visual Basic programmers, and now you have VB programmers look down their noses at CGI/Perl hackers. It's a pyramid: each new invasion is a much larger and population. The current invasion of lightweights doing Web development is the largest of all: it's millions of people.
"The current crop of lightweights doesn't have any idea of the history of application development. They don't know what can or can't be done. The C guys know they can mess around with memory but don't play with the clock speeds, which assembler guys take for granted. The VB guys think in terms of, 'Wow, look at the neat ways I can combine components,' but don't often think about building their own components. Now you have Web guys whose goal is to communicate ideas bi-directionally with the audience, and to them it's all done with the 'submit' button, and they don't rethink this paradigm. There's nothing inherent about Web design that says you need to have a 'submit' button. It's that nobody has thought beyond the 'submit' button, so now we have the 'submit-button paradigm.'
"What we've done is taken the sophisticated interaction we have in the C world and reduced it to 'I'm totally stupid until you hit 'submit.'' This isn't something new: It's called mainframe computing. Lightweights don't remember that mainframes were gleefully destroyed by the thousands in the '80s when the PC came along liberating people from that stupid, bad, limited behavior of computer interaction.
Install Programs: One Step Forward, One Step Back
"Now that there are these millions of people designing Web sites, I see usability getting better and worse. For example, I've been ranting and raving about install programs for years. The general attitude in the industry is 'well, yeah, but you need to have an install program.' Everyone goes out and uses the same install program, and it's the same piece of crap software asking the same questions, and that's the way it is. Nobody thinks, 'what if we get rid of the install process? Can we get rid of the install process?' So they go on that basis.
"Any enterprise-level software vendor today is building all their software for the Web platform. You ask them, 'Why?' and they will all tell you, 'It's easier to configure. There's no install program!' It turns out that nobody would admit this when you had to install, but installing is a huge, nightmare problem. Then the Web comes along and people say 'Oh, new Web technology means you don't have to install.' That's a piece of crap.
"There is no new technology brought to us by the Web: All the Web does is place pictures and pieces on a computer screen, while communicating over telephone lines. What happens is that the browser gets installed and people run their Web sites inside the browser and say, 'If I take away this capability from my software and people can run it inside the browser, I don't have to install.'
"And all the old-school programmers are saying, 'Oh god, you can't do that,' and the lightweights down at the bottom say, 'Why not?' Now there's a whole new generation of programs out there that don't need an install, and every IT manager in the universe is saying, 'This is much better!' This makes usability much better than before.
"Why is it better? No install. My question is, 'Why didn't you get rid of the install in the C program?' They didn't because that was the way they always did it. It took this new technology paradigm to just change people's mindset but there's in fact no difference, no reason to remove install programs from C++ programs.
"So, what we've done on one hand is introduce 'no installation,' where the industry had no depth perception, and guys like me are saying, 'Take your hand off of your eyes.' Now lightweights come in with no depth perception and eliminate the installer. One hand gives, one hand takes. We get no installs, better device independence than Bill Gates was willing to give us (and a lot better device independence than Apple was willing to give us, and better realizable device independence than Unix gives you without a Ph.D.). And so you have all that independence, and no install, but then you get really bad interaction tools.
The Role of the Browser
"Frankly, I think that the role of the browser serves the same role as the elevator does in architecture. Every office building has elevators, and they serve a very useful purpose by getting people to their offices. But nobody actually sits and works in an elevator. What we've done is this browser thing has become the elevator, but we have people working in it.
"I think it's foolish to work inside the browser. What does the browser do? It's like an explorer. Microsoft is totally right and the government is totally wrong here. It is an explorer, and who's to say where the operating system begins and ends? All the Finder or [Microsoft Internet] Explorer does is allow you to peruse information in a structured store. And all the browser does is allow you to look for information in the Internet, this huge sea of information. And when you find a piece of information that is of interest to you, you download it. Chunks of text, chunks of very primitive display specification code, sounds, and you can also download code. Right now we say the only piece of code you can download is Java that runs within the browser.
"On the other hand, I've gone out on the Internet and found code like a little audio CD player. It comes as a ZIP file I have to install. And when it's finished it's a little piece of code that runs on my computer. If you added a little piece of functionality to a browser that installs programs in your systems and then hands you the reins in your operation system, then the browser is an elevator. It means that you surf to a location and it says, 'Yes, I'm a piece of interactive software.' You go to CDnow, fill your order basket and then click on 'submit.' It's already delivering interactive software, only very intensive on the audio and text, and very light on the software code. You're spending plenty of time on this site: You can be downloading a lot more code during your visit, and it doesn't have to run inside the browser.
"To do a context switch in Windows is instantaneous. You hit a URL and the program downloads. Boom, you have sophisticated interaction instead of the mainframe model that relies on the submit button for anything to happen. The browser is the elevator that takes you to your office.
Delivering Both Power and Pleasure to Users
"Our corporate motto is: 'We create software that delivers power and pleasure to the people who use it.' We believe in power and pleasure. There are a lot of people out there who believe that the way to deliver pleasure is to dummy down the software. The idea is: 'You're having a hard time understanding Microsoft Word? I'll throw out all the features, then you will be able to understand how to use it. I can make it easier to use if I just make it more stupid.' This is true, although you can design an interface with a single feature that is unusable. We believe that you can leave in a thousand features and make it easy to use, delivering power and pleasure. In the Web paradigm, the way you achieve pleasure is by throwing out the power. So there is this tiny set of things that your browser can do, and they are all stupid and unhelpful.
"The Web has created this medium with millions of people saying, 'How can I tweak this? How can I take the given limitations and cheat and work around it?' Within the browser, everyone is cheating left and right: 'Whoa, man, we can cram the code down the throat of the browser and make it do something. There are only 17 tags in HTML so let's add a tag.' So you add one tag, then you can add another tag, and then you have the point where a tag may be compatible with only version 2.0.a release 4.
"The level of hack thinking that's going on in Web programming makes me want to scream, 'Hey, it's a Pentium II 300 MHz! Write a damn program that does stuff and get the hell outside of the stupid little (browser) box!' You want to have it download from the browser? Write a decent program that interacts with the user, that has rich feedback, and talks to the server when it needs to. It doesn't matter if it goes out through the same TCP/IP connection as the browser, it's just a wire and bits that talk on it.
"But we're not talking about programmers building much of the Web, we're talking about lightweights. In the short term it's chaos out there. In the long term, I believe that the vision I've described about breaking out of the box and making the browser the elevator will prevail. Staying within the browser has no upside: you're hobbled.
Thinking Like a Person, Not a Microprocessor
"Programmers think in the first person. They put themselves in the shoes of the CPU—'OK, I'm going to go out and put this information in the buffer, then I'm going to move it to this part of the memory.' This process helps them role-play as processor. It helps make programmers good at programming. Our job as designers is to role-play as users. We ask, 'what would the user be doing right now?' The trick to it is that when programmers play this game, they don't actually role-play. They say, 'Hmm, if I was using this, what would I like?' I mean, programmers have great skills, but inhabiting another human's shoes isn't one of them. They can imagine being in the processor's shoes, which is a tough task, but when it comes to thinking like one of the users, they can sort of pretend they do, but in fact they can't. It gets back to the point that we call 'self-referential design,' where a designer adds features that he likes. What we do at CID is actually put ourselves in the shoes of the users.
Getting into Clevis McCloud's Head
"Part of how we do this is that we are rigorous in defining who the user is (see sidebar, "Personas in Action"). On the Sony project for example, there was Clevis McCloud. He was our primary persona. He was the 65-year-old Texan with a touch of arthritis, and we had to get inside of his head.
"Instead of getting inside the heads of the users, programmers go 'Oh, cool, let's add these extra functions.' But if you show the results of that process to Clevis, he will ask, 'Isn't there a simpler one?' Clevis would walk into a high-tech AV room with laser discs, DBS units, and 12 remote controls, and ask if you had a copy of The Wall Street Journal for him. He wants fewer functions. Once you can get into Clevis's shoes, you can begin to ask and answer questions about design. There are a lot of other tools we use, but the fundamental basis of how we do our design is getting to the point where we identify a guy like Clevis.
Why Making Everyone Happy Makes No One Happy
"The way to not satisfy two users is to design for both. The way to satisfy both is to pick one to design for. In the Sony example, Clevis is no stupider than Chuck, he's no less accomplished than Chuck, and he has no less strength of character than Chuck. He just doesn't want to look stupid.
"For example, I just got back from flying a small airplane. Why? Because I like to immerse myself in complexity. But if I want to go somewhere I can fly United: It's a lot simpler and a lot easier and frequently cheaper. What happens is that flying the small airplane works for me, but it wouldn't for Clevis McCloud. Flying United works for Clevis, but it also works for me. It's so simple.
"You then say, 'OK, but what about all the options that Chuck or myself like?' Fine. What's wrong with adding options as long as you don't add options in the Clevis McCloud world. We start by saying, 'Here is Clevis, here's where he starts, and here's where he needs to finish,' and you do the same for Chuck. What programmers do is say, 'Chuck goes farther so we will make the path work for Chuck.' This then puts all of Chuck's complexity in Clevis's critical path. This is why computers are hard to use—programmers are really sympathetic to Chuck, and they say, 'After we deal with Chuck, we'll deal with Clevis.'
"In this case, knowing Clevis led us to the understanding that we cannot have a complex user interface. As programmers we constantly say, 'People want and need flexibility, and the great thing about computers is that they offer lots of options.' So, 'You can't take options away from people' is the mindset that most programmers have when they approach the task. We approach this in a different way, which is, 'Every time you offer an option, you've just poured a little vinegar in your chardonnay.' So you can't do much of this without destroying the work.
"As designers, we are really sympathetic with Clevis as our primary user persona. So we create Clevis's critical path first, and plan for everything he needs to get the task done. Then, for Chuck, who wants all the fancy and feature-rich stuff, he sees that he can go past Clevis and get to where he needs to go.
"A common mistake programmers make is that you have to offer the options up front, and in fact, the people who want the options are the ones who are willing to go through the extra steps to get to the options. The people who don't want the options are precisely the ones who are not willing to wade through the extra options to not get them. So programmer-think says you have to surface all the options and let them know what is going on. The simplicity of Clevis's critical path doesn't bother Chuck, but adding the complexity to Clevis's critical path kills him dead. Makes it completely unusable.
How We Succeed
"None of the pieces of our methodology are hard, but sticking to it is hard. I mean, driving a race car is pretty simple, but to be successful at it, you have to do it under extreme pressure and for four hours. Identifying a guy like Clevis isn't hard, it's keeping him in mind throughout the design process that's hard. Being able to define him, weed out the others, and inhabit him, all of a sudden we come to very simple solutions.
"We start with a whole bunch of people, and role-play this person and that person, and begin to collapse them down. Soon we have it down to five personas. If we try to make the nine-year-old kid happy, we make others unhappy and soon we found that Clevis was our common denominator. And we know by thinking like humans rather than like computers that the exact opposite is true, so you pull back the options. A lot of software has gratuitous functions that can be thrown out, but you don't need to throw them out to make it easy. It's a matter of picking one person to design for.
"It's counter-intuitive that you can make a broad success of a consumer group by being very narrowly focused. A good example of this is roll-aboard luggage. The roll-aboard was not designed for a mass market. It was designed by and for airplane crews who spend their whole day getting on and off planes. Then the people who sit in the front of the plane go, 'Oh, that's what I need,' and ask the crew where to get the roll-aboards. Then the other passengers see it, and now you can't buy luggage without a handle and wheels.
"The luggage industry changed not by designing for the mass audience, but for a specific niche that's deliberately not in the mainstream. They achieved the goals of this niche in a very real way. They did a bang-up job and made the niche really happy instead of trying to make everyone sort of happy.
Why Programmers Are Handicapped
"Goal-directed design is so counter-intuitive, so illogical, and so insanely effective. And programmers are completely and utterly handicapped because they believe that logic conquers all problems, and it conquers only a certain class of problems.
"Programmers are constantly broadening, trying to add more features. The key phrase used by programmers when you are about to get screwed by them is, 'Well, someone might want this feature.' Whenever you hear the phrases, 'Someone might like...' or 'Someone might want...' it's the sign of a doomed project.
"Programmers logically think, 'If you want to be a success in the marketplace you have to have a lot of people who really like your product, so you need to go for the broadest possible market.' And this is wrong, totally wrong. It's rational, it's reasonable, it's intuitively accurate, and it's wrong. The way you get a big success across a broad marketplace is by not aiming at the broad segment of the market.
Bridging Logic and Brilliance
"Engineers say, 'Just give me the methodology. I am an engineer: Give me the specs and I will design in a good user interface.' It's like saying, 'Give me the algorithm for love and I will have a great relationship with my wife.' They aren't in the same universe. You can't apply engineering tools to designing usability into software.
"I don't want to imply that engineering or programming isn't creative, because they are, but there are other things involved, like logic. There's another issue here: There is this idea that software design is either a methodology or it's just talent. A lot of people think you get good design by finding these great people with this innate magical skill. They consult their muse and then they come back with their sketch. There are a lot of people who like to think that, but in our experience, sometimes they come back with something that is good, and sometimes they don't.
"In our experience, most of the time they don't come back with something that is good. I mean, look at a guy like Andy Hertzfeld. He did some great stuff when he did the first Macintosh. He was a clever, brilliant guy who had good ideas. But 14 years later he went to work on MagicCap (the General Magic interface for a Sony PDA device in the mid-1990s) and he said, 'Oh, I'll go and have brilliant ideas again,' and his ideas didn't work, and the company stumbled. And it's not because he's a bad guy, but you can't depend on inspiration. It's like finding a twenty-dollar bill in front of your house one day and going outside the next day to make some more money.
"These are the two poles: It's all in the algorithm, or it's just brilliant people who have brilliant ideas. We occupy the central area that says, 'you've got to have a method.' Like any expert, the real usefulness of a method is to know when to break it. To me, what we do isn't that difficult. When programmers reflect on what they do, it doesn't seem that difficult and yet it's incredibly difficult. It has a lot to do with your point of view. If you can think like a computer, it's not tough.
"It's sort of like watching Andre Agassi play tennis. If he can empty his mind and 'be the ball,' he can just make these awesome shots. And that's kind of what we do. If we can inhabit the people and empty our heads of all this extraneous technology stuff and solve problems from this user-goal-directed way, we can solve the problems.
"You have to have some talent too, but it's not all about getting talented people. The central point to our method is that it's about training. People come in here and they have some talent and we give them a methodology and they work through the methodology to come to a solution working in conjunction with more experienced designers. It's not about personas, although personas are incredibly important, and it's not about skills. It's about mixing the two in the crucible of training, and what you have there is a designer who can walk into a situation and solve problems.
Hope for Programmers Designing Software
"I don't think the typical development shop can take our methods and go out and do good design. I think you need good designers to do that. On the other hand, being completely insensitive to the needs of design makes you go out and do really bad things. I've seen this from readers of my book, About Face, who are primarily Visual Basic developers. They send me e-mail telling me the book completely changed the way they write interfaces. From my point of view I'm a critic, so when I see an application that has 20 dialog boxes, I say, 'That's bullshit.' But if it had 200 dialog boxes before they read my book, then you can't really complain.