Review

This book was written in 1999, it was a much needed call to action to get more design into software development. The authors style is unapologetically opinionated - which makes for an interesting read. He goes a little too hard and far with his characterisations of programmers. He makes the case for design so passionately, he seems to offend all the other disciples along the way.

The hidden gem of the book is one of the best descriptions of personas, goals and scenarios that I’ve seen.

It’s helpful for readers to understand how best practice for building software has evolved. But don’t read this book to understand the best practice of today.

By modern standards, the responsibilities given to the interaction designer in this book are a little too broad. This book is pre product-management and it shows.

You Might Also Like…

Designing Interactions

This is a collection of interviews that meanders through the history of interaction design. It lacks some structure and isn’t exactly insight dense. I’m interested in the history of computers and the pioneers of early computing - so I found it enjoyable. I wouldn’t recommend if you’re looking for something more practical.

andrewclark.co.uk

Book Review and Summary: The Design of Everyday Things by Donald A. Norman

Get a comprehensive review and summary of the classic book "The Design of Everyday Things" by Donald A. Norman, the user experience and design expert. Learn about the key principles and practices for designing products and environments that are intuitive and enjoyable for users.

andrewclark.co.uk

Book Review and Summary: Think Like an Architect by Hal Box

Get a comprehensive review and summary of the best-selling book "Think Like an Architect" by Hal Box, the renowned architect and educator. Learn about the key principles and practices of design thinking and problem-solving, based on Box's own experience and insights.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

• Products are not inherently hard to use → we just use the wrong process for creating them
• The key to solving the problem is interaction design before programming. We need a new class of professional interaction designers who design the way software behaves.
• Interactive products need to be designed by interaction designers instead of software engineers
• Interaction designers decisions are based on what the user is trying to do. Programmers decisions are often based on what is easiest to build.
• Interaction designers think first conceptually (what is best for the user) then behaviourally (how elements of the software should act and communicate) and only then in terms of interface.
• Beware of the dancing bear. People gather to see the wondrous sight. The bear is a really terrible dancer. The wonder isn’t that the bear dances well, but that the bear dances at all.
• Most software creators don’t know how to make their products easy to use, but they sure know how to add features, so that is what they do.
• Features taken in isolation seem to add utility, but together they all conspire to make the program difficult to understand and use.
• Each well-meant feature that might be useful - obfuscates the few features that will probably be useful
• Physical objects are subject to a natural brake on the proliferation of marginal features.
• 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 it!
• People obsess over ‘time to market’ - the wisdom goes shipping now is better than shipping later. BUT shipping a product that angers and frustrates users early isn’t great either
• If you lack a clear vision for a product - you can’t assess it’s progress toward completion → you’re more vulnerable
• Don’t let ‘shipping it’ become your only definition of completion!
• You can either provide a really detailed description of what the product will do → or you can describe the reaction you’d like the end user to have
• Feature-list bargaining is a result of deadline management. They allow programmers to shift blame to management - it wasn’t my fault, I put in all the features management wanted.
• Features are traded for time, and time for features. Both parties are instantly comfortable with it. Lost though - is the perspective needed for success.
• If you manage only to deadlines and feature lists, the product might arrive on time but it won’t be desirable. Instead - manage toward quality and user satisfaction and you till get to a product that users want - and it won’t take any longer.
• The side-effect of not understanding your failure to understand the customer → is the silent admission that success it not predictable, leaving us in a spray and pray mindset.
• If you keep shipping sketchy versions, you’ll iterate based on the feedback of only those that have the stamina to return to it - skewing your feedback.
• Don’t start before you know what problem you’re solving. Coding momentum is unstoppable, and the design process starts having to response to the needs of the programmers.
• Without a solid design - programmers experiment to find better solutions, which causes waste
• Prototypes → are experiments made to be thrown out. They have too many foundational short-cuts to scale.
• the value of a prototype is in the education that it gives you, not the code itself
• What’s wrong with software?
• Products forget - they don’t adapt to how we use them
• Products are stingy with information - they don’t tell us what is happening, or tell us things that are relevant
• Software is inflexible - inhumane rationality is imposed. System flexibility is key to maintaining social order - fungibility is what makes our manual systems work much better
• Software blames users - Programs push their problems onto users - and blame the usres for it.
• Software won’t take responsibility - Stop asking people if they’re sure - start allowing them to undo actions.
• Well-designed products or services generate fierce loyalty
• Apple’s use of design to make the Macintosh desirable - earned it unheard of customer loyalty. Mac fans are reluctant to leap to other vendors for specs, which gives Apple time to react to the competition.
• Three primary qualities in high-technology businesses (from Larry Keeley of Dolblin group)
• Engineers - Capability → What are we capable of, what is possible
• Business people - Viability → What is viable, what can we sell?
• Designers - Desirability → What is desired? What do people want?
• Programmers have a conflict of interest: serve users or make their lives easier.
• Management often say they don’t have time for the design method
• CTO told a development manager his spec was a waste of time - even though it exposed huge differences in assumptions about functionality. The inmates are truly running the asylum.
• Anyone untrained in interaction-design tends toward self-referential design (when you imagine yourself as the user)
• I’m not saying that a programmer can’t become a designer, I’m just saying that it is nearly impossible to do either task well - while attempting to do both simultaneously.
• Reusing code → Prewritten code saves time, code reuse is more important than almost any other technical consideration to programmers.
• When programmers implemented Jeff Bezos’ 1-click button, they did so with a confirming question! Jeff pointed out the extra click was 100% inflation.
• Scarcity thinking → Software products don’t work hard to serve the user - often the user is overworked and the CPU is idle. “Being kind to chips and cruel to users”
• We have to revamp our development methodology so that the humans who ultimately use them are the primary focus
• The two most important process changes
• design interactive products completely before beginning programming
• turn responsibility for design over to trained interaction designers.
• The most powerful tools are always simple in concept, but must be applied with some sophistication.

