About Face 3: The Essentials of Interaction Design, Alan Cooper,

Robert Reimann and David Cronin.  Wiley Publishing Inc.  2007.

"Computer literacy, however, is nothing more than
a euphemism for forcing human beings to stretch
their thinking to understand an alien, machine
logic rather than having software enabled
products stretch to meet people's way of thinking."

1
Models (Chapter 2)

Implementation Model
1. Representation of the way a machine actually works. 
2. Describes the details of the way a program is implemented in code. 
3. Example, a motion picture projector uses a complicated sequence of
intricate moving parts to create an illusion.  It shines a very bight light
through a translucent, miniature image for a fraction of a second.  It then
blocks the light for a split second while it moves another miniature image
into place.  It unblocks the light for a moment.  It does this 24 times a
second.
4. Example: Automobile engine has both mechanical and theoretical
complexity.

2
User Mental Models (aka Conceptual Model)
• Movie goer sees the projector as something that throws the picture up on
the screen, not thinking about 24 frames/second or the sprockets and gears
that make it all happen.
• Better example:  Driving a car.  The gas pedal makes it go and the brake
makes it stop.  There is no reason to understand the inner workings of the
engine or the theory (Carnot cycle).
• The complex underlying workings of even a word processor are, and should
be, invisible to the user.  The user thinks in terms of a document that can
easily be cut, pasted, formatted, etc.
• Mental models are usually simpler than reality.
• Users will make a mental model of the software they use.

Most Software Conforms [too closely] to Implementation Models

• The user is constrained to use the systems file system, document naming
conventions, etc.
• The interface is an abstraction of the programmers model, not an
abstraction of the user's goals in using the product.

3
Represented Models
•The behavioral face the software shows the world. 
•A clever designer can hide the inner workings of the software and present a
neat, fairly simple and consistent model.
•The represented model should be close to the user's mental model. Or, stated
in a better way, the represented model should encourage a good, consistent
mental model.
•A represented model that follows the implementation model too closely
significantly reduces the user's ability to learn and use the program.  (e.g.
Writing programs in assembly or machine language after writing in Java.)
•Adobe Photoshop feature, Variations., displays a picture being worked on in
several ways, each with a different color balance.  The user can pick the
preferred one.  No dealing with numerical values, scroll bars, etc.

4
User interfaces designed by engineers often follow the implementation model
Example, a home theater system (or even a less formal grouping of various video
components).  The user must keep track of video sources, even changing remote
controls to deal with some goals. 

I have a DVD player, a VCR (nearly never used but occasionally useful), a DVR
(TimeWarner) and auxiliary speakers.  Usually I can just use the DVR remote (after
having set it up correctly).  Occasionally I must use the remote for a specific component.

Dragging a file from one directory to another within the same drive ostensibly moves the
file, erasing the source file and putting the file in the target directory.  Moving a file from
one disk to another copies the file, leaving the source intact.  Same user action, different
computer action.

5
Boolean logic vs English
Boss says: Give me the names of all employees who work in Maine and
Vermont.  (Really means, "Give me the names of all employees who live in
Maine and the names of all employees that live in Vermont.)

Query:  SELECT names FROM employees WHERE  state = "Maine" OR state

= "Vermont“

Boss, speaking in query form: Give me the names of all employees who live in
Maine or Vermont.

Query, in original boss form: SELECT names FROM employees WHERE 

state = "Maine" AND state = "Vermont"     // Would probably get no results.

6
User Categories: beginners, experts and intermediates
(Chapter 3)

Perpetual  Intermediates
•The bulk of users are intermediates. 
•Bulk of users remain intermediates
•A few have come up from beginners and are heading towards experts. 
•Others are ex-experts who have used the product extensively for a while but
use it rarely now.

Example: Ski slopes -  Must have runs that cater to each of the 3 levels.

7
Designing for different experience levels.
Marketers and sales people often see only beginners. 
The person buying the product is not the real user. 
Programmers naturally program for experts and, often, make a hash
of designing for beginners.

The product must be designed for all levels, but beginners and
experts are the two most designed for groups even though there may
be far more intermediates than beginners and experts combined.

Optimize the product for intermediates.

[Note: Marketers trying to lure beginners come up with poor wizards

or artifacts like Clippy.  These can be annoying for everyone.  Even
beginners tire of them quickly.]

