Alan Cooper - Questions after his keynote

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?

Wow

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.

This guy is scary !

I hope he'll write a book titled "The Visual Studio Chronicles" 
as a software version of Rob Colwell's "The Pentium Chronicles."

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

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

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.

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.

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!

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 :d

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.

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?

Shark_M wrote:

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

You and scobleizer are both right in yours perspective.
I can say I inverted the words "Customers don't know what they want" ,  no one tell me before I say the words out, it's from experience.
At frist, do asked what the Customers know? yes, people are good at what you are living with, for example, lawyers know the process of court, we don't , we know the software, lawyers don't, so "Customers don't know what they want" = "Customers don't know what the computer(or software) can do for them".

God, I hope Alan is working on About Face 3.0 or something cause I'm pretty sure most people will make horrible programs from a usuability point of view once Vista is released. All the cool Avalon stuff will get overused and used in wrong horrible ways.

scobleizer wrote:

I disagree with you. Customers don't know what they want.

Did you know you wanted an iPod before you saw it?

Maybe I'm an exception, but yes I did.  I knew I wanted an mp3 player to fit in my pocket, hold my entire collection, have decent battery life, and allow me to navigate it easily.  I think a lot of geeks / music people were clamoring for it.  Was my vision exactly the iPod?  No.

Customers do know the functionality they want, they just don't know the specifics or care about the implementation process.

scobleizer wrote:

Did you know you wanted an iPod before you saw it?

No, I didn't.

Do I want an iPod now - no, I don't.

Excellent video.  It has been a long time since Channel 9 has had a video of the caliber (IMHO)

The guy is a monster.  [6]  I did not get any closure though and I thought it was very rude the way he ended the video.  But what the heck, If anybody has the right to do that is him.

Great Job Scoble!

It's very enjoyable and useful to listen to passionate thinkers like Alan Cooper,  because his pronouncements make all of us think, and thinking is a good thing.  But life (and corporate life) is not black & white with no shades of gray; black & white pronouncements are a mismatch against shades-of-gray real life.

For example, this business about how users are like kindergarteners and should never be allowed to be part of the software design process because software engineers are the experts, falls short in the real world.  At least in the many different corporate real worlds I've worked within during my career so far.

In the real world, not every person in life is working in a job they are most perfectly suited for.  Some software users are much more sophisticated and knowledgable than others, some, in fact, actually become software engineers (funny, but most software engineers were once -- and still are -- software users).  Meanwhile -- and tell me you aren't nodding your head at this -- some software engineers should never, never, have gone into the field they now find themselves in, and, you find yourself mystified on an almost daily basis as to how they got through the hiring gauntlet and why they continue to be able to draw a paycheck.

In that very real world I just described, it's often the case that when the "engineers" solve all the problems without including their "users", the most useless drek results that almost immediately needs to be trashed and rewritten.  And when a well-chosen set of expert users is included, a system that was about to become one of those turkeys gets rescued by the voice of sanity and reason from the right expert user being on the team at the right time.

We engineers are often (hopefully) better informed than many users about back-end issues like server configuration or what data should be normalized or how to utilize network bandwith efficiently.  But when it comes to creating an intuitive set of features or user interface -- well, I wish my engineer compatriots were the "experts" that Mr. Cooper envisions are hard at work at the corporation and should best be left alone.  The truth is, some of these folk really really shouldn't be doing what they're doing.  Many of them have limited communication skills, interface design skills, people skills, or worse, enjoy doing things that technologically assist them in stuffing their Resumes, but could give a crap if the final finished system actually meets their user's needs.

In most typical real-world situations, the users need to be involved cradle-to-grave -- presuming you want the system to actually meet the corporations' needs and provide actual value (a lot of stuff we produce DOESN'T).

I would expect that he would say he is not the right person to design an OS.  He is not a good person to design the scheduler, the DMA support, and so on.

He would probably also say that his ideas of how the OS should behave are no better than anyone else's.  We all have ideas for what the OS behavior should be, but that design needs to be more than just a bunch of ideas.  A house I once saw as described as "The architect had 5 good ideas here, unfortunately he used all of them."

What makes many great products stand out is that the set of features and approaches to the problem work together and are not just a bunch of separate features thrown together.  For example the Apple word processor Pages does far less than Word but is more enjoyable to use because all the features work together and the overall design appears well thought out in advance.  The same is true of many other good products.  WPF is an example of software that has a very well thought out interface to its user (programmers).  If you threw 20 application programmers in a room they would almost certainly never have defined an API as good as WPF.

The best project I ever worked on in terms of low stress, productive process, and satisfactory result, was a project where we wrote the user manual first and the code second.  We defined at the level of the user manual exactly what the software was to do.  Then coding the software to do that was much easier, and there was no indecision on what any features should look like.

Michael

I think Alan makes several points that were missed, and you make a good point but conclude the wrong judgment.

If the software developers do not include domain experts the project will produce drek.  No question about that.  But, end-users are not necessary domain experts.  Most users do not know how the automated processes of their software work, and could not tell you the requirements on a replacement.  I have often gone into replace a manual system and rather than simply implementing the current user's process, have provided a solution that required 1/2 or less of the effort of the original manual system.  So domain experts are always needed, but not end-users per se.

