- pag. 219
“Conceptual Integrity Is a Core Competence… Customer driven products don’t have a coherent design… The customers, no matter how well meaning they might be, don’t have the ability to think of your product as a single, conceptual whole.”
- pag. 220
“Selling brains is difficult. Anyone who will hire you for your brains must trust you to a high degree, because they are expecting you to do something that you have not yet demonstrated competence in. Selling gray hair is easier. A potential client can see that since you have solved this same problem before, you can solve it again for them.”

- pag. 221
“…it’s your responsibility as a product manager to keep yourself on the cutting edge and avoid the customer-driven death spiral. You have to look inside yourself for answers, the same way you did when you first started.
It means taking a longer view, taking responsibility, taking time, and taking control.”

- pag. 222
“When a company is customer driven, this is a clear symptom that the product managers believe in the myth of unpredictable market. They really don’t know whether or not a feature is good or bad, necessary or unnecessary.”

- pag. 223
comparação do processo de desenvolvimento de software com o de produção de filmes.

- pag. 226
“Interaction designers, like architects, deliver a set of blueprints that describe the product to built. But although the similarity between blueprints and software design documents is very close, they have great differences, too. Blueprints have a lot of leverage. A single line on paper can indicate a wall of 100,000 bricks. When interaction is involved, most of the leverage shrinks away. It might take a 100-page document to describe the behavior of 100 pages of code. With only a small dose of facetiousness, I say that a sufficiently detailed specification is indistinguishable from the code that implements it.”

Chapter 14: Power and Pleasure
- pag. 241
“The mass-market of low-tech consumers will quickly leap on easy-to-use products, as the explosion of the Web attests. The same people who were attracted to the Web because it does simple things simply will be attracted to well-designed products that do complex thinks simply.”

Share/Save

- pag. 182-184
programmers design for experts / marketers design for beginners vs perpetual intermediates

pag. 185
- “pretend it’s magic. (…) This exercise increases the contrast between tasks and goals. When technology changes, tasks normally chage, but goals remaisn constant. By imagining a magic technology, we force all tasks to change, thus highlighting the goals.”

pag. 187
- “When engineers invent, they arrive at their solution through a succession of pratical, possible steps. Because of this, theis solution will always be derivative of the old, begginning solution, which is often not good enough.”

pag. 198
- “Those gadget-obsessed, control-freak programmers love to fill products with gizmos and features, but that tendency is contrary to a fundamental insight about good design. Less is more”

Chapter 12 – Desperatly seeking usability
pag. 205
- “Puting design before programming means fundamental change in the software-development process. Programmers, wha re naturally affected by this, see it in vaguely threatning terms. They have heretofore been first and, by implication, most important. If some other discipline comes firs, does that mean the other practitioners are more importante?”

pag. 207
- “Programmers designing. The first ‘volunteers’ to address the problems of the new nontechnical users were the programmers themselves. That their culture and tools wew wholly inadequate to the task was less relevant than that they were the only available candidates for the job. … [also] the difficult challenge of designing interaction appealed to them, and they invested considerable effort. This gave rise to the sardonic joke in the industry that says ‘Design is what programmers do in the 20 minutes before they begin coding.’”

pag. 210
- Focus Groups (…) the biggest problem is simply that most people, even professional software users, are ignorant of what software is and what it can and cannot do. So when a focus group participant asks for a feature, the request is made from a shortsighted point of view. The user is asking for what he or she thinks is likely, possible, and reasonable. To consciously ask for something unlikely, impossible, or unreasonable would be to voluntarily seem stupid, and people don’t willingly do that.”

pag. 213
- Iteration. It is a commonly accepted truth about software development that the way to get good interaction is to iterate. (…) And, yes, iteration is an important element of good design: Keep working on it until it’s right. However, many product developers have interpreted this to mean that you can dispense with design and merely iterate across random thrusts in the dark.”

Share/Save

- pag.127
“Designing for the elastic user gives the developer license to code as he pleases while paying lip service to ‘the user’. Real users are not elastic.”
- pag.129
“As a design tool, it is more important that a persona be precise than accurate. That is, it is nore important to define the persona in great and specific detail than the persona be the precisely correct one.”

- pag.147
“If you want to design software-based products taht make people happy, you have to know who those people are with some precision. That is the role that personas play.”

Chapter 10 – Designing for Power
- pag.149
“…the quality of design isn’t so much a matter of opinion and is much more amenable to systematic analysis. In other words, in the bright light of a user’s goal, we can learn quite directly what design would suit the purpose, regardless of anyone’s opinion or, for that matter, of aesthetic quality. ‘Good interaction design’ has meaning only in the context of a person using it for some purpose.”

- pag.151
“The essence of good interaction design is to devise interactions that let users achieve their practical goods without violating their personal goals.”

- pag.151
“Tasks are not goals. The goal is a steady thing. The tasks are transient. That is one reason why designing for tasks doesn’t alsways suit, but designing for goals always does.

- pag.155
designing for vs providing for

- pag.155
“People are willing to put effort into tasks because they feel it is a fair exchange between equals. In other words, users area willing to invest extra effort because they know they will get extra rewards for it.”

- pag.156
“Personal goals are always true and operate to varying extents for everyone. Personal goals always take precedence over any other goals (…) Any system that violates personal goals will ultimately fail, regardless of how well it achieves other goals.”

- pag.157
“… Hygienic factors (…) prerequisites for effective motivation but powerless to motivate by themselves”

