Notes from About Face, The Essentials of Interaction Design 3 by Alan Cooper, Robert Reimann and David Cronin.

Design Principles

Interaction design is not guesswork.  Goal-Directed Design is a powerful tool for answering the most important questions that crop up during the definition and design of a digital product, such as

• 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?
• How should my product behave?
• What form should my product take?
• Who will (should) users interact with my product?
• How can my product’s functions be most effectively organized?
• How will my product introduce itself to first-time users?
• How can my product present technology?
• How can my product deal with problems that users encounter?
• How can my product provide sufficient depth and power for expert users?

User interfaces should be based on user mental models rather than implementation models.  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.

Goal-directed interactions reflect user mental models.  If the represented model for software closely follows users’ mental models, it eliminates needless complexity from the user interface by providing a cognitive framework that makes it evident to the user how his goals and needs can be met.

Don’t replicate mechanical-age artifacts in user interfaces without information-age enhancements.  Real-world mechanical systems have the strengths and weaknesses of their medium, such as pen and paper.  Software has a completely different set of strengths and weaknesses, yet when mechanical representations are replicated without change they combine the weaknesses of both.

Nobody wants to remain a beginner. Most beginners will either migrate into intermediates or will eventually stop using the product or activity and find one in which they can migrate into intermediacy.

Optimize for intermediates.  Experience levels of people using the product tend to follow the classical bell curve, where most are intermediate level users.  A well-balanced user interface doesn’t cater to the beginners or experts, but rather devotes the bulk of its efforts to satisfying the perpetual intermediate. It also provides mechanisms for beginners to advance and experts to automate and speed up production.

Imagine users as very intelligent, but very busy.  Just because a user needs to learn how to operate a product doesn’t mean that he needs or wants to learn how it works inside. At the same time, they learn better when they understand cause and effect, so you must give them an understanding why things work as they do. Analogies work well here.

Don’t make the user feel stupid.  Avoid letting the user make big mistakes, keep her from getting an adequate amount of work done, or boring her.

Focus the design of each interface on a single, primary persona. This is the primary target for the design of the interface.  If you target for the primary, other personas such as secondary, supplemental, and others will be dissatisfied. However, the primary persona will be dissatisfied if you target the interface towards a specialized persona.

Define what the product will do before you design how the product will do it.  Defining the need or requirement beforehand prevents a never-ending circle of iteration; proposing a solution before clearly defining and agreeing upon the problem.

Never show a design approach that you’re not happy with; stakeholders just might like it.  All the choices you present to the stakeholders should be reasonable and appropriate. It is almost an unwritten rule that if there’s one direction that you don’t want your client or stakeholder to choose, that’s the one they’re guaranteed to like.

Optimize sovereign applications for full-screen use.  In most cases, sovereign applications run maximized. The application needs to be fully resizable and must work well in other screen configurations, but the interface should be optimized for full-screen use instead of the less common cases.

Sovereign interfaces should feature a conservative visual style.  Because users may stare at a sovereign application for long periods, you should mute the colors and texture of the visual presentation. Keep the color palette narrow and conservative. Big colorful controls seem garish after a couple weeks. Tiny dots or accents will have more effect in the long run than big splashes, and allow you to pack controls together more tightly.

Sovereign applications should exploit rich input.  Direct manipulation, dialog boxes, keyboard mnemonics, and keyboard accelerators are all appropriate. In a jet cockpit, most frequently-used controls are situated directly in front of the pilot; those used only occasionally are found on sides, etc.

Maximize document views with sovereign applications.  Client windows containing documents should always be maximized inside the application unless the user explicitly instructs otherwise.

Transient applications must be simple, clear and to the point.  Transient applications are temporary in nature so users do not get the chance to become familiar with it, so the product’s user interface must be obvious.  It should spell out what it does. This is not the place for artistic but ambiguous images or icons.

Transient applications should be limited to a single window and view.  Never force the user into supporting subwindows or dialog boxes. All information should be right there on the surface of the single window.

