Quotes from Alan Cooper

Define what the product will do before you design how the product will do it.

In all other construction disciplines, engineers plan a construction strategy that craftmen execute. Engineers don't build bridges; ironworkers do. Only in software is the engineer tasked with actually building the product. Only in software is the "ironworker" tasked with determining how the product will be constructed.

Sort of like the pilot saying, "We're gonna make Chicago on time, but only if we jettison all our baggage!" I've seen product managers sacrifice not only design, but testing, function, features, integration, documentation, and reality. Most product managers that I have worked with would rather ship a failure on time than risk going late.

High cognitive friction polarizes people into two groups. It either makes them feel frustrated and stupid for failing, or giddy with power at overcoming the extreme difficulty. These powerful emotions force people into being either an "apologist" or a "survivor." They either adopt cognitive friction as a lifestyle, or they go underground and accept it as a necessary evil. The polarization is growing acute.

Eric Raymond says, "Good programmers know what to write. Great ones know what to reuse.

Usability's strength is in identifying problems, while design's strength is in identifying solutions.

When your number one job is serving the needs of users, and some external force tries to divert your efforts to some other goal, your number one job now changes to removing that external force. It doesn't matter if that external force has more economic or political power than you do. Your job is clear.

The real interaction designer's decisions are based on what the user is trying to achieve.

Like putting an Armani suit on Attila the Hun, interface design only tells how to dress up an existing behavior.

To deliver both power and pleasure to users, interaction designers think first conceptually, then in terms of behavior, and last in terms of interface.

You can predict which features in any new technology will be used and which won't. The use of a feature is inversely proportional to the amount of interaction needed to control

Most software is used in a business context, so most victims of bad interaction are paid for their suffering. Their job forces them to use software, so they cannot choose not to use it—they can only tolerate it as well as they can. They are forced to submerge their frustration and to ignore the embarrassment they feel when the software makes them feel stupid.

You can blame the "stupid user" all you want, but you still have to staff those phones with expensive tech-support people if you want to sell or distribute within your company software that hasn't been designed.

The Only Thing More Expensive Than Writing Software Is Writing Bad Software

Product successes and failures have shown repeatedly that users don't care that much about features. Users only care about achieving their goals.

When programmers speak of "computer literacy," they are drawing red lines around ethnic groups, too, yet few have pointed this out.

Interaction design isn't merely a matter of aesthetic choice; rather, it is based on an understanding of users and cognitive principles.

Writing software is not a variable cost, but it's not really a fixed cost either. Writing software is an ongoing, revenue-generating operation of the company, and it is not the same as constructing a factory. The expensive craftsmen who build the factory leave and go to work on some other job after the building is erected.

Homo logicus are driven by an irresistible desire to understand how things work. By contrast, Homo sapiens have a strong desire for success. Programmers also want to succeed, but they will frequently accept failure as the price to pay for understanding.

Computer literacy, however, is really a euphemism for forcing human beings to stretch their thinking to understand the inner workings of application logic, rather than having software-enabled products stretch to meet people's usual ways of thinking.

Goals are not the same as tasks or activities. A goal is an expectation of an end condition, whereas both activities and tasks are intermediate steps (at different levels of organization) that help someone to reach a goal or set of goals.

Many developers and usability professionals still approach interface design by asking what the tasks are. Although this may get the job done, it won't produce much more than an incremental improvement: It won't provide a solution that differentiates your product in the market, and very often it won't really satisfy the user.

People don't need to know all the details of how a complex mechanism actually works in order to use it, so they create a cognitive shorthand for explaining it. This explanation is powerful enough to cover their interactions with it but doesn't necessarily reflect its actual inner mechanics.

Interaction design is not guesswork.