Cooper on Personas

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 Research-based 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.

1
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.
3
4
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.

5
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.

6
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.

7
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.

8
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.
9
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

Hypothetical personas, provisional personas, ad hoc 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.

11
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.

12
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.
13
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
•Learning a useful skill
•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
•Advance my career
•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

15
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.

16
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

17
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

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.

18
Successful products meet user's need first
Again, the user is the most important person, more important than the corporation, IT
manager, parent, grandparent, etc.

Excellent to meet these other goals, but not to the detriment of user's goals.

Basic design principle: Don't make the user feel stupid.

19
Constructing Personas

Constructed using the data obtained from patterns observed during interviews
and observations of users and potential users of a product. May include
ethnographic studies.

Basic principles of the process to construct personas are:

1.Identify behavioral variables
2.Map interview subjects to behavioral variables
3.Identify significant behavior patterns
4.Synthesize the characteristics and relevant goals
5.Check for redundancy and completeness.
6.Expand description of attributes and behaviors.
7.Designate persona types.

20
Step 1: Identify behavioral variables

After completing research and cursory organization of the data, list the
distinct aspects of observed behavior as a set of behavioral variable.
For enterprise applications, behavioral variables are often closely
associated with job roles.  List out the variables for each role separately. 
Typically find 15 to 30 variables per role.

Demographic variables such as age or geographic location may seem to

affect behavior but behavioral variables will be much more important.

Focus on the following types of variables:

•Activities - What the user does; frequency and volume
•Attitudes - How the user thinks about the product domain and
technology
•Aptitudes - What education and training the user has; capability to learn.
•Motivations - Why the user is engaged in the product domain
•Skills - User capabilities related to the product domain and technology

21
Step 2: Map interview subjects to behavioral variables
• Map your interviewees to their place in the variable's range. 
•Some variables will be continuous, computer novice to computer expert while
some will be discrete (uses digital or film camera). 
•The interviewees probably can not be place precisely in the range of a
continuous variable, but that is OK.

Figure 5-4

22
Step 3: Identify significant behavior patterns

Look for clusters that occur across multiple ranges or variables.  A set of
subjects who cluster in six to eight different variables will likely represent a
significant behavior pattern for a persona.  Some specific roles may exhibit
only one significant pattern, but typically there are two or three.

There must a a logical or causative connection between the clustered

behaviors, not just spurious correlation.  For example, if data show that
people who buy a lot of CDs online also download MP3 files, these
behaviors are logically (or causatively) related.  If some of them are also
vegetarians that is probably not a logical consequence of buying CDs on
line.

23
Step 4: Synthesize characteristics and relevant goals
For each significant pattern you identify, you must synthesize details from your
data.  Describe the potential use environment, typical work day,(or other
relevant context), current solutions and frustrations, and relevant relationships
with others.

Brief bullet points, often written on Post-its for use later, are sufficient.  Some
descriptive material is good, but do not overdo it.  Too much is a distraction. 
Give the persona a first and last name.  An evocative but not stereotypical
name is good.  Cooper uses a baby book as a reference tool.  Also some
demographic information can be added such as age, geographic location,
relative income and job title.  This is primarily to help you visualize the person
better.  Refer to the person by name from now on.

Synthesizing goals
•Usually you want end goals, these are fairly immediate goals such as getting
home on time or keeping in touch with relatives.
•Must be goals related to the product.
•Life goals are most useful for consumer products.
•General experience goals are implicit goals ("don't feel stupid", "don't waste
time".) 24
Step 5: Check for completeness and redundancy
Be sure each persona is unique, not too close to some other persona.  If so,
tweak each persona to make them different or drop one of the personas.

Step 6: Expand description of attributes

•Third person narrative
•Majority of research findings incorporated into the persona description
•One or two pages.
•Not a short story.
•Idea of the persona's days at work
•Some fictional stuff to flesh it out.  Not more detail than you actually know.
•Emphasize the product (interests, peeves, concerns)
•Express what the persona is looking for in the product
•Augment with carefully chosen photographs
•Don't get too detailed.  Personas are design aids.

25
Persona types

Primary persona – Usually one primary persona.

Must satisfy this user and not dissatisfy other personas.

Secondary persona – Not always necessary

May be mostly satisfied with primary persona’s interface but has specific
needs that will not interfere with the primary persona's use of the
interface. Design first for primary persona, then for secondary.

Customer persona – model the customer not the end user. Typically like
a secondary persona. May be a primary persona if the customer has their
own administrative interface.

Served persona – Someone who does not directly use the interface but is
served by it. A patient being treated by a radiation therapy machine is not
a user, but is served and affected by the interface.

Negative persona – Someone the product is not being built for. E.g.
Technically savvy early adopters.
27
Other models

Holtzblatt and Beyers, Contextual Design

Workflow models - How does the user use the system?

Artifact models – Models based on online forms, company

forms, etc.

Physical models – Models of the physical layout of the user’s

workspace.