A transient application should launch to its previous position and configuration.  If the widows remembers where it was the last time it was used, the chances are excellent that the same size and placement will be appropriate this time, also.

Kiosks should be optimized for first-time use. This is especially true for tourist based kiosks where the chance of intermediate or expert users is slim to none.

No matter how cool your interface is, less of it would be better.  Users actually prefer no interface at all, as interacting with software will never be an entirely pleasing experience (with some obvious exceptions, such as games, creative tools and content-delivery systems like web browsers). The UI is an artifact and not directly associated with the goals of the user.

Well-orchestrated user interfaces are transparent.  To create a sense of flow, our interaction with software should be transparent. A good interaction designer must train himself to hear sour notes in the orchestration of software interaction.  It is vital that all the elements in the interface work coherently together towards a single goal.

Follow users’ mental models. While different people have different mental models of a given activity or process, they rarely imagine them in terms of the detailed mechanics how computers function.

Less is more. We should constantly strive to reduce the number of elements in user interfaces without reducing the capabilities of the products we are creating.

Enable users to direct the software; don’t force them to discuss it. Users prefer to interact with software in the same way they interact with, say, their cars. They do not want to engage in dialogue. The users should have the ability to demand information from the software, not vice versa.

Various Notes

Manufacturing costs used to dominate, but software-dominated businesses now see significant costs in software development.

Interaction design is the practice of designing interactive digital products, environments, systems and services. It is not only concerned with form, but with the design of behavior.

Computer-based appliances have much more complex behavior than before. Digital products may be capable of 1000s of different states.

Gestalt Theory states that people perceive a thing not as a set of individual features and attributes, but as a unified whole in a relationship with its surroundings.

There have been many terms over the years for designing user interfaces, including:

• Software design
• User interface design
• Information Architecture (IA)
• User Experience (UX)

Note that UX is an umbrella term under which many different design and usability disciplines collaborate to create products, systems and services. But this does not address how to design the behavior of complex interactive systems. With UX, we wonder whether it is actually possible to design an experience. Designers hope to manage and influence the experiences people have, but this is done by carefully manipulating the variables at hand.

We attempt to influence people’s experiences by designing mechanisms for interacting with a product. We chose Moggridge’s term interaction design, abbreviated IxD, for this design.

The three areas that affect user experience are

• Form – typically done by industrial designers, graphic designers.
• Content – done by information architects, copywriters, animators, sound designers.
• Behavior – by interaction designers.

These are not done in a vacuum, as designers in one area must be concerned as to how their work relates to the others.

Product teams use a division of responsibilities to improve design success and efficiency:

• The design team is responsible for user satisfaction with the product. They decide how the product will look, feel and behave. They must have access to information on potential users and their needs, engineering opportunities and constraints, requirements, and resources.
• The engineering team is responsible for implementation and fabrication of the product. They build to specifications, on budget and schedule. They require clear description of the product’s form and behaviors from the design team.
• The marketing team is responsible for convincing customers to purchase the product. They need authority over all communication with the customer, and input into product definition and design.
• The management team is responsible for the profitability of the resulting product. They require clear information from the groups.

We must help users achieve their goals.  Learning what their goals are, therefore, is very important.

Bad software processes – there are many examples where software forces a process on humans that isn’t their preferred way to do things. To change a file name in MS Word, the user must either exit the document and then rename it using a file browsing application, or they must Save As… and then delete the old document. This is not consistent with the way a normal person thinks.  Incomprehensible jargon such as “stop bits” or “specific IRQ” confuses users and even software developers. Dangerous commands are often presented right up front for a user to mistakenly trigger them.

One of the worst effects of poor planning is where decisions about what a product will do and how it will do it is simply a byproduct of its construction. Developers deep in their thoughts of algorithms and code end up “designing” product behaviors and user interfaces the same way that miners end up “designing” the landscape with their pits and piles of rubble. The interaction design process becomes accidental.

Some feel that integrating customers into the design process can solve human interface design problems. While asking users what they want and how they do their job provides valuable information to design, domain and design knowledge are not the same. Users, while often can articulate the problems with interfaces, are not always capable of visualizing the solutions to those problems.

