Posted by Charles // Tue, Mar 14, 2006 2:22 PM
Alan Cooper spoke at a recent Patterns and Practices Summit here at Microsoft and we turned our camera on during the conversation that happened afterward.
Who's Alan Cooper? He's the guy who invented the user interface for Visual Basic (which later became Visual Studio). So he knows a thing or two about software development. He also runs a software design firm, http://www.cooper.com
Tags: Visual+Studio
|
| Clip Length: 00:00:08
|
|
Replies:
35
// Views:
44,182
|
 |
|
|
|
I've always wanted to know more about the patterns and practice group at Microsoft.
I've read many of their white papers and prescriptive guidance papers but I've always wondered about who exactly makes up the group (are they all deep CS PHD research candidates?) because they seem to publish scary smart stuff that has really great technical breath and depth.
The video didn't answer that question so much it highlighted one of the group's core principles of giving real world guidance about deep technical engineering issues.
Best lines from the video.
"USERS DON'T KNOW WHAT THEY WANT."
Amen to that.
"Software is too complex, to difficult, to costly to let users have anything to do with it!"
Question: "What's the first step along the path out of the death march world?
Answer: Admitting there is a problem and admitting that it's a solvable problem. It's like saying I'm an alcoholic.
I agree with him in many ways....although I bet Jamie strongly disagrees.
I love the kindergarden analogy. 
I'm going to use the broken arm analogy in the future because its a great clear analogy.
He said "Never show users prototypes"....hmm I disagree with him there, but then again what do I know?
Great comment Robert about throwing out code with Longhorn.
I'm not familair with the Access history he spoke about, anyone know more about what exactly took place?
Some of his thoughts seem to be rather out there. Changing accounting principles....never going to happen. Never. Anyone know of any articles about this idea out there I'd love to learn more and re-evaluate my position?
The alcoholic comment makes me laugh....All of us software people are alcoholics...and on top of being alcoholics we're also code addicts.
Really great coversation.
Thanks for capturing it on video channel9.
The guy who got his book signed. Very funny. I guess you could put it on ebay and get millions for it. 
Scoble where was this video taken? In the Microsoft Conference center?
|
I don't get it, he is in SW biz and does not know what C9 is or who Robert is with the vid camera and tells you to turn it off only after you tell him you walk around MS with a video camera? I think you said that up front. Much of that was crazy talk. Some was right. Thing is, you can't go to a user after a year of work and only then see if works for them. Isn't that the kind of thing people are moving away from for that exact reason?
|
 |
dahat
Vist my homepage to help pay off my student loans
|
|
|
|
With his line of:
 | Alan Cooper wrote:
The thing is that the users don’t know, you can’t get blood from a stone, users are got a good source of software, you’ve got to have software built by experts, and you’ve got to have software designed by experts. Software is too complicated and too big and too costly and too difficult to let users have anything to do with it. |
Alan has nearly reached the level of being one of my heros.
Now... when he writes a book that I agree with to the point that I do as Atlas Shrugged... then he may achieve full hero status... until then... wow!
I must also remember not to utter such a line near one of my bosses or one of my internal (non expert) customers for fear of getting axed.
|
Yeah, that was shot inside our conference center. Building 33.
Oh, Alan knows me very well. He asked me to turn off the camera so that he could have a private conversation with me.
He is a God in my eyes, though. Having conversations with him after conferences is always interesting.
The problem with this video is it is a bit out of context. You need to hear Alan's whole schtick to understand what he means when he says you shouldn't let customers design things.
He's absolutely right, by the way.
|
I hope he'll write a book titled "The Visual Studio Chronicles"
as a software version of Rob Colwell's "The Pentium Chronicles."
|
| scobleizer wrote:
Yeah, that was shot inside our conference center. Building 33.
Oh, Alan knows me very well. He asked me to turn off the camera so that he could have a private conversation with me.
He is a God in my eyes, though. Having conversations with him after conferences is always interesting.
The problem with this video is it is a bit out of context. You need to hear Alan's whole schtick to understand what he means when he says you shouldn't let customers design things.
He's absolutely right, by the way. |
I disagree on some of his points. I mean you need customers to tell you what they want. Isnt The Product Feed back and the interaction of the customers and the developer division at Microsoft there to get ideas of what the customers want? I mean you need them to tell you want they want to ship the perfect product for them. If you have no idea what the customer wants then mostlikely you will waste effort and money on something most people might not be interested in.
Espcially if your customers are fellow developers, they kneed to be shown how microsoft design things, inorder for both parties to say "aha, this is what I really want, Please ship this to me"
these are my 2 cents !
P.S: I find Alan Cooper scary, i dont knwo why, but he is scary when he talks lol.
|
I disagree with you. Customers don't know what they want.
Did you know you wanted an iPod before you saw it?
The best design is done when you actually just study what users are doing.
But, Alan's comments are a bit out of context.
To learn more about what he means (and how he designs) I highly suggest reading some of his books on the topic: http://en.wikipedia.org/wiki/Alan_Cooper
|
he does have that ballmer vibe, though! quite inspiring. i found that to be one of the most interesting videos on channel9 at least for the last few months. got to watch it again... cooper's views seemed quite radical to me (which i like in this case)... his views of the clash of management and tech guys i suspect do reflect reality quite well, sadly. sometimes i think this gap is even bigger in companies where software isn't their primary product, where there 's only an IT department for internal development. for the financial guys the IT department is just another cost factor to be minimized.
management gets the nice big flat screens first ;-)
in the words of Charles: outstanding video!
- martin
|
 |