Personas

• Personas are the single most powerful design tool we use. They are the foundation for Goal-Directed Design.
• they help you see the scope and nature of the design problem
• they make it clear what the user goals are, so we can see what the product must do
• We don’t make up personas - we discover them as a byproduct of investigation
• Defined by their goals → start with a reasonable approximation and quickly converge on a believable population of personas
• Iterating with personas is quick and easy. Iterating later with code is slow and difficult
• Designing for a single user is the most effective way to satisfy a broad population
• Don’t assume your user is elastic - you should be bending to them. Never refer to the user - refer to the persona
• Detail brings solidity → identify skills, motivations and what she wants to achieve
• A persona without a name is not useful → they will never be a concrete person
• It is more important to be precise than accurate → surprising as the opposite is true for the product. Precision is important - because you don’t want the persona to wiggle under the pressure of development.
• Create a cast of characters: 3-12 personas. Often some are defined just to make it clear that we’re not designing for them. Negative persona’s make it clear who we’re not designing for.
• Primary Personas - are the main focus of the design. If there’s more than one primary persona - then they should have a different interface!
• If we find more than 3 primary personas - then the problem is too large and we’re trying to do take on too much at once
• Goal directed design starts with personas and their goals.
• Goals are the reasons why we perform tasks. Tasks change as technology changes, but goals remain stable
• When you use goals and not tasks to analyse interactions - you can find different and much better solutions
• The distinction between personal goals and practical goals is critical to success. Personal goals are simple, universal.

‣

4 principles for polite software → quality, quantity, relevance and clarity

