When I read a book I have the habit of highlighting certain passages I find interesting or useful. After I finish the book I’ll type up those passages and put them into a note on my phone. I’ll keep them to comb through every so often so that I remember what that certain book was about. That’s what these are. So if I ever end up lending you a book, these are the sections that I’ve highlighted in that book. Enjoy!
This is the 3rd edition of the book. I know the 4th is out now and if I end up reading it I’ll add to these notes!
The web dominates all sales and marketing. Live humans are no longer the front line of businesses. Software plays that role instead.
Once a software program has been successfully written, it can be reproduced an unlimited number of times for virtually nothing. There is little benefit in reducing the cost of writing it. Reducing the amount one spends on software construction usually means compromising the quality.
According to Gestalt Theory, people perceive a thing not as a set of individual features and attributes but as a unified whole in a relationship with its surroundings. Even a relatively simple product must be considered in totality and in light of its context in the world.
Some job titles in this field: Information Designer, Information Architect, User Experience Strategist, Interaction Designer, and Chief Experience Officer.
Style guides are good at answering what, but generally weak at answering why.
Adding “easy to use” to the list of requirements does nothing to improve the situation.
Error messages pop up like weeds announcing that the user has failed yet again. These messages also demand that the user acknowledge his failure by agreeing: OK
The feature-rich Palm Treo smartphone doesn’t anticipate that a user might want to add the phone number of someone who has just called to an existing contact. It doesn’t take a lot of research or imagination to deduce that this is something that many users will want to do, but nevertheless one is force to go through a complicated maze involving copying the phone number, navigating to the contact in question, and pasting into the appropriate field.
There is a compelling reason for involving designers in the research process. One of this most powerful tools designers bring to the table is empathy.
Behavior patterns – Identifiable behaviors that help categorize modes of use of a potential or existing product.
Behavior patterns suggest goals and motivations. In business and technical domains, these behavior patterns tend to map into professional roles; for consumer products, they tend to correspond to lifestyle choices. Behavior patterns and the goals associated with them drive the creation of personas.
Specific design targets are chosen from the cast of personas through a process of comparing goals and assigning a hierarchy of priority based on how broadly each persona’s goals encompass the goals of other personas.
Personas represent a powerful communication tool that helps developers and managers to understand design rationale and to prioritize features based on user needs.
Market research helps select and filter valid personas that fit business models.
Interaction design is not guesswork.
Great questions early in the personas phase are:
- Who are my users?
- What are my users trying to accomplish?
- How do my users think about what they’re trying to accomplish?
- What kind of experiences do my users find appealing and rewarding?
People don’t need to know all the details of how a complex mechanism actually works in order to use it, so they tend to create a cognitive shorthand for explaining it.
- Many people imagine electricity flows like water from the wall to the appliances through the little black tube of the electrical cord. In actuality, there is a reversal of electrical potential 120 times per second.
- We tend to ignore the fact that our cellular telephone is actually a radio transceiver that might swap connections between a half-dozen different cellular base antennas in the course of a two-minute call.
- Pressing the brake pedal in your car may conjure a mental image of pushing a lever that rubs against the wheels to slow you down. The actual mechanism includes hydraulic cylinders, tubing, and metal pads the squeeze on a perforated disk, but we simplify all that out of our minds, creating a more effective, albeit less accurate, mental model.
- Nontechnical computer users imagine that their video screen is the heart of their computer. The computer is actually a little chip of silicon in that black box sitting under his desk.
The model for how the software actually works is called the implementation model. The way users perceive the jobs they need to do and how the program helps them do it is ther mental model of interaction with the software.
The closer the represented model comes to the user’s mental model, the easier he will find the program to use and to understand. Generally, offering a represented model that follows the implementation model too closely significantly reduces the user’s ability to learn and use the program.
User interfaces that are consistent with users’ mental models are vastly superior to those that are merely reflections of the implementation model.
Interaction designers must shield users from implementation models.
Users don’t understand Boolean logic.
The fruits of new technology can often only be expressed at first with the language of an earlier technology. We called railroad engines iron horses and automobiles were labeled horseless carriages.
Don’t replicate mechanical-age artifacts in user interfaces without information-age enhancements. When mechanical representations are replicated without change, they combine the weakness of the old with the weakness of the new. When designers rely on mechanical-age representations to guide them, they are blinded to the far greater potential of the computer.
In the nondigital world, calendars are made of paper and are usually divided up into a one-month-per-page format. Computer screens are not so constrained, but most designers copy the Mechanical-Age artifact faithfully. The calendar could easily be a continuously scrolling sequence of days, weeks or months, or the grid pattern could be not just a fixed size. Why can’t the width of columns of day or the height of rows of weeks be adjustable like a spreadsheet?
Buying a new cell phone usually pairs with several days of frustration and disappointment spent learning the new interface. On the other hand, many experienced users may find themselves continually frustrated because the product treats them like beginners.
One of the eternal conundrums of interaction and interface design is how to address the needs of both beginning users and expert users with a single, coherent interface.
Although everybody spends some time as a beginner, nobody remains in that state for long.
Although beginners quickly improve to become intermediates, they seldom go on to become experts.
Learning and improving is rewarding, so beginners become intermediates very quickly – or they drop out altogether.
Most users remain in a perpetual state of adequacy striving for fluency, with their skills ebbing and flowing like the tides depending on how frequently they use the product.
In many cases, a well-balanced user interface doesn’t cater to the beginner or to the expert, but rather devotes the bulk of its efforts to satisfying the perpetual intermediate. Sometimes these intermediates use the product extensively for weeks at a time to complete a big project. During this time, they learn new things about the product. Sometimes however, they do not use the product for months at a time and forget significant portions of what they knew.
In some specialized products, it is appropriate to optimize the user experience for experts. In particular, tools that technically minded people rely on for a significant portion of their professional responsibilities should be inflected towards a high degree of proficiency. We expect users of those product to come to the table with the necessary technical knowledge, and to be willing to invest significant time and effort to mastering the application.
Our goal is threefold:
- To rapidly and painlessly get beginners into intermediacy
- To avoid putting obstacles in the way of those intermediates who want to become experts
- To keep perpetual intermediates happy as they stay firmly in the middle of the skill spectrum
If a ski instructor begins lecturing on snowpack composition and meteorology, he will lose his students regardless of their aptitude for skiing.
Imagine users as very intelligent but very busy.
Intelligent people always learn better when they understand cause and effect, so you must give them an understanding of why things work as they do. We use mental models to bridge the contradiction. If the represented model of the interface closely follows the user’s mental model, it will provide the understanding the user needs without forcing him to figure out the implementation model.
To get beginners to a stage of intermediacy requires extra help. This extra help will get in their way as soon as they become intermediates. Whatever extra help you provide, it must not be fixed into the interface (Or at least as prominent).
The average skier may find it inspirational to know that there is a really scary, black-diamond, expert run just beyond those trees, even if he never intends to use it. It gives him something to aspire to and dream about, and it gives him the sense that he’s at a good ski resort.
In order to design a successful product, you have to have 3 things:
- A clear and detailed knowledge of the users you’re designing for
- The constraints of the problem
- The business or organizational goals
In almost all cases, the reason a product is being designed (or redesigned) is to achieve specific business outcomes (most commonly – make money). It is the designer’s obligation to develop solutions without ever losing sight of these business goals.
Subject Matter Experts represent a somewhat skewed perspective. They are often expert users. They may also lean towards expert controls rather than interactions designed for perpetual intermediates.
Most people are incapable of accurately assessing their own behaviors, especially when they are removed from the context of their activities.
You can talk to users about how they think they behave, or you can observe their behavior first-hand. The latter route provides superior results.
Interviewers must take care to not make video recorders too obtrusive; otherwise the users will be distracted and behave differently than they would off-camera.
Typically, we won’t bring out the camera until we feel that we’ve established a good rapport with the interview subject, and then we use it to capture things about the environment that are difficult to jot in our notes.
Video can sometimes provide a powerful tool for achieving stakeholder buy-in to contentious or surprising research results.
It is often quite helpful for the design team to examine any existing version or prototype of the product, as well as its chief competitors. Comparing each interaction and visual design principle familiarizes the team with the strengths and limitations of what is currently available to users.
Contextual inquiry (Interview strategy) follows a master-apprentice model. It’s based in observing and asking questions of the user as if he is the master craftsman, and the interviewer is the new apprentice.
- Rather than interviewing the user in a clean white room, it is important to interact with and observe the user in his normal work environment.
- The interviewer and observation should take the tone of a collaborative exploration with the user, alternating between observation of work and discussion of its structure and details.
- Rather than coming to interviews with a set questionnaire or letting the interviewer wander aimlessly, the designer needs to subtly direct the interviewer so as to capture data relevant to design issues.
- First identify and prioritize user goals before determining the tasks that relate to these goals.
- Interviews as short as 1 hour can be sufficient to gather the necessary user data, provided that sufficient number of interviews (6-8) are scheduled.
Basic Methods
- Interview where the interaction happens
- Observe the environment closely: it is likely to be crawling with clues about tasks the interviewee might not have mentioned (Cheat sheets, user manuals, memos, charts, calendars)
- Avoid a fixed set of questions
- The entire premise of interviews is that we as interviewers don’t know enough about the domain to presuppose the questions that need asking.
- What makes a good day? A bad day?
- What activities currently waste your time?
- What is most important to you?
- What helps you make decisions?
- What are the most common thing you do with the product?
- What parts of the product do you use the most?
- What are your favorite aspects of the product? What drives you crazy?
- How do you work around problems?
- What shortcuts do you employ?
- What did you do when you first came in today? And after that?
- How often do you do this? What things do you do weekly or monthly, but not every day?
- What constitutes a typical day? What would be an unusual event?
- What do you see yourself doing five years from now?
- What do you prefer not to do? What do you procrastinate on?
- What do you enjoy most about your job (or lifestyle)? What do you always tackle first?
- Focus on goals first, tasks second
- What motivates the behaviors of individuals in different roles?
- Avoid making the user a designer
- If an user blurts out an interesting idea, ask “What problem would that solve for you?” or “Why would that be a good solution?”
- Encourage storytelling
- Encourage stories that deal with typical cases and also more exceptional ones.
- Ask for a show and tell
- It is often useful to ask the interviewee for a show and tell or grand tour of artifacts related to the design problem.
- Avoid leading questions
Focus groups tend to drive to consensus. The majority loudest opinion often becomes the group opinion.
Interaction design is first and foremost the design of behavior that occurs over time.
Just as storyboards breathe life into a movie script, design solutions should be created and rendered to follow a plot – a story.
Personas model goals and not simply tasks.
Many designers are tempted to jump right into active design and render possible solutions. This runs the risk of turning into a never-ending circle of iteration.
Define what the product will do before you design how the product will do it.
The reason we brainstorm is to get ideas out of our heads so that we can record them and thereby “let them go” for the time being.
Context scenarios are where the design begins. As you develop context scenarios, you should be focusing on how the product you are designing can best help your personas achieve their goals. Context scenarios establish the primary touch points that each primary and secondary persona has with the system.
Context scenarios should be broad and relatively shallow in scope. They should focus on high-level actions from the user’s perspective. They should address questions such as the following:
- In what setting(s) will the product be used?
- Will it be use for extended amounts of time?
- Is the persona frequently interrupted?
- Are there multiple users on a single workstation or device?
- With what other products will it be used?
- What primary activities does the persona need to perform to meet his goals?
- What is the expected end result of using the product?
- How much complexity is permissible, based on persona skill and frequency of use?
Context scenarios should not represent system behaviors as they currently are. Focus on user goals. Don’t yet worry about exactly how things will get accomplished.
At this point we are not yet discussing the form, only the behaviors of the user and the system.
Persona example: Viven Strong, a real-estate agent in Indianapolis, whose goals are to balance work and home life, close the deal, and make each client feel like he is her only client.
Context Scenario example:
- While getting ready in the morning, Vivien uses her phone to check her e-mail. It has a large enough screen and quick connection time so that it’s more convenient than booting up a computer as she rushes to make her daughter, Alice, a sandwich for school.
- Vivien sees an e-mail from her newest client, Frank, who wants to see a house this afternoon. The device has his contact info, so now she can call him with a simple action right from the e-mail.
- While on the phone with Frank, Vivien switches to speakerphone so she can look at the screen while talking. She looks at her appointments to see when she’s free. When she creates a new appointment, the phone automatically makes it an appointment with Frank, because it knows with whom she is talking. She quickly enters the address of the property into the appointment as she finishes her conversation.
- After sending Alice off to school, Vivien heads into the real-estate office to gather some papers for another appointment. Her phone has already updated her Outlook appointments, so the rest of the office knows where she’l be in the afternoon.
- The day goes by quickly, and she’s running a bit late. As she heads towards the property she’l be showing Frank, the phone alerts her that her appointment is in. 15 minutes. When she flips open the phone, it shows not only the appointment, but a list of all documents related to Frank, including e-mails, memos, phone messages, and call logs to Frank’s number. Vivien presses the call button, and the phone automatically connects to Frank because it knows her appointment with him is soon. She lets him know she’ll be there in 20 minutes.
- Vivien knows the address of the property but is a bit unsure exactly where it is. She pulls over and taps the address she put into the appointment. The phone downloads directions along with a thumbnail map showing her location relative to the destination.
- Vivien gets to the property on time and starts showing it to Frank. She hears the phone ring from her purse. Normally while she is in an appointment, the phone will automatically transfer directly to voicemail, but Alice has a code she can press to get through. The phone knows it’s Alice calling, and uses a distinctive ring tone.
- Vivien takes the call — Alice missed the bus and needs a pickup. Vivien calls her husband to see if he can do it. She gets his voicemail; he must be out of service range. She tells him she’s with a client and asks if he can get Alice. Five minutes later the phone makes a brief tone Vivien recognizes as her husband’s; she sees he’s sent her an instant message: “I’ll get Alice; good luck on the deal!”
Also notice how the activities in the scenario tie back to Viven’s goals and try to strip out as many tasks as possible.
A powerful tool in the early stages of developing scenarios is to pretend the interface is magic. If your persona has goals and the product has magical power to meet them, how simple could the interaction be? This kind of thinking is useful to help designer look outside the box. Magical solutions obviously won’t suffice, but figuring out creative ways to technically accomplish interactions that are as close to magical solutions as possible (from the persona’s perspective) is the essence of great interaction design.
There’s lots of value in low-fidelity presentation techniques in gathering user feedback – a study of people’s reaction to different types of CAD images found that pencil-like sketches encouraged discourse about a proposed design.
Pretend the product is human – What would a helpful human do? What would a thoughtful, considerate interaction feel like? How can it minimize the persona’s effort in reaching his goals?
There is only one user experience – form and behavior must be designed in concert with each other.
To be clear, usability testing is, at its core, a means to evaluate, not to create.
Personas
Personas are not real people, but they are based on the behaviors and motivations of real people we have observed and represent them throughout the design process.
Although personas are depicted as specific individuals, they represent a class or type of user.
Understanding personas is more about understanding motivations and goals.
Personas do not seek to establish an average user, but rather to express exemplary to definitive behaviors within these identified ranges.
Don’t confuse persona archetypes with stereotypes. Stereotypes represent biases and assumptions, rather than factual data.
Personas are derived from patterns observed during interviews with and observations of users and potential users.
None of this “persona supplemental data” can take the place of direct user interviews and observation. Almost every aspect of a well-developed persona can be traced back to a user statement or behavior.
Good models emphasize the salient features of the structures and relationships they represent and de-emphasize the less significant details.
For a successful product, you need to design for specific types of individuals with specific needs.
When you broadly and arbitrarily extend a product’s functionality to include many constituencies, you increase cognitive the load and navigational overhead for all users.
If you try to design an automobile that pleases every possible driver, you end up with a car with every possible feature, but that pleases nobody.
Prioritize specific individuals so that the needs of the most important users are met without compromising our ability to meet the needs of secondary users.
Many “cool” product designs fall into this category where the audience doesn’t extend beyond people like the designer.
IF the designer doesn’t respect his personas, nobody else will either.
The function and behavior of the product must address goals via tasks – typically, as few as absolutely necessary. Remember, tasks are only a means to an end; goals are that end.
You usually can’t ask a person what his goals are directly. Either he won’t be able to articulate them, or he won’t be accurate or even perfectly honest.
One of the most critical tasks in the modeling of personas is identifying goals and expressing them succinctly: Each goal should be expressed as a simple sentence.
A misconception is that designing for visceral response is about designing beautiful things. Visceral design is actually about designing for affect – eliciting the appropriate psychological or emotional response for a particular context. Beauty, and the feelings of transcendence and pleasure it evokes, is really only a small part of the possible affective design palette.
Users tend to initially judge attractive interfaces to be more usable. This may be because users make a greater effort to learn what may be a challenging interface and are then unwilling to consider their investment ill spent.
Experience goals are simple, universal, and personal. Examples include:
- Feel smart or in control
- Have fun
- Feel cool or hip or relaxed
- Remain focused and alert
When products make users feel stupid or uncomfortable, their self-esteem drops and their effectiveness plummets.
End goals represent the user’s motivation for performing the tasks associated with using a specific product.
Life goals represent deep drives and motivations the help explain why the user is trying to accomplish the end goals he seeks to accomplish. For example:
- Live the good life
- Succeed in my ambitions to…
- Be a connoisseur of…
- Be attractive, popular, or respected by my peers
A product that the user discovers will take him closer to his life goals, and not just his end goals, will win him over more decisively than any marketing campaign.
A user’s most important goal is always to retain his human dignity: not to feel stupid. We can reliably say that we make the user feel stupid if we let him make big mistakes, keep him from getting an adequate amount of work done, or bore him.
Optimizing the experience of the user means minimizing work. Types of work to be minimized are:
- Cognitive work – comprehension of product behaviors
- Memory work – recall of product behaviors and relationships between objects
- Visual work – figuring out where the eye should start on a screen, finding one object among many, decoding layouts, and differentiating among visually coded interface elements
- Physical work – switching between input modes, and number of clicks required to navigate
Certain kinds of entertainment products (such as games) are able to engage users to do just the right amount of a certain kind of work and rewards them for doing so.
One of the classic elements of good design is economy of form: using less to accomplish more.
- In interface design, this means using only the screens and widgets necessary to accomplish the task.
- In behavioral design, this means using a simple set of tools for the user that allows him to accomplish great things.
- In visual design, this means using the smallest number of visual distinctions that cleary convey the desired meaning.
All the above is Goal-Directed Interaction Design.
Physical products are used in much different contexts than computers. Idioms that have become accepted on a PC are completely inappropriate on an embedded device. “Cancel” is not an appropriate label for a button to turn off an oven, and requiring people to enter a “settings” mode to change the temperature on a thermostat is preposterous.
Much better than trying to squeeze a computer interface into the form factor of a small-screen device is to see it for what it is and to then figure out how digital technology can be applied to enhance the experience.
For kiosks, the contextual concerns focus more on the environment in which the kiosk is being placed. Questions to ask are:
- What role does the kiosk play in the environment?
- Is the kiosk in the main flow of public traffic?
- Does it provide ancillary information, or is it the main attraction itself?
- Does the architecture of the environment guide people to the kiosks when appropriate?
- How many people are likely to use the kiosk at a time?
- Are there sufficient numbers of kiosks to satisfy demand without a long wait? Is there sufficient room for the kiosk and kiosk traffic without impeding other user traffic?
You must carefully map out embedded systems’ displays, developing a hierarchy of information. Determine what is the most important information to get across, and make that feature the most prominent. then, look to see what ancillary information can still fit on the screen.
Controls that can display their own state are valuable, such as hardware buttons with LEDs or hardware that maintains a physical state (toggles, switches, sliders, knobs).
To make people more productive and happy, we must design interactive products to promote and enhance FLOW, and for us to go to great pains to avoid any potentially flow-disturbing behavior. If the application consistently rattles a user and disrupts his flow, it becomes difficult for him to maintain that productive state.
No matter how cool your interface is, less of it would be better.
A user interface is an artifact, not directly associated with the goals of an user. Next time you find yourself crowing about what cool interaction you’ve designed, just remember that the ultimate user interface for most purposes is no interface at all.
To create a sense of flow, our interaction with software must become transparent. When a novelist writes well, the craft of the writer becomes invisible, and the reader sees the story and characters with clarity undisturbed by the technique of the writer.
When a product interacts well with a person, interaction mechanics disappear, leaving the person face to face with this objectives, unaware of the intervening software.
In this situation, these idioms are simple enough to learn easily, and the consequences of getting it wrong are fairly small, so it’s had little impact on the overall success of the product.
One of the reasons interactive products often aggravate people is that they don’t act like cars or hammers. These are simple products that provide direct output. No dialog boxes needed about failed states.
There are several ways for an application to present information or feedback to users. Unfortunately, the most common method is to pop up a dialog box on the screen. A better way to inform users s with modeless feedback.
Feedback is modeless whenever information for users is built into the structure of the interface and doesn’t stop the normal flow of activities and interaction. In Microsoft Word, you can see what page you are on, what section you are in, how many pages are in the current document, and what position the cursor is in, modelessly just by looking at the status bar at the bottom of the screen.
In Word 2003, if you want to know the number of words in your document, you must choose Word Count…from the tools menu. this opens a dialog box. To get back to work, you must first click the Close button the Word Count dialog.
To a logician, if a proposition is true 999,999 times out of a million and false one time, the proposition is false. The proposition has a possibility of being false, but the probability of it being false is minuscule to the point of irrelevancy.
For example, a user has the choice of ending the application and saving his work, or ending the application and throwing away the document he has been working on for the last six hours. Ye the typical application always includes a dialog box asking the user if he wants to save his changes.
the obtrusive presence of edge case possibilities is a dead giveaway for user interfaces designed by programmers.
Avoid unnecessary reporting. For users, it is disconcerting and distracting to know all the details of what is happening.
Don’t use dialog boxes to report normalcy. Don’t’ stop the proceedings and bother an user with problems that are not serious. If the application is having trouble creating a connection to a server, don’t put up a dialog box to report it. Instead, build a status indicator into the application so the problem is clear to the interested user but is not obtrusive to someone who is busy elsewhere. Instead, take a goal-directed approach. You must ask yourself whether a particular interaction moves a person rapidly and directly to his goal.
It is better to make a user ask explicitly for configuration one time in ten than it is to make a user reject the configuration interface nine times in ten.
In The Media Equation (Cambridge University Press, 1996), Stanford sociologists made a compelling case that humans treat and respond to computers and other interactive products as if they were people. We should thus pay real attention to the “personality” projected by our software. is it quietly competent and helpful, or does it whine, nag, badger, and make excuses?
The best interfaces often don’t leave users in awe of their beauty, but rather are hardly even noticed because they can be used effortlessly.
Any large task, such as driving to the office, involves many smaller tasks. Some of these tasks work directly towards achieving the goal; these tasks are like steering down the road towards your office. Excise tasks, on the other hand, don’t contribute directly to reaching the goal, but are necessary to accomplishing it just the same. Such tasks include opening and closing the garage door, starting the engine, and stopping at traffic lights.
Excise is the extra work that satisfies either the needs of our tools or those of outside agents as we try to achieve our objectives. The distinction is sometimes hard to see because we get so used to the excise being part of our tasks.
Stopping at red lights is something imposed on us by our society that, again, doesn’t help us achieve our true goal.
Examples of excise tasks in software are installation, configuring networks, and backing up our files.
The problem with excise tasks is that the effort we expend in doing them doesn’t go directly towards accomplishing our goals.
The command-line interface forces an even more expensive excise budget on users: They must first memorize the commands.
Allow input wherever you have output.
The most effective method of improving navigation sounds quite obvious: Reduce the number of places to which one must navigate. These “places” include modes, forms, dialogs, pages, windows, and screens.
Commonly, interactive products irritate us because they aren’t considerate, not because they lack features.
The rest of this book is mostly about designing for desktop and web. Since i’m not into that currently, I skipped it!
@joekotlan on X