Karim
Trapped in a world he never made!
|
|
|
| staceyw wrote:
Much of that was crazy talk. Some was right. Thing is, you can't go to a user after a year of work and only then see if works for them. Isn't that the kind of thing people are moving away from for that exact reason? |
He did say, "You never show users prototypes!" But then he added,
"There's an asterisk on 'never...' I mean... when you're doing refinement, at a very focused, tiny level -- like if you're trying to say, 'Ok, should this be a... do you click and drag this with the LEFT mouse button, or the RIGHT mouse button?' Ok, those are the kind of things you can user test. Ok? But, 'Should this be draggable, or not?' 'Should it be present?' 'Should it be manipulatable?' 'Should the user be exposed to this?' -- these are the bigger issues. These, you don't solve through prototyping. And you certainly don't solve them in the presence of users. Oh my God -- it's like coding in the presence of users. 'Shouldn't that be a comma, instead of a semicolon...?' I mean, what -- [laughs] what's that?"
When you buy a car, they let you pick out the color, the interior, the radio etc. While the car is being designed, the car company doesn't give the customer a whole lot of input into the final drive ratio or whether the camshaft should have solid lifters or hydraulic ones...
| Shark_M wrote:
I disagree on some of his points. I mean you need customers to tell you what they want. Isnt The Product Feed back and the interaction of the customers and the developer division at Microsoft there to get ideas of what the customers want?
|
Most customers don't know what they want. Quote: "THE USERS DON'T KNOW!!!" What they do know, usually, is how to describe a problem they have: "Searching Outlook takes too long." "I have too many icons on my desktop." etc.
It's like the broken arm analogy -- when you go to the Doctor, you don't say, "Write me a prescription for X." That would be assuming that YOU KNOW what you want. Instead, you go to the Doctor and you say, "It hurts when I do this." Then you let the Doctor -- the expert -- decide how to fix the problem.
One is imperative: Give me what I want!
The other is declarative: Here is the problem I am having.
Doctors and designers both have to be good listeners at first, not to understand what the user "wants" as a solution -- but to understand the problem.
It's Where do you want to go today? Not How do you want to get there?
To the extent that end users do really know what they want, it's probably just refinement of an existing solution.
Great video, C9 Team...
|
WOW! He's the one who wrote About Face, THE definitive book on UI design. OK, so i'll watch this and then read the book.
http://www.cooper.com/content/insights/cooper_books.asp
I must say, it was an amazing video! And I'm happy to say our company seems to get it and doesn't engage in death marches to finish releases...
I'm still learning a lot in terms of getting to professional level in User Interaction, but I love this stuff!
|
| scobleizer wrote:
I disagree with you. Customers don't know what they want.
Did you know you wanted an iPod before you saw it?
The best design is done when you actually just study what users are doing.
But, Alan's comments are a bit out of context.
To learn more about what he means (and how he designs) I highly suggest reading some of his books on the topic: http://en.wikipedia.org/wiki/Alan_Cooper |
There is a saying "Need Is the mother of all inventions"
People needed to listen to music, on a portable device. So a given company that made a "Solution" to fit the need of the people. But they still asked what would be good, small size thing that you can fit into your pocket, or a bigger size device that you can fit into your school bag. People said , They wanted a small device that is convenient and would play all mp3 music files they wanted. Smaller is cool!
I say that, if some company just made its own solution, and did not talk to people or show them prototypes, or got feedback on the usability of the product, and how its best to achieve the solution, then that company would likely fail. Alot of companies failed because of that. Good Design process comes from constant feed back and corrections that come from the people the devices are intended for.
On his example with kids in school, I think if the teachers talked to the students, on what would acheive order and common understanding the classes would be more ordered and more mature  . You achieve results faster and in more efficient ways.
my 2 cents
|
| Zeo wrote:
I've always wanted to know more about the patterns and practice group at Microsoft.
I've read many of their white papers and prescriptive guidance papers but I've always wondered about who exactly makes up the group (are they all deep CS PHD research candidates?) because they seem to publish scary smart stuff that has really great technical breath and depth.
The video didn't answer that question so much it highlighted one of the group's core principles of giving real world guidance about deep technical engineering issues.
|
I've got one more day with the P&P team here in Redmond before going back to my cave in Arkansas.
They are all very bright, a few are outrageously talented. It has been fun recognizing their voices from Ron Jacobs ARCasts and podcasts and from Robert's videos.
--------------
My favorite metaphor from Alan Cooper is that "users are 5-year old kindergarten kids who have absolutely no business telling the teachers how to do their jobs". So true. My best software was delivered without any prototypes or user inspections.
Documenting the expectations is imperative. Iterative design, going over and over requirements with the clients, is essential. At least that is what I picked up from Alan's interview.
Good professionals know how and when to tell their clients "No", just like the kindergarten teachers "feed the kids beets and brocolli when they ask for candy". (Kids don't die when they don't get candy.) It isn't like "the customer is always right" it is that the customer needs guidance, just like me here today.
|
| Karim wrote:
Most customers don't know what they want. Quote: "THE USERS DON'T KNOW!!!" What they do know, usually, is how to describe a problem they have: "Searching Outlook takes too long." "I have too many icons on my desktop." etc.
It's like the broken arm analogy -- when you go to the Doctor, you don't say, "Write me a prescription for X." That would be assuming that YOU KNOW what you want. Instead, you go to the Doctor and you say, "It hurts when I do this." Then you let the Doctor -- the expert -- decide how to fix the problem.
One is imperative: Give me what I want!
The other is declarative: Here is the problem I am having.
Doctors and designers both have to be good listeners at first, not to understand what the user "wants" as a solution -- but to understand the problem.
It's Where do you want to go today? Not How do you want to get there?
To the extent that end users do really know what they want, it's probably just refinement of an existing solution.
Great video, C9 Team...
|
Yeah but you should give the doctor a feed back as to what is the best way to heal your injured arm. A doctor could solve the problem just by giving you pain killers, that would stop the "Complaining", and the problem would appear as gone for you. But the arm is still broken! Or a doctor might just solve it by amputating it, instead of healing the broken bone! SO the expert can only present "Possibilities" or spectrum of possibilites to the customer, and let the cusomter choose which possibility or option to go about and producing a solution to the posted problem. This has a basis in the Scientific Theory itself. You have to get feedback to know what is the best answer to the problem.
There are many expert companies that produced solutions, that would work and all, but they did not work well for the intended people.... I mean why do most people in the world choose Windows Operating system over Unix? Both work and all, But Windows is a solution that is simper to use, and Microsoft produced it because it talked to people and it observed that Unix is not that easy to work with for the average home user. Microsoft until this day interacts with the developer bodies and the customers out there, and presents options and let the people decide on what features that they need in a "solution".
The Information Technology sector is growing, more and more people are becomming mini-experts on computers, and they know alot than before. So what if 80% of the end users are experts, would you not want to tell them how a tool was made, or what would be a good way to go about producing a solution? Option A or Option B?
I mean when you did a project for some customer, dont you first have an outline of the project, and show the pathway to getting the project done to the customer?
50% of programming is knowing what the customer wants, and that include how to get what he/she wants. The other 50% is the actual coding and debugging and producing the final project.
So Customers should be shown and asked "What is best for you. If i place a TreeView or aListview, or a radio button, or a check mark".
|
|
Hi Zeo -
I've always wanted to know more about the patterns and practice group at Microsoft.
I've read many of their white papers and prescriptive guidance papers but I've always wondered about who exactly makes up the group (are they all deep CS PHD research candidates?) because they seem to publish scary smart stuff that has really great technical breath and depth. |
I'm a product manager in the p&p team - wow, glad you like the stuff we're producing! We're a pretty diverse team (in both experience and culture), but the overwhelming majority of us have spend considerable time working out in the "real world" on enterprise customer projects.
We also try very hard to be transparent in our processes and to participate in community forums - it's very important that we're grounded in reality, and we need customers help to do this! If you want to find out more about our team, our blogs are a great place to start - see http://msdn.microsoft.com/practices/Comm/TeamBlogs/default.aspx. We are also involved in GotDotNet community sites and we do webcasts and events as often as we can - so hopefully some of us will cross paths with you eventually
Thanks again for your support
Tom Hollander
http://blogs.msdn.com/tomholl
|
Shark_M, what you're advocating isn't all that different from what Cooper is talking about. Cooper isn't advocating developers work in a vacuum. That kind approach breeds arrogance and crappy results. What he's arguing against is letting users micromanage the design. The problem is that users tend to communicate immediate desires rather than long terms needs--you could compare this with the old aphorism of giving a man a fish vs. teaching him how to fish. Moreoever, most users are "tainted" with what they've encountered before and that exposure obstructs their imagination. The trick of a good interaction designer, then, is to gleam deeper needs from wants.
|
|
Karim
Trapped in a world he never made!
|
|
|
| Shark_M wrote:
Yeah but you should give the doctor a feed back as to what is the best way to heal your injured arm. A doctor could solve the problem just by giving you pain killers, that would stop the "Complaining", and the problem would appear as gone for you. But the arm is still broken! Or a doctor might just solve it by amputating it, instead of healing the broken bone! SO the expert can only present "Possibilities" or spectrum of possibilites to the customer, and let the cusomter choose which possibility or option to go about and producing a solution to the posted problem. This has a basis in the Scientific Theory itself. You have to get feedback to know what is the best answer to the problem.
|
What you call "feedback," I call describing a problem. "It hurts when I move my arm this way, but not that way." What you don't want to do is tell the doctor "the best way to heal your injured arm." That's the doctor's job. Did you go to Medical School?
Real doctors do not fix broken arms by amputating them. (Or at least, not competent ones.) But if your doctor runs tests and your broken arm turns out to be gangrenous, your doctor might NEED to amputate to save your life, even though you would be telling your doctor, "All I need is some more Percoset."
Bottom line, it's a cooperative process, but at some point you have to decide who knows more, who's doing the design, who's driving the bus. If you know more than your doctor, why are you going to a doctor?
| Shark_M wrote:
There are many expert companies that produced solutions, that would work and all, but they did not work well for the intended people....
|
Either poor implementation, or poor design, or failure to understand the original problem. Usually it's the latter...
| Shark_M wrote:
The Information Technology sector is growing, more and more people are becomming mini-experts on computers, and they know alot than before. So what if 80% of the end users are experts, would you not want to tell them how a tool was made, or what would be a good way to go about producing a solution? Option A or Option B?
|
The "savvy" people can be the worst, because sometimes they think they know it all. "I once launched Microsoft Access, therefore I know relational database design."
| Shark_M wrote:
I mean when you did a project for some customer, dont you first have an outline of the project, and show the pathway to getting the project done to the customer?
|
No, the first thing I do is listen. And take notes. And ask questions. I try to understand the problem really, really well, before I get anywhere near having "an outline of the project."
Once I'm at the point where I can describe the problem in my own words, the customer's eyes light up and they go "Yes! Finally, someone who understands the problem."
The best doctors are the ones who take the time to listen as well.
| Shark_M wrote:
Customers should be shown and asked "What is best for you. If i place a TreeView or aListview, or a radio button, or a check mark". |
I think that's incredibly scary. LOL
The Doctor doesn't say, "What is best for you? Xanax, Percoset, or Aspirin?" Those drugs do different things.
Treeviews, Listviews, Radio Buttons and Checkboxes all do different things. They don't substitute for one another. For hierarchical structures, you'd use a Treeview. For a series of exclusive choices, you'd use Radio Buttons, etc. I've seen those hellish applications where someone implemented Checkboxes instead of Radio Buttons because the customer thought Checkboxes were prettier, or whatever.
Again, the task is to know the problem in sufficient detail so that you KNOW (as a Designer) whether to use a Treeview, or Listview, or whatever -- not to ask the customer what they prefer.
|
I guess your both right.
Good Discussion and eyes opened my friend
|
| Karim wrote:
Once I'm at the point where I can describe the problem in my own words, the customer's eyes light up and they go "Yes! Finally, someone who understands the problem."
|
Isn't that the funnest reaction? It's strongest when the customer can't quite clearly describe the problem they're trying to solve and you wrap it up nicely in a little box with a bow and hand it back to them. "Zounds! That's it!"
Some aspects of this field really are satisfying. How odd that it involves people.
|
Users should never see the code, or _others_ should never see the code ?
Hasn't anyone learned that exposing things to other people is a great way to get perspective ? It almost seems as though the subject's view is that the coder is above all inputs, and cannot be wrong. I'll agree that users have their place, as do marketers, executives, etc, but exposing code to more eyes can ONLY make it better.
|
Wow, this is a cool dude! Great guy! A wonderful video.
|
|
I'm assuming this guy uses an Operating System?
Did he build that Operating System? (I doubt it, there are very few people who will go to the effort to build a custom operating system.)
Therefore, he is a user, am I not correct?
So his analogy therefore implies that he is a five year old kid, as far as using this Operating System is concerned, correct?
So... what would his take be on this - does he believe that he should have any input in the building of this Operating System?
This post is an open question, not meant to imply anything.
|
| ohgood wrote:
Users should never see the code, or _others_ should never see the code ?
Hasn't anyone learned that exposing things to other people is a great way to get perspective ? It almost seems as though the subject's view is that the coder is above all inputs, and cannot be wrong. I'll agree that users have their place, as do marketers, executives, etc, but exposing code to more eyes can ONLY make it better.
|
Are you saying that all software should be Open Source or that other people should have input into the development process?
|
|
|