The other point is that he is promoting a different way of structuring software development, so "reality" is not so important to him.  He wants to change that.  The current processes that leave mediocre programmers in charge of what the software does, is not a good solution, so why defend it?  I certainly know that sense of helplessness that drives that lament.  Being in a job where you feel you have no abiilty to make things better is very frustrating.  That is the death march he mentions as the current status quo in many organizations.

Zeo wrote:

I'm not familair with the Access history he spoke about, anyone know more about what exactly took place? 

As I understand it, Access 1.0 is the 3rd iteration on the 3rd technology framework (i.e. Ruby aka Pre-VB engine, Silver?)

The 2nd iteration, if I recall correctly was called Omega and was around the same time as Opus(?) which was the WinWord 1.0 alpha/beta. Rumour has it that everyone loved Omega (and I think I saw a running beta) but one man stood against it, Bill Gates.

Pressure was big on Microsoft shipping a database system, remembering that a company called Ashton Tate had a killer application called dBase while Microsoft was repackaging something called Cobol and RBase(?)

I never saw the 1st iteration. The 2nd iteration looked sweet, considering the technology of the time, but I had not used nor was competent with db to touch it (as opposed to I am now totally incompetent)

When looking at the support for legacy code that would have been strapped to Microsoft with the Omega release, there would definitely not have been the same after-market for Access.

Sam T.

I haven't read everything Alan Cooper said, or seen the quote in context, but I'll say this:

Its true that some users will give you input that is misguided or not helpful and they think something will be good that would actually turn out bad,

Many users have the understanding of design and programming that that the actual designers do, whether they actually can program or just instinctively understand the issues involved.

Its the same thing with kindergarteners and their teachers, its very possible for there to be a child who can pose a challenge to a teacher, whether because he is particularly smart and can point something out, or because he just doesn't fit the teachers expectation forces the teacher to address issues that the child wants to be addressed.

Move beyond the kindergartener and teacher analogy and look to college student/college professor where this is more pronounced. Often students at this level are intelligent and understanding enough that, even without years of experience, and knowledge of particular facts and details, they could understand certain things, including the larger picture, better than their teachers.

Its also possible for someone who is not an accredited expert in a field to have better intuition than someone who is an accredited expert. Psychologists, lawyers, politicians, theorists, (software designers) etc., all have access to the same information everyone else does. Outside the experts is usually where geniuses any given field come from, though you don't need to be a genius to have some worthwhile understanding. Geniuses in a field usually are able to articulate all of the dissatisfaction and doubt that people outside the field had but were unable to put in the right terms. Experts in the field may have no real insight and just be working as hacks, doing what they think users want based on what they've learned; and may sometimes have even less clue on what to do than the users.

You don't assume people who haven't been given some degree, or spent as many years doing design as you, or knows all of the minute details of the Windows API and programming in C++ are clueless.

If you go back to talking about the software industry, even if some users have as much understanding as the designers, not all do---but all users might have some particular thing they understand better, or at the least some issue they have that the designer has to pay attention to--because their issues with their software don't always come out of stupidity but real problems. Even if those users can't encapsulate what the real problem is with their software or they can't encapsulate what the solution should be, at the bottom of their complaint or suggestion is usually something real that needs to be looked at.

In the end, not only should designers understand the users, but understand what the user says they want, and why they say they want it, to understand how to create the software. And often times what they say they want is actually what they want. Designers should never dismiss what users say they want, if they find the user wrong, they should be able to convince the user in some way why they're wrong. If they can't do that, they can't deliver a good product.

Maybe Alan Cooper is simplifying things when he makes that statement out of context. But thats exactly something I'm sick of, making simplistically bold statements.

What I have been fighting inside for the past few years is proven to be correct by Alan Cooper.  What we are taught in school is proven to be true by Alan Cooper.  Thank you for your persistance and knowledge in this field.  I have managed to create virtually bug free software by designing on paper, listening to the user, and coming up with the solution I believe is best for a given scenario.  User experience is key.  A very simple way to have a developer understand "User Experience" when it comes to the UI and feel of a software program is to simply say "How would you have liked it to look like and act?"  As simple as that, a developer would be forced to take additional time to map out a software program and design it to make it work the way the developer themselves would like it to be.  An example would be a simple program that tracks a workflow.  Yes you can put an auto-refresh on a webpage to poll the data base to re-fill a datagrid, but what about sending an Email or SMS to the user to let them know that there is a new item in the workflow, or a change.  It is *easier* to just let the user "minimize" the web page and check it now and then, it is more complicated, or takes a few more lines of code and one more hour to insert some logic that enhances the overal user experience.  Also, Alan metions that developers enjoy working on open source software more.  The majority of open source software, while may be well thought out, lacks in User Experience/User Interface design, and is merely more enjoyable to the developer for the simple fact that there are no deadlines, at the least.  The bottomline, there is more freedom in every respect when it comes to creating open source programs.  What you get are thought out programs that are virtually unusable withour understanding the code that went in them!  There is a balance that can be achived in the real world.

Finally, the user *does* know what they *want*, but she does not know what she *needs*.

-Leeor