– a few quotes and notes –

Excerpts from the book

Unfortunately, most software products never have a description. Instead, all they have is a shopping list of features. A shopping bag filled with flour, sugar, milk, and eggs is not the same as a cake. (page 42)

Thus, most products begin life with a document variably called a “marketing specification,” “technical specification,” or a “marketing requirements document”. It is really just a list of desired features, like the list of ingredients in the recipe of a cake. It is usually the result of several long brainstorming sessions where managers, marketers, and developers imagine what features would be cool, and jot them down. Spreadsheet programs are a favorite tool for creating these lists, and a typical one can be dozens of pages long. (Invariably, at least one of the line items will specify a “good user interface.”) Feature suggestions can also come from focus groups, market research, and competitive analysis. (46)

One thing I’ve noticed is that you get what you measure and reward. [The] only measure our board had were dates and features promised. They never set out measures for minimum quality […] so quality was sacrificed. […] There were never any measures about how long it would take to learn something, or how often a user would work without an error, so learnability and usability were sacrificed. But the things that were measured–the schedule and the list of features–were achieved, and because there wasn’t a full description of the features. Many of them were achieved in name only. (85)

Anyone untrained in interaction design methods tends toward self-referential design, in which one imagines himself as the user, and programmers naturally fall into this trap. Any group of people designing self-referentially will have a devilish time getting to closure on issues because they have no firm, common ground about users, and the process drags on interminably. (87)

Programmers trade simplicity for control. (96) They exchange success for understanding. They focus on what is possible to the exclusion of what is probable. And they act like jocks. (93)

[The] programmers run the show. Even when they don’t do so explicitly, they do so implicitly by the force of their will. (111)

[…] important for an interaction designer: a strong understanding of what programmers actually do, understanding of interaction design principles and methods, along with taxonomy for understanding their users. (112)

[Visual Designers] have a well-developed aesthetic sense, think visually, can draw or paint, and are a part of every one of our design projects. However, they add their magic to our designs only after the heavy lifting of conceptual and behavioral design work has been completed by trained interaction designers. (113)

Letting programmers do their own design results in bad design, but it also has another, collateral effect: the programmers lose respect for the design process. Programmers have been successfully bluffing their way through the design process for so long that they are conditioned to disregard its value. When a trained interaction designer is finally hired, the programmer naturally treats their work dismissively. (116)

[Programmers] consider the absence of criticism a compliment, so their assessment of their own performance is unrealistically positive, and many of them insist on continued ownership of the design role. Like mad kinks, programmers are unwilling to relinquish territory after it is occupied, even if the occupation is unpleasant, unprofitable, undesired, and untenable. (209)

I have seen [usability professionals developing] sophisticated tests […]. When their rigorous, scientific method uncovered a problem area, they would lapse into the most amateurish babbling about solutions […]
It is fine to say, “I don’t know,” but very self-defeating to guess at answers. What’s worst is that any gazing off into space and guessing will cause programmers – the one with skin in the game – to quietly write you off as a quack. (210)

When a company is customer-driven, it is a clear symptom that the product managers believe in the myth of the unpredictable market. They really don’t know whether or not a feature is good or bad, necessary or unnecessary. […] If the customer says, “Add a left-handed monkey wrench feature,” the product manager figures the customer must know something. The manager believes that it might be the magic feature that will make the product a big success. (224)

Conceptual model of three primary qualities in high-tech business

• What’s Capable? (Engineering)
• What’s Viable? (Business)
• What’s Desirable (Design)

Ingredients of Goal-Directed Design

• Personas (= user profiles?)
• Goals (definitely not tasks)
• Scenarios

other useful design concepts

• inflecting the interface
• perpetual intermediates
• vocabulary
• brain-storming
• lateral thinking

Mind the Gap!

• Mind the Gap! Software Engineers and Interaction Architects – Position paper for Interact 2003
• [ID Discuss] on Mind the Gap! Software Engineers and Interaction Architects – a discussion on discuss.interactiondesigners.com, February 2004