• Personas → Goals → Scenarios
• Scenarios are concise description of a persona using a product to achieve a goal
• Two key types → Daily use scenarios and necessary use scenarios
• Daily is most useful and important. The main actions users perform, typically with the greatest frequency. Typically less than 3 scenarios.
• Necessary-use scenarios include all the actions that must be performed - but that are not performed frequently. There will be more of them than daily use scenarios.
• If a user performs a task frequently - its interaction mush be well crafted. Tasks that are neither frequent or necessary don’t require careful design.
• Inflecting the interface → The interface can be simplified by placing only the controls and data needed for the daily-use scenarios prominently in the interface and moving all others to secondary locations out of normal sight
• Most breakthrough conceptual advances are opaque in foresight and transparent in hindsight
• The most important aspect of design is the sequence.
• Design → Program → Bug test / User test → Tweak ✅
• Put design in front of programming. When you overlap design with programming - what you get is programming. Do design first.
• Be wary of iterating to a good design. The attrition strategy is expensive and time-consuming. Only works with a rock solid brand, lots of time, nerves of steal, and vast amounts of money.
• Conceptual integrity is a core competence → a single-minded vision of a product
• Without it customers take control. Are you a product company or a service company?
• Use your personas, goals and scenarios to help understand wether you should respond to a customer request.
• Interaction designers are like architects, deliver a set of blueprints that describe the product to be built. A sufficiently detailed specification is indistinguishable from the code that implements it.
• Organise design documents in the spiral method → allowing the reader to take what they want
• Headline: tells the entire tale
• First paragraph: tells the story with a bit more detail
• Next 3 paragraphs: tell the story once again, with more information
• Remainder of the article: tells the entire story in complete detail
• Product managers are weak if they cannot articulate with precision and conviction exactly what it is they are building.
• By vanquishing deadline management and feature-list negotiation → focus turns to quality → which in turn generates more customer loyalty.
• The interaction designer should be the ultimate owner of product quality. Should be able to determine the content and behaviour of the program. Own the feature list and the schedule. They are the advocate for the user and should have the authority to control all external aspects of the product.
• Designers need the combination of authority and responsibility to be respected by programmers.
• Mandate → designing a feasible-to-build, easy-to-use, attractive product that allows the user to achieve her practical goals without violating her personal goals. Describe and document things in a way engineers can understand.
• Interaction design can shorten the amount of time you spend developing your product.

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Chapter 1: Riddles for the Information Age

• We’ve all come across products that are hard to use.
• Products are not inherently hard to use → we just use the wrong process for creating them

• Software was so hard to use in the 90’s job adverts included ‘computer literate’
• By designing products to be more human and forgiving we can make them more inclusive
• The tech industry is in denial - our products are too hard to use
• When you cross a computer with a product or service → the behaviour of the computer dominates completely.
• The key to solving the problem is interaction design before programming. We need a new class of professional interaction designers who design the way software behaves.
• Programmers consciously design what the program does BUT which unconsciously shapes the user experience (how it behaves, communicates or informs the users)
• Interactions designers focus directly on the way users see and interact with products.
• The costs of badly designed software are incalculable.

Chapter 2: Cognitive Friction

• Engineers were able to move from problem to problem in the industrial age - satisfying people all the while.
• Engineers writing programs however have been greeted by unhappy, frustrated, dissatisfied and unproductive users.
• Cognitive friction: resistance encountered by human intellect when it engages with a complex system of rules that change as the problem changes.
• Cognitive friction is higher with software than physical devices (as physical devices tend to stay in a narrow range of states)
• Microwaves are an engineering marvel. Human factors experts adapt the buttons to humans eyes and fingers - but not their minds. So although everything is easy to press - it’s often hard to program what you want.
• Interactive products need to be designed by interaction designers instead of software engineers
• assertion generates antagonism from programmers who have been doing design all along
• fear that the best most creative part of their work is being taken away
• this is untrue - their worry stems from the imprecise nature of the team ‘design’
• The entire software creation process is design - they make design decisions at every stage
• the part of design that directly affects the end user of the product on one side - on the other side is all other deign. The differentiating factor is human not technical.
• Interaction design: design that directly affects the end user of the product
• The selection of behaviour, function and information and their presentation to users.
• Program design: everything else
• The author wants to take interaction design away from programmers and put it into the hands of dedicated interaction designers.
• Interaction design should be the first consideration in the creation of products.
• Most software is designed by accident.
• Programmers typically don’t use the software they design
• Motivation is key:
• Interaction designers decisions are based on what the user is trying to do
• Programmers decisions are often based on what is easiest to build
• Interface design isn’t enough. It is dressing up existing behaviour, and implies that the product stops at the interface.
• Interaction designers think first conceptually (what is best for the user) then behaviourally (how elements of the software should act and communicate) and only then in terms of interface.
• Don’t make a user feel stupid. Avoid presenting them with ejection-seat levers intermingles with controls for everyday functions.
• Beware of the dancing bear. People gather to see the wondrous sight. The bear is a really terrible dancer. The wonder isn’t that the bear dances well, but that the bear dances at all.
• Difficult interactions are very avoidable
• Cognitive friction doesn’t come from technology, it comes from the people who build it
• Most software creators don’t know how to make their products easy to use, bu they sure know how to add features, so that is what they do.
• Physical objects are subject to a natural brake on the proliferation of marginal features.
• Bloatware:
• Features taken in isolation seem to add utility, but together they all conspire to make the program difficult to understand and use.
• Without a governor, products fill up with unwanted features, creating complexity and confusion for the user.
• Difficulty of operation is increasing more rapidly than utility. Pushing people to either be left behind, or giddy with power at overcoming the difficulty. People are either apologists or survivors. ‘Power user’ is code for an apologist. Survivors meanwhile grit their teeth and don’t look forward to the interactions with the products.
• People’s reaction to cognitive friction is to learn the smallest set of features they need - and abandon the rest.
• 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 it!
• Cognitive friction abandonment can be found in many products.
• Users should not have to acquire computer literacy to use products for common tasks in everyday life. Or at work - if they’re already trained in the domain - their domain knowledge should be enough to see them through.
• “Computer literacy” is a bad concept → drawing red lines around ethnic groups - it’s not inclusive

