Cooper on Personas Modeling Users Personas and Goals

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 i. Pod. • 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 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 coverhead 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 MP 3 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.