Larry Keeley’s triad of product development concerns:

• Capability – can we build it?  Product delivery.
• Viability – what will sustain a business? Sustainable business.
• Desirability – what do people need?  Effectiveness and customer adoption.

If any of these three foundations is significantly weak in a product, it is unlikely to stand the test of time.

Examples of companies that have struggled to find the balance:

• Novell – Emphasized technology, with little attention to desirability. Made it vulnerable to competition.
• Apple – Emphasized desirability but made many business errors. Has sustained by loyalty created by attention to user experiences.
• Microsoft – Well run but has been unable to create highly desirable products, creating openings for competition.

Planning interactive design takes significant upfront effort by processional designers. Interaction design is quite new. A systematic approach is possible. This is achieving user goals via appropriately designed behaviors using rules of form and aesthetics. This book presents a set of methods to achieve Goal-Directed Design (Rudolf, 1998).

There are business goals and personal goals. Each worker’s goals vary – for example, a manager’s goals are different from a general worker’s. Products designed and built to achieve business goals alone will eventually fail – personal goals must also be addressed.

Even when businesses become sensitive to user goals, it is often too late to do anything about them. UI design is sometimes addressed after coding begins – sometimes even after it ends. But you cannot easily make a program serve user’s goals once there is significant and inflexible code in place. (Note – This really depends on the design of the back-end software.)

Goals are not the same as tasks or activities. Companies often pay too much attention to user tasks and not enough on their goals in performing those tasks. A goal is an expectation of an end condition. Tasks or activities are individual steps to help someone reach a goal.

Goals change very slowly, if at all, over time. Activities and tasks are current-technology based and may therefore change quite often.  This distinction will assist in differentiating them during analysis.

Easy-to-learn interfaces are not always the best ones. Efficiency may be at odds with ease-of-learning, so an appropriate balance is needed. A kiosk which visitors must use is an example of an interface that should be extremely easy to learn, but with a call-distribution system, where the operators are paid by the number of calls they route, efficiency is much more important, even if the learning curve is steeper.

Good design makes users more effective and happy.

Knowing the users’ goals is very important when determining what tasks to create. An example is a user who must enter names and addresses into a database. A developer may feel that a smoothly functioning data entry application may be what the user needs, but if there are 5000 names to enter, it won’t satisfy the user’s goal as much as an automated system to extract the names from another system. Effective tasks are therefore designed from knowing end goals.

Employing pure researchers to obtain user information often fails. This is because the research is not correctly translated into design solutions.  One way to solve this is for designers to learn to be researchers, too. Designers are often empathic to users, but they can’t know what users are feeling if they are isolated from them.  Additionally, it is often difficult for pure researchers to know what user information is really important from a design perspective. Involving designers directly into research solves both issues.

We need an explicit, systematic process to bridge the gap between research and design for defining user models, establishing design requirements, and translating those into a high-level framework.

Research -> Modeling -> Requirements -> Framework -> Refinement -> Support

• Research – employs ethnographic field study techniques (observations and contextual interviews) to obtain quantitative data about potential and/or actual users of the product. Also includes competitive product audits, market research, reviews of technology white papers and brand strategy, and one-on-one interviews with stakeholders, developers, SMEs, and technology experts.  Their goal is a set of behavior patterns that suggest goals and motivations.
• Modeling – synthesizes the behavior patterns into domain and user models.  Domain models may include information flow and workflow diagrams. User models, or personas, are detailed user archetypes that represent distinct groupings of behaviors, attitudes, aptitudes, goals and motivations observed during the Research phase.
• Requirements Definition – provides connection between user and other models and the framework of the design. Employs scenario-based design methods. A user/persona perspective is taken.  Business goals, brand attributes, and technical constraints are all considered and balanced with persona goals and needs. The output is a requirements definition that balances user, business and technical requirements.
• Framework Definition – where designers create an overall product concept, defining the basic frameworks for the product’s behavior, visual design and – if applicable – physical form. The design team create an interaction framework by also employing two other critical methodological tools in conjunction with context scenarios: interaction design principles (context specific), and interaction design patterns that encode solutions to previously analyzed problems.  After describing the data and needs in high level, they are translated into design elements such as design sketches and behavior descriptions.  The output is an interaction framework definition. This is a stable design concept that provides structure for the detail to come.  Once the product takes physical form, designers can prototype form factors that satisfy the product’s required behavior.  Visual interface designers produce several options.