Chapter 3: Wasting Money

• People obsess over ‘time to market’ - the wisdom goes shipping now is better than shipping later. BUT shipping a product that angers and frustrates users early isn’t great either
• If you lack a clear vision for a product - you can’t assess it’s progress toward completion → you’re more vulnerable
• Once you have a description of what finished software will be - you can have something to compare your product against - so you’ll know if it’s done
• You can either provide a really detailed description of what the product will do → or you can describe the reaction you’d like the end user to have
• Most products just have a shopping list of features.
• Don’t let ‘shipping it’ become your only definition of completion!
• Parkinson’s Law → work will expand to fill the time allotted to it
• 90% done and half way there
• Gresham’s Law - that bad currency drives out good. Bad schedule estimates also drive out good ones. Everyone loves a rosy prediction.
• “Most product managers I’ve worked with would rather ship a failure on time than risk going late”
• If a product is a hit - it’s not a big deal that it ships a month or even a year late. Conversely if a product stinks, who cares that it shipped on time
• Feature-list bargaining is a result of deadline management. They allow programmers to shift blame to management - it wasn’t my fault, I put in all the features management wanted.
• Line of death appears in the backlog - management has two choices, allow more time or cut features
• Features are traded for time, and time for features. Both parties are instantly comfortable with it. Lost though - is the perspective needed for success.
• Don’t meet the deadline and lose the market!
• Programmers assign longer durations to more nebulously defined items, typically those concerned with substantive user-interface issues.
• Programmers tend to cherry pick easier things from the bottom of the list
• Users don’t care about features → they only care about their goals
• Each well-meant feature that might be useful - obfuscates the few features that will probably be useful

• Don’t blame failure on the fickleness of the market for your failure. The side-effect of not understanding your failure to understand the customer → is the silent admission that success it not predictable, leaving us in a spray and pray mindset.
• The web has encouraged us to iterate until something works. Programmers don’t like it, because it means extra work.
• Just because customer feedback improves your understand of your product or service, you cannot deduce that it is efficient, cheap or even effective to toss random features at your customers and see which one are liked and which are disliked.
• How could anyone presume to know what the users want? → This is a staggering question. Your customers don’t want to plow through your guesses to do your design work for you.
• If you keep shipping sketchy versions, you’ll iterate based on the feedback of only those that have the stamina to return to it - skewing your feedback.
• You can learn from trial and error - but those trials should be informed by something more than random chance and should begin from a well-thought-out solutions.
• When software is frustrating and difficult to use, people will avoid using it. Costs are time, reputation and customer loyalty.
• When people are paid to use software (as part of their job) makes users more tolerant but only because they have no choice.
• Don’t start before you know what problem you’re solving. Coding momentum is unstoppable, and the design process starts having to response to the needs of the programmers.
• Starting is like jumping out of the plane stitching a parachute - Don’t think you’ll have something before you hit the ground
• Without a solid design - programmers experiment to find better solutions, which causes waste
• Opportunity cost → building a failure means that you didn’t build a success.
• Prototypes → are experiments made to be thrown out. They have too many foundational short-cuts to scale.
• the value of a prototype is in the education that it gives you, not the code itself

Plan to throw one away Frederick Brooks (author of mythical man month)

• The essence of good programming is deferred gratification, you put in all the work up front, and reap the rewards later.
• Programmers often have to decide wether to back up and restructure, or continue down a shaky path. Both are difficult choices
• If you manage only to deadlines and feature lists, the product might arrive on time but it won’t be desirable. Instead - manage toward quality and user satisfaction and you till get to a product that users want - and it won’t take any longer.

Chapter 4: The Dancing Bear