8
What beginners need
• Beginners do not want to stay beginners. 
• Good software shortens the beginner phase and leads directly to some
intermediate stage. 
• Imagine a beginner as intelligent but busy.  They need to learn this
software in addition to the rest of the work they do. 
• Give the beginner an implementation model of the system that
encourages the user to make an accurate mental model. 
• Consistency is key to this.

Beginners need to know the scope and purpose of the software.  [Welty: 
I have always thought that the Help/About menu items should have an
overview of what the software does and who it is aimed at.   Help does
have links to tutorials, etc., but I never see an overview of the software.]

Any aspects of the program built for beginners must not be required of
them or others after the beginner stage.  Intermediate and advanced
users do not want to deal with the "training wheels" implemented for
beginners.

Beginners need well thought out menus, shortcut keys readily visible and
understandable dialog boxes (with good choices for Cancel and other
buttons). 9
What experts need
•Shortcuts
•Not to have the software stand between them and what they want to do.
•If experts recommend the purchase of software, get some input from
intermediates and beginners to see if it meets their need, too. 
•Experts are outliers. They must be designed for but not to the exclusion of
others.

What perpetual intermediates need

•Access to tools. 
•Do not need scope and purpose.  That should have come out in their
beginner phase.
•ToolTips are excellent for intermediates.  They are easy to access, brief
and to the point.
•They want easy access to all the tools they use regularly which is usually
a fairly small subset of all possible tools.

Summary:  All users are equal but perpetual intermediate users are more
equal than others.
10
Understanding Users: Qualitative Research (Chapter 4)

Qualitative vs quantitative research

Quantitative:  Tightly controlled, statistically significant results.
Miss nuances due to the tight control and equal treatment of all the
participants (often called subjects in quantitative studies).

Value of qualitative research

Helps us understand:
•Behaviors, attitudes and aptitudes of potential product users.
•Technical, business and environmental contexts (the domain) of the
product.
•Vocabulary and social aspects of the domain in question
•How existing products are used

11
Also help in the progress of the project by:
•Providing credibility and authority to the team because design decisions
can be traced to research results
•What goals motivate people to use the product and what basic tasks help
people accomplish those goals?
•What problems do people encounter with their present way of doing
things?

Qualitative methods are faster, cheaper and more likely to

provide useful answers to important questions that lead to
superior design:
•How does the product fit into the broader context of people's lives?
•What goals motivate people to use the product and what basic
functionality will help people to accomplish these goals?
•Often qualitative studies find behaviors, goals, etc. that would never be
found in quantitative studies

With quantitative methods you often find what but not why.
12
Cooper example: 
Company wanted to sell entry-level consumer video-editing
software. 

•Traditional market research techniques to identify a significant

market of people who owned both a computer and a digital video
camera. 
•Interviews were conducted with a dozen users in the target
population. 
•Parents were the most likely customers for such a product. 
• Only 1 in 12 people had successfully connected their computer
and camera and that was done by an IT guy.  At the time it was
difficult to get FireWire or video capture card working. 
•Product put on hold. 
•Probably saved the company significant money.

13
The persona hypothesis: We can consolidate user
behaviors and goals into a few identifiable groups and give a
single person’s name to this group. Designing for these
composite individuals works very well in practice.

Based on likely consumer behavior patterns and the factors that

differentiate these patterns, not demographic characteristics.

Personas have come up in passing in the course but never a

focus.  We will use Cooper to focus in on personas.  Cooper
invented personas.

Persona hypothesis attempts to address, at a high level, these

three questions:
•What different sorts of people might use this product?
•How their needs and behaviors vary?
•What ranges of behaviors and environments need to be
explored?

14
Behavioral and demographics variables. 
Example, for an online store, there are several ranges of behavior
concerning shopping that we might identify:
•Frequency of shopping (from frequent to infrequent)
•Desire to shop (from loves to shop to hates to shop)
•Motivation to shop (from bargain hunting to searching for just the
right item)

It is difficult to anticipate what users to interview based on these

behavioral variables. 
Market research can identify demographic variables that may map
to behavioral variables. 
E.g., Frequent shopper who loves to shop and usually searching
for the right item.  In Maine, perhaps Falmouth or Cape Elizabeth. 
These are stereotypes but we are looking for stereotypes.

15
Now must interview possible candidates for forming the
personas.  Cooper's experience:  Each behavioral variable
requires about five interviews.

The interviews are ethnographic interviews which have been

touched on before.  The basics of these interviews are:
•Interview where the interaction happens
•Avoid a fixed set of questions
•Focus on goals first, tasks second
•Avoid making the user the designer
•Encourage storytelling
•Ask for a show and tell
•Avoid leading questions