• Refinement – adds detail and implementation. Task coherence, using key path (walkthrough) and validation scenarios via storyboards. Define system of styles, icons and other visual elements and provide a compelling experience.  The output is the detailed documentation of the design, a form and behavior specification, either on paper or interactive media.
• Development Support – even a very well-conceived and validated design solution can’t anticipate every development challenge or user need. Budgets change, as do schedules. The design may need adjustment and require scaled-down design solutions, and if the interactive design team is not available the developers are forced to do this under time pressure, which can compromise product design integrity.

Goal-Directed Design is a powerful tool for answering the most important questions during definition and design of a digital product:

• 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?
• How should my product behave?
• What form should my product take?
• Who will (should) users interact with my product?
• How can my product’s functions be most effectively organized?
• How will my product introduce itself to first-time users?
• How can my product present technology?
• How can my product deal with problems that users encounter?
• How can my product provide sufficient depth and power for expert users?

Creating software that better matches how people think and work can help them solve their problems.

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

The model of how 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 their mental model. The way the designers choose to represent the working of the program to the user is called the represented model which, unlike the other two models, is an aspect of software over which the designers have great control.  The designer should make the represented model match the users’ mental model as closely as possible. To do so, the designers must understand in detail the way the users think about their work they do with the software.

One of the most significant ways in which computers can assist humans is by putting a simple face on complex processes and situations. As a result, user interfaces that are consistent with user’ mental models are vastly superior to those that are merely reflections of the implementation model. It is therefore a major design principle that user interfaces should be based on user mental models rather than implementation models.  Interaction designers must shield users from implementation models.

Using mechanical-age analogies in design is often incorrect, and often implements their limitations as well. Don’t replicate mechanical-age artifacts in user interfaces without information-age enhancements. 

When designers rely on Mechanical-Age representations to guide them, they are blinded to the far greater potential of the computer to provide sophisticated information management in a better, albeit different, way.

Minor changes from familiar idioms are acceptable for performance and usability gains.  Significant changes, however, must be significantly better.

One of the eternal conundrums of interaction design and interface design is how to address the needs of both beginning users and expert users with a single, coherent interface.  (This assumes that creating separate tools for each is prohibitively expensive and time consuming.)

The experience level of people performing an activity tends, like most population distributions, to follow the classic statistical bell curve.  Most users are intermediates.  Although everybody is a beginner for some minimum time, nobody wants to remain a beginner. They will either advance to intermediate level, or stop using the product and find one in which they can migrate into intermediacy.  There will also be few experts.  Larry Constantine first identified the importance of designing for intermediates and in his book Software for Use, her refers to such users as improving intermediates. We prefer the term perpetual intermediates since they seldom go on to become experts.

Ski slopes use this model. If they want to stay in business, they will cater to the perpetual intermediate skier without scaring off the beginner or insulting the expert. In many cases, a well-balanced user interface takes the same approach. With some specialized products, it is appropriate to optimize the user experience for experts. Development tools often fall into this category, as do scientific instrumentation and medical devices.

Designing for different experience levels is often a dilemma. Programmers qualify as experts in the software they code, and their natural tendency is to design implementation-model software with every possible option. This is expert level.  Sales, marketing and management professionals must demo the product to unfamiliar customers who qualify as beginners, so they have a strong bias towards beginner-level interfaces. 

In reality the largest group of users is intermediate, and for the reasons mentioned above, this group might be ignored. We need to spend more time making our products powerful and easy to use for perpetual intermediate users. We must accommodate beginners and experts, too, but not to the discomfort of the largest segment of users.  Designers should optimize their products for intermediates.