• Most people are unaware that things could be better - a lot better. Most people assume that all the problems a computer can solve, have been solved. This is far from the truth
• Bill Gates observed → the way you make software user friendly, is to stamp each box with ‘USER FRIENDLY’
• What’s wrong with software?
• Products forget - they don’t adapt to how we use them
• Products are stingy with information - they don’t tell us what is happening, or tell us things that are relevant
• Software is inflexible - inhumane rationality is imposed. System flexibility is key to maintaining social order - fungibility is what makes our manual systems work much better
• Software blames users - Programs push their problems onto users - and blame the usres for it.
• Software won’t take responsibility - Stop asking people if they’re sure - start allowing them to undo actions.

Chapter 5: Customer Disloyalty

• Well-designed products or services generate fierce loyalty
• Three primary qualities in high-technology businesses (from Larry Keeley of Dolblin group)
• Engineers - Capability → What are we capable of, what is possible
• Business people - Viability → What is viable, what can we sell?
• Designers - Desirability → What is desired? What do people want?
• Design makes the product into something people really want.
• It’s best to start with what customers find desirable.
• Desirability is easy to confuse with need - but they are different. You desire a 6 week vacation in Bermuda, you don’ need it.
• Desires emerge after needs are satisfied → people are loyal to their desires. A product that doesn’t have desirability designed into it, might address a robust market need, but it won’t inspire loyalty.
• Apple’s use of design to make the Macintosh desirable - earned it unheard of customer loyalty. Mac fans are reluctant to leap to other vendors for specs, which gives Apple time to react to the competition.
• If you’ve lost the time to market race - focus on desirability.

Chapter 6: The Inmates are Running the Asylum

• General Magic - we never knew what we were building, we didn’t write specifications until 8-12 weeks from the end. Their product was engineered not designed.
• Specifications are not a substitute for interaction design.
• Programmers have a conflict of interest: serve users or make their lives easier
• In many companies software engineers are allowed to control the development process from start to finish. Sometimes they’re driving from the backseat.
• Management often say they don’t have time for the design method
• Design Method: identify key users and stakeholders, write profiles, develops statements of their goals and tasks. From those tasks - come up with visual representations of key objects and interaction behaviours. Then build.
• You get what you measure and reward. If you only talk in deadlines and features, then you’re doing to sacrifice quality. Learn-ability and usability will be sacrificed. Features will be achieved in name only.
• There is a moral imperative to stop wasting people’s lives in useless activities. We don’t have enough engineers in the world to waste their output because we didn’t do design.
• Engineers also care deeply that what they build is used
• CTO told a development manager his spec was a waste of time - even though it exposed huge differences in assumptions about functionality. The inmates are truly running the asylum.
• Anyone untrained in interaction-design tends toward self-referential design (when you imagine yourself as the user). Dragged into a strange place, where you don’t know if you’re done - because you’re not the customer.
• Humans are SO different from computers. Programs need to be written with sensitivity to the needs of computers, and sensitivity to the needs of people. Engineers do the first, interaction designers the second.

Once you eliminate your number one problem, you promote number two Jerry Weinberg

• When computers were really expensive it was cheaper to train people to use bad software, now the opposite is true - we must make software conform to the needs of the users.
• Teaching dogs to be cats → Engineers often say they’re willing to learn design. Engineers work with literal, deterministic, sequential silicon → which is different to the irrational, unpredictable, emotional world of humans. I’m not saying that a programmer can’t become a designer, I’m just saying that it is nearly impossible to do either task well - while attempting to do both simultaneously.

Chapter 7: Homo Logicus

• Tongue in cheek → Programmers are homo logicus: a species slightly - but distinctly different from Homo sapiens. Four ways in which they’re different:
‣
Trade simplicity for control
• The price of control is always more effort and complexity. Programmers have a higher willingness and ability to master extreme complexity.
• Engineers: Control is the goal - and complexity is the price they’re willing to pay
• Normal people: Simplicity is the goal - and relinquishing control is the price they will pay
‣
Exchange success for understanding
• Normal humans are content not to know how something works, even though they use it and depend on it in their everyday lives
‣
Focus on what’s possible to the exclusion of what is probable
• In maths a proposition is only true if it’s always true.
• Programmers: if something might happen then it must be considered. Enormously remote possibilities can’t be ignored (edge-cases)
• Preparation for possible obscures the probable
• There are only three numbers to a programmer: 0, 1 and infinity. Typical humans do things in quantities that in a programmers no-mans-land.
‣
Act like jocks
• Once out of school - physically dominating another person loses its power and usefulness
• If I can beat you in a mental contest, then I am your master, I am better than you
• Mental-jock-dynamic gains power in the adult world of the information age
• They sneer and joke about the ‘L-users’ who are not smart enough to use computers
• Programmers want to be in the pilots cabin, surrounded by complexity but in control. Most people want to be in the passenger cabin, relinquishing control and relaxing.
• Nothing will change unless we can influence the software developers. We need to figure out how to motivate them to create interaction that is good for users.