16
Goal-oriented questions
• Goals - What makes a good day?
•Opportunity - What activities currently waste your time?
•Priorities - What is most important to you?
•Information - What helps you make decisions?

System-oriented questions:
•Function - What are the most common things you do with the
product?
•Frequency - What parts of the product do you use the most?
•Preference - What are your favorite aspects of the product?  What
drives you crazy?
•Failure - How do you work around problems
•Expertise - What shortcuts do you employ?

Avoid leading questions

Examples:
•Would feature X help you?
•You like X don't you?
•Do you think you would use X if it were available?
17
Other Types of User Research

Focus groups

•Participants chosen on demographics

•Usually use a structured set of questions
•Get initial reactions to a possible product
•Get reactions to a product currently being used
•NOT good as a design tool
•CAN'T find out how people really use the product
•NOT individual, loudest person dominates.
•NOT good at seeing different patterns of use

Usability and User Testing - at this point Cooper goes into a review of user testing.  We will not
cover it.  He cites our text, Usability Engineering by Jakob Nielsen as "the classic volume on
usability and provides excellent guidance on the subject."

18
Modeling Users: Personas and Goals (Chapter 5)
After finding out a lot about potential users' lives, motivations and environs, how is this
information used? 

Personas are User Models

•You should have notebooks full of conversations, perhaps recordings. 
•Take this data to generate models of different types of user. 
•The personas are based on the notes taken from real people and made in to composite
archetypes. 
•Personas are a simple but powerful tool. 
•It takes experience and thought to come up with meaningful personas. 
•One must identify the significant and meaningful patters in user behavior and turn these
into archetypes that represent a broad cross-section of users.

Personas
To create a product that must satisfy a diverse audience, logic might tell you to make it
as broad in its functionality as possible to accommodate the most people.   This logic
,however, is flawed.  The best way to accommodate a variety of users is to design for
specific individuals with specific needs.

When you broadly and arbitrarily extend a product's functionality to include many
constituencies, you increase the cognitive load and navigational overhead for all users. 
Facilities that please some users will likely displease others. 19
20
21
Key to this approach is first to choose the right individuals to design  for - those
whose needs represent those of a larger set of key constituents - and then
prioritize those individuals so that the needs of the most important users are
met without compromising our ability to meet the needs of secondary users.

22
Strengths of personas as a design tool

Personas help designers:

• Determine what a product should do and how it should behave.  Persona

goals and tasks provide the foundation for the design effort.
• Communicate with stakeholders, developers and other designers. 
Personas provide a common language for discussing design decisions and
help keep the design centered on users at every step in the process.
• Build consensus and commitment to the design.  With a common language
comes a common understanding.  Personas reduce the need for elaborate
diagrammatic models; it is easier to understand the many nuances of user
behavior through narrative structures that personas employ.  Put simply,
because personas resemble real people, they are easier to relate to than
feature lists and flowcharts.

23
Strengths of personas as a design tool (cont’d)

•Measure the designs effectiveness.  Design choices can be tested on a

persona in the same way that they can be shown to a real user during the
formative process.  Although this does not replace the need to test real users,
it provides a powerful reality check tool for designers trying to solve design
problems.  This allows iteration to occur rapidly and inexpensively at the
white board and it results in far stronger design baseline when time comes to
test with actual people.
•Contribute to other product-related efforts such as marketing and sales
plans.  The authors have seen their clients repurpose personas across the
organization, informing marketing campaigns, organizational structure and
other strategic planning activities.  Business units outside the product
development desire the sophisticated knowledge of product's users and
typically view personas with great interest.

24
Personas can also resolve three design issues that arise during
product development

•The elastic user

•Self referential design
•Edge cases

The elastic user

The design team can, without and even with personas, view the user
population as having elastic needs and abilities. Personas help focus
the group on the users previously determined as personas.

It is easy to say, “Maybe someone would like to be able to ????.” This

is more difficult to say if you relate the action to well drawn personas.

Self-referential design
Developers designing for themselves.  Usually there are no personas
that embody the background of developers.

25
Edge cases
Designing for situations that may possibly happen but are extremely rare.  The
design personas will not run into these situations very often.  Edge cases can
be designed for but should not be the design focus.  “Will Julie want to perform
this operation often?  Ever?”

Personas are based on research

Chapter 4 outlines this research. 