- pag.159
“…humans have special instincts that tell them how to behave around other sentient beings, and as soon as any object exhibits sufficient cognitive friction, those instincts kick in and we react as though we were interacting with another sentient human being”

- pag.162
“What makes software polite:
(…) polite software is interested in me
polite software is deferential to me
polite software is fothcoming
polite software has common sense
polite software is antecipates my needs
polite software is responsive
polite software is taciturn about my personal problems
polite software is well informed
polite software is perceptive
polite software is self confident
polite software stays focused
polite software is fudgable
polite software is trustwhorthy”

- pag.170
“Our software-based products irritate us becaus the aren’t polite, not because they lack features.”

Share/Save

- pag.96
“Programmers trade simplicity for control”

- pag.98
“Homo Logicus: wants to understand – accepts failure as trade-off
Homo Sapiens: wants success – accepts less understanding as trade-off”

- pag.99
“Programmers focus on what is possible to the exclusion of what is probable”

chapter 8 – An Obsolete Culture

pag.106
“The primary effect of code reuse is that large portions of most programs exist not only because some interaction designer wanted them to exist, but because some other programmer already did the work on someone elses’s budget.”

pag.112
“At Microsoft, the most important projects are conceived, managed and coded by programmers. The multimedia CD-ROM project that Moody observed was something of an exception in that ‘designers’ were involved at every step of the way. But they in no way exhibited the skill set that I consider mandatory for the role of interaction designer. They seemed to be ignorant of all of the thins important for an interaction designer: a strong understanding of what programmers actually do, an understanding of interaction-design principles and methods, and a taxonomy and tools for understanding theis users. Moody makes clear that the only skills the Microsoft designers brought were a quick wit, boundless energy and a sense of aesthetics.”

pag.113
“Visual designers have a well-developed aesthetic sense, think visually, can draw or paint(…). However, they add their magic to our designs only after the heavy lifting of conceptual and behavioural design work has been completed by trained interaction designers.”

pag.116
“Letting programmers do their own design results in bad design, but it also has a collateral effect: The programmers lose respect for the design process. Programmers have been successfullt bluffing their wat through the design process for so long that they are conditioned to disregard its value.”

pag.119
“Astonishingly, the simple and obvious fact taht computers are vastly more powerful, cheaper and faster that they were just a few years ago hasn’t really penetrated the practice of software construction. Consequently, most software products don’t work very hard to serve the user. Instead, they are protective of the CPU in the mistaken impression that it is overworked. The result is that software-based products tend to overwork the human user. Design guru Bill Moggridge calls this attitude ‘be kinf to chips and cruel to the users.’”

pag.120
“Interactive systems do not have to be dehumanizing, but for this to occur, we have to revamp our development methodology so that the humans who ultimatly use them are the primary focus.”

Share/Save

- pag.42
…Instead, all they [software products] have is alist of features. A shopping bag filled with flour, sugar, milk and eggs is not the same thing as a cake.”

- pag.43
“Managers know that software development follows Parkinson’s Law: Work will expand to fill the time allote to it. (…) corollary to Parkinson called the Ninety-Ninety Rule, atributed to Tom Cargil of Bell Labs: ” The first 90% of the code acount for the first 90% of development time. The remaining 10% of the code accounts for the other 90% of the development time.”

- pag.45
“A third-rate product that ships late often fails, but if your product delivers value to its users, arriving behind schedule won’t necessarily have lasting bad effects.”
- pag.48
“It might be counterintuitive in our feature-conscious world, but you simply cannot achieve your goals by using feature lists as a problem-solving tool. It’s quite possible to satisfy every feature item on the list and still hatch a catastrophe. Interaction designer Scott McGregor user a delightful test in his class to prove this point. He describes a product with a list of features, asking his class to write down what the product is as soon as they can guess. He begins with 1) internal combution engine; 2) four wheels with rubber tires; 3) a transmission connecting the engine to the drive wheels; 4) engine and transmission mounted on a metal chasis; 5) a steering wheel. By this time, every student will have written down his or her positive identification of the product as an automobile, whereupon Scott ceases using features to describe the product and instead mentions a couple of user goals: 6) cuts grass quickly and easily; 7) comfortable to sit on. From the five feature clues, not one student will have written down “riding lawnmower”. You can see how much more descriptive goals are than features.”

- pag.52
“People who use business software might despise it, but they are paid to tolerate it. This changes the way people think about software. Getting paid for using software makes users far more tolerant of its shortcomings because they have no choice, but it doesn’t make it any less expensive. Instead – while the costs remain high – the become very difficult to see and account for.”

- pag.57
“The value of a prototype is in the education it gives you, not in the code itself. Developer sage Frederic Brooks says, “Plan to throw one away.” You will anyway, so you might as well do it under controlled circumstances”.

Chapter 4 – The Dancing Bear

- pag.65
“Whats wrong with software: software forgets, software is lazy, software is parsimonious with information, software is inflexible, software blames users, software won’t take responsability

Chapter 5 – Customer Disloyalty

- pag.72
Capability (engineering), Viability (business), Desirability (design)

- pag.77
“In the information age – in the age or rapid innovation and extreme cognitive friction – design is a primary necessity.”

Chapter 6 – The Inmates Are Running the Asylum
- pag.87
“Clearly, one side of software – the inside – must be written with technical experitse and sensitivity to the needs of computers. But equally clear, the other side of software – the outside – must be written with social expertise and sensitivity to the needs of people. It is my contention that programmers can do the former, but it takes interaction designers to do the latter.”

Share/Save