Chapter 8: An Obsolete Culture

• Reusing code → Prewritten code saves time, code reuse is more important than almost any other technical consideration to programmers.

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

• The side effect of code reuse is that much of the code in an end program exists because it was written by somebody else for something else. Much of software exists because it existed before.
• When programmers implemented Jeff Bezos’ 1-click button, they did so with a confirming question! Jeff pointed out the extra click was 100% inflation.
• Many executives want to bring in interaction designers after the engineers have built most of the functionality. This makes moot most of the designers opportunities to contribute.
• Many executives have had successful products without interaction design - they therefore deduce that software success is simply a crapshoot.
• Programmers doing their own design lose respect for the design process. Bluffing their way through the design process - results in them ultimately having a lack of respect for interaction designers when they do work for them.
• Scarcity thinking → Software products don’t work hard to serve the user - often the user is overworked and the CPU is idle. “Being kind to chips and cruel to users”
• We have to revamp our development methodology so that the humans who ultimately use them are the primary focus
• The two most important process changes
• design interactive products completely before beginning programming
• turn responsibility for design over to trained interaction designers.

Chapter 9: Designing for Pleasure

• Been developing Goal-Directed design since 1992.
• The most powerful tools are always simple in concept, but must be applied with some sophistication.

Personas

• Develop a precise description of our user and what he wishes to accomplish
• Sophistication is in how we determine AND how we use that precise description.
• Finding the user and asking them doesn’t work. Don’t let the user directly affect the solution.
• Make pretend users and design for them (personas). They are the necessary foundation of good interaction design
• Persona’s are hypothetical archetypes of actual users.
• We don’t make up personas - we discover them as a byproduct of investigation
• Defined by their goals → which are determined by successive refinement throughout the investigation of the problem domain
• start with a reasonable approximation and quickly converge on a believable population of personas
• Iterating in this was is quick and easy. Iterating later with code is slow and difficult
• Designing for a single user is the most effective way to satisfy a broad population
• Narrow the target to a single user → and there will be nothing between you and success
• Opening up to a second use can make the experience worse for the first
• It’s OK for 80% of people to hate your product if 20% love it
• Don’t assume your user is elastic - you should be bending to them. Never refer to the user - refer to the persona
• Be specific - the more specific we make personas the more effective they are as design tools. Persona’s lose elasticity as they become specific
• Detail brings solidity → identify skills, motivations and what she wants to achieve
• A persona without a name is not useful → they will never be a concrete person
• Stereotypical personas? → goal is not to be politically correct but to get everyone to believe that my persona’s are real. For a nurse persona - I will use a woman not a man because the overwhelming majority of nurses are female. I am shooting for believability not diversity {ANDY HERE - This makes me uneasy}
• It is more important to be precise than accurate → surprising as the opposite is true for the product. Precision is important - because you don’t want the persona to wiggle under the pressure of development.
• to be precise averages have to be ruled out. People don’t have 2.3 children
• Personas are the single most powerful design tool we use. They are the foundation for Goal-Directed Design.
• they help you see the scope and nature of the design problem
• they make it clear what the user goals are, so we can see what the product must do
• Personas end feature debates.
• Engineer: What if the user wants to print this out? Interaction Designer: Rosemary isn’t interested in printing things out. Engineer: But somebody might want to print it? Interaction Designer: But we are designing for Rosemary, not for someone.
• Never fall back to the ‘user’ construct. This consistency pays off - and programmers beging to adopt personas and refer to them by name.
• It’s the user not the buyer. Designing for the buyer is a frequent mistake.
• Create a cast of characters: 3-12 personas. Often some are defined just to make it clear that we’re not designing for them. Negative persona’s make it clear who we’re not designing for.
• Primary Personas - are the main focus of the design. If there’s more than one primary persona - then they should have a different interface!
• If we find more than 3 primary personas - then the problem is too large and we’re trying to do take on too much at once
• Have a one-page document → print out copies of it → distribute it at meetings → make them unavoidable
• When you make something beautiful at the prototype stage → it’s called painting the corpse
• When you’re defining personas - start with lots and then collapse them down using their similarities.
• Having secondary personas is helpful - you don’t want to make any of them unhappy, but you don’t have to make them exceptionally happy

Chapter 10: Designing for Power

• Goal directed design starts with personas and their goals
• A persona exists to achieve his goals.
• Goals are the reasons why we perform tasks.
• Goals over tasks.
• Cognitive friction comes with interaction, and interaction is only needed if there is a purpose, a goal.
• With a clear persona goal - we learn what is fit for purpose and what isn’t, it’s clear what should be built
• Help users achieve their practical goals without violating their personal goals (feeling stupid)
• Tasks are not goals → A goal is an end condition, a task is an intermediate step needed to achieve the goal.
• Tasks change as technology changes, but goals remain stable
• When you use goals and not tasks to analyse interactions - you can find different and much better solutions
• The distinction between personal goals and practical goals is critical to success.
• Personal goals are simple, universal.
• Not to feel stupid, not to make mistakes, get work done, have fun
• Principle of Commensurate Effort → People are willing to invest extra effort if they’re going to receive extra rewards for it
• You also have to take into consideration corporate goals: profit, market share, defeat competition, hire more people, offer more products, go public
• False goals → save memory, save keystrokes, run in a browser, be easy to learn, speed up data entry
• A fighter pilot who’s controls were easy to learn but slow to operate wouldn’t be much good
• Humans react to computers like we do other humans - design for politeness if we want users to like our software.

‣

4 principles for polite software → quality, quantity, relevance and clarity

• Humans like to take actions out of sequence

Chapter 11: Designing for People

• Personas → Goals → Scenarios
• Scenarios are concise description of a persona using a product to achieve a goal
• The scenario process is a little like method acting - putting your persona through the process of achieving their goal
• You have to remove tasks that were only their for historical reasons.
• Breadth is more important than depth - getting from start to end is more important than defining all the detail
• Two key types → Daily use scenarios and necessary use scenarios
• Daily is most useful and important. The main actions users perform, typically with the greatest frequency. Typically less than 3 scenarios.
• Necessary-use scenarios include all the actions that must be performed - but that are not performed frequently. There will be more of them than daily use scenarios.
• Edge-case scenarios: Designs can be rough and pushed way into the background of the interface.
• Code succeeds or fails in its ability to handle edge cases → the product will succeed or fail in it’s ability to handle daily use and necessary cases
• If a user performs a task frequently - its interaction mush be well crafted. Tasks that are neither frequent or necessary don’t require careful design.

• Inflecting the interface → The interface can be simplified by placing only the controls and data needed for the daily-use scenarios prominently in the interface and moving all others to secondary locations out of normal sight.
• Perpetual Intermediates → most users are neither beginners nor experts; instead they are perpetual intermediates.
• Everyone spends some time as a beginner - nobody stays there for long.
• When people achieve an adequate level of experience and ability they tend to stay there
• Developers tend to cater for experts. Marketers for beginners. But most users are in the middle!
• Pretend it’s magic → assume you have a magic computer to help you through your scenario. By imagining magic technology - we force the tasks to change and we highlight the goals
• Reality never needs an advocate - because it can never be denied. Constraints are often illusory and self-imposed - so it’s important that you can step around them.
• Less is more → a user is unaware of a good interaction designer. Each element of the interface is a burden on the user. A good designer removes interface from the product.
• Most breakthrough conceptual advances are opaque in foresight and transparent in hindsight

Chapter 12: Desperately Seeking Usability

• The most important aspect of design is the sequence
• Program → Bug test / User test → Tweak ❌
• Design → Program → Bug test / User test → Tweak ✅
• Just because design should come first - it doesn’t mean that it’s more important than engineering.
• The unpredictable market is a myth - design first helps
• Usability testing and the end and tweaking it, is like taking sandpaper to a chair. No amount of sanding will turn a chair into a table.
• By testing one program against another - you only know which is better, you don’t know what was possible to achieve
• Put design in front of programming.
• Programmers designing - Their culture and tools were wholly inadequate to the task. Regardless of how much you might teach, test or design, you are a programmer if you program professionally.
• Interaction designers rely on their experience, training and judgment to make an accurate evaluation.
• Style guides don’t address Goal-Directed interaction design problems.
• Focus groups are troublesome in the software business. They rely on the assumption that people can be introspective about experiences.

Users will reject new ideas if you ask them Larry Keeley

• Be wary of iterating to a good design. The attrition strategy is expensive and time-consuming. Only works with a rock solid brand, lots of time, nerves of steal, and vast amounts of money.

Chapter 13: A Managed Process

• Customers should take precedence over the different discipline leads.
• Beware of the customer-driven death spiral. Customers request changes and additions. There is a big difference between listening to and following your customers.
• Listening → apply your own filter to what you have heard
• Following → merely doing what your customers tell you to do
• If you follow you cease to become a product company and you become a service company.
• When customers come with a cheque and a feature requests managers find it irresistible. They are riding the tiger.
• The customer doesn’t have your best long-term interests at heart, and it doesn’t know how to design your product
• Conceptual integrity is a core competence → a single-minded vision of a product
• Without it customers take control
• Are you a product company or a service company?
• Take a longer view. Walk away from short-term lucrative deals. If you have confidence to walk away, they may gain trust in you and reevaluate their ask.
• When you overlap design with programming - what you get is programming. Do design first.
• Use your personas, goals and scenarios to help understand wether you should respond to a customer request.
• Letting non-designers cut features is like anyone cut wires in an airplane - it’s random and dangerous
• Movie makers realise that shooting the movie is the expensive part - so it’s planned well in advance. The purpose of pre-production is to minimise the production phase.
• Management must commit to bringing in design before programming. Design must take full responsibility for the success of the products. Design must put their thoughts in writing.
• Great design is meaningless unless it gets built. It won’t be built unless described at length, with precision, and detail, in terms that make sense to programmers (with supporting evidence and examples).
• Interaction designers are like architects, deliver a set of blueprints that describe the product to be built. A sufficiently detailed specification is indistinguishable from the code that implements it.
• The design document must omit some things - designers must know what is important
• The designer must know what parts of the program need to be designed, and which don’t
• Organise design documents in the spiral method → allowing the reader to take what they want
• Headline: tells the entire tale
• First paragraph: tells the story with a bit more detail
• Next 3 paragraphs: tell the story once again, with more information
• Remainder of the article: tells the entire story in complete detail
• Interface design is what’s done after both the purpose and behaviour of the product are established. A bad product in beautiful and imaginative wrapping is still a bad product
• Design is a product-definition process.
• Bad managers are easier to find than good programmers. Product managers are weak if they cannot articulate with precision and conviction exactly what it is they are building.
• Give programmers a difficult problem worth solving.
• A designer is a person that can translate from marketing to programming
• Good design eliminates the need for lots of documentation, fewer complex interactions means fewer long explanations.
• A designed product makes the programming phase more predictable.
• By vanquishing deadline management and feature-list negotiation → focus turns to quality → which in turn generates more customer loyalty.
• The interaction designer should be the ultimate owner of product quality. Should be able to determine the content and behaviour of the program. Own the feature list and the schedule. They are the advocate for the user and should have the authority to control all external aspects of the product.
• Designers need the combination of authority and responsibility to be respected by programmers.
• Mandate → designing a feasible-to-build, easy-to-use, attractive product that allows the user to achieve her practical goals without violating her personal goals. Describe and document things in a way engineers can understand.
• Designers must accept responsibility for the quality of the final product

Chapter 14: Power and Pleasure

• Bake interaction design into the software-development process. Don’t tack it on afterwards.
• Make it clear to everyone that design is a blueprint that must be followed
• The design team must have responsibility for everything that comes in contact with the user
• Build a company wide awareness of design.
• Technology doesn’t have to be dehumanising.
• Interaction design - makes your product desirable, inspiring consumer loyalty. If your product is dancing bearware, your customers will be quietly casting their eyes around looking for easier, friendlier alternatives.
• Interaction design can shorten the amount of time you spend developing your product.
• Throwing away less code on the path to a successful product will save you money and time

It is easier to convince consumers software is easy to use, than it is to actually make it easier to use Seymour Merrin

• Change will only occur when those with influence early in the product life cycle become interested in fixing this problem