Other data that can also support and supplement the creation of personas
include (in rough order of effectiveness):
•Interviews with users outside their use contexts
•Information about users supplied by stakeholders and subject matter experts
(SMEs)
•Market research data such as focus groups and surveys
•Market-segmentation models
•Data gathers from literature reviews and previous studies

The most important data comes form direct interviews and observation of real
users.
26
Highlights of persona attributes
•Personas are represented as real people
•They are personifications
•Engage empathy of designers and developers
•Akin to Method Acting where actors "become" the character (sometimes this is
referred to as the Stanislavsky method of interaction design).
•Represent a class of users (composite archetypes)
•These are not stereotypes.  Stereotypes are simplistic models based on poor
research and bias.
•Express definitive behavior within a identified range
•Must have motivation (goals)
•May need Customer Personas if product's buyer is different than the user

Provisional personas
These are not based on detailed research but on available data and best
guesses about behaviors, motivations and goals.  Based on stakeholder and
subject matter experts.  Don Norman calls them "ad hoc" personas.

They seem to yield better results than having no personas at all.

27
Goals

•Goals drive behavior.

•Goals serve as a lens through which a designer sees the product.
•Goals are achieved through tasks.
•Tasks are a means to an end; goals are that end.
•Often users can't specify their own goals.
•Goals are garnered from users environment and behavior
•Each goal should be expressed as a simple sentence.

User goals and cognitive processing

Don Norman's three levels of cognitive processing (from his book Emotional
Design)
•Visceral - Immediate level.  Help make rapid decisions.  Fight or flight. 
Malcolm Gladwell's Blink.
•Behavioral - Middle level.  Simple every day behaviors.  This is the level that
usability addresses.
•Reflective - Least immediate level.  Involves conscious consideration and
reflection on past experience.

28
Designing for Visceral Responses
•Want immediate appeal. 
•The immediately perceived beauty, functionality, etc. of the product are very
important. 
•May make a difference in original purchase and, even long-term satisfaction. 

Often if people put work into a product, they do not want to think of their
investment as being wasted.  [This sometimes is true of people and their cars. 
If you paid a lot for a car, you might think it a good car even if experience has
shown it is not.  People hate to be wrong or to feel foolish.]

Designing for behavior

•Most products designed for this level.
•Match users behaviors, assumptions and mental models.
•Influenced by both of the other levels of processing.
•Design should harmonize with elements of visceral and reflective design.

Designing for reflection

•Need a balance of style and elegance with function.  Apple's iPod.
•Difficult to design for long-term use, but necessary for success.
29
Three type of user goals
These were formulated by Cooper to correspond to Norman's cognitive
levels
•Experience goals
•End goals
•Life goals

Experience goals
Simple, universal and personal
How someone wants to feel about the product when using it.
Persona motivations at the visceral level:
•Feel smart or in control
•Have fun
•Feel cool or hip.
•Remain focused and alert
End goals
End goals represent the user's motivation for performing the tasks associated
with a specific product.
Examples:
•Be aware of problems before they become critical
•Stay connected with friends and family
•Clear my to-do list by 5:00 pm every day.
•Find music that I'll love.
•Get the best deal.

Life goals
Typically go beyond the product being designed.  Why is the user trying to
accomplish the end goals?  What are the user's long-term desires,
motivations and self-image attributes? For example:
•Live the good life
•Succeed in my ambitions to ...
•Be a connoisseur of ...
•Be attractive, popular or respected by my peers

31
User goals are user motivation
Relationship between Cooper's person goals and Norman's model:

•Experience goals are related to visceral goals: how a user wants to feel
•End goals relate to behavior goals: what a user wants to do.
•Life goals relate to reflection: who a user wants to be.

32
Other, subsidiary but still important stakeholder goals

Customer goals -  People who buy the product are not necessarily the users.
•For consumer products the customer could be a friend or family member. 
Concerned about safety and enjoyment of the product.
•Business customers may be IT managers.  Concerns about security, ease of
maintenance and ease of customization.

Business and organizational goals    

Business goals differ between businesses but, generally they include the
following:
• Increase profit.
• Increase market share
• Retain customers
• Defeat the competition
• Use resources more efficiently
• Offer more products or services

33
Non-profit goals
• Educate the public
• Raise enough money to cover overhead

Technical goals (of the developer)

• Run in a variety of browsers
• Safeguard data integrity
• Increase program execution efficiency
• Use a particular development language or library
• User's do not usually care about tees except as they aid in the user's
satisfaction.

Other developer goals are same as business goals.

Specific developers are interested in how much work is involved for the
pay, overtime needed, ease of coding, etc.

34