Offer more products or services
You may find yourself designing on behalf of an organization that is not necessarily a business, such as a museum, nonprofit, or school (though all organizations are increasingly run as businesses these days). These organizations also have goals that must be considered, such as:
Educate the public
Raise enough money to cover overhead
09_084113 ch05.qxp 4/3/07 6:02 PM Page 96
96
Part I: Understanding Goal-Directed Design
Technical goals
Most of the software-based products we use everyday are created with technical goals in mind. Many of these goals ease the task of software creation, which is a programmer’s goal. This is why they typically take precedence at the expense of the users’ goals. Technical goals include:
Run in a variety of browsers
Safeguard data integrity
Increase program execution efficiency
Use a particular development language or library
Maintain consistency across platforms
Technical goals in particular are very important to the development staff. It is important to stress early in the education process that these goals must ultimately serve user and business goals. Technical goals are not terribly meaningful to the success of a product unless they are derived from the need to meet other more human-oriented goals. It might be a software company’s task to use new technology, but it is rarely a user’s goal for them to do so. In most cases, users don’t care if their job is accomplished with hierarchical databases, relational databases, object-oriented databases, flat-file systems, or black magic. What we care about is getting our job done swiftly, effectively, and with a modicum of ease and dignity.
Successful products meet user goals first
“Good design” has meaning only for a person using a product for some purpose.
You cannot have purposes without people. The two are inseparable. This is why personas are such an important tool in the process of designing behavior; they represent specific people with specific purposes or goals.
The most important purposes or goals to consider when designing a product are those of the individuals who actually use it, not necessarily those of its purchaser. A real person, not a corporation or even an IT manager, interacts with your product, so you must regard her personal goals as more significant than those of the corporation who employs her or the IT manager who supports her. Your users will do their best to achieve their employer’s business goals, while at the same time looking after their own personal goals. A user’s most important goal is always to retain her human dignity: not to feel stupid.
We can reliably say that we make the user feel stupid if we let her make big mistakes, keep her from getting an adequate amount of work done, or bore her.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 97
Chapter 5: Modeling Users: Personas and Goals
97
DESIGN
Don’t make the user feel stupid.
principle
This is probably the most important interaction design guideline. In the course of this book, we examine numerous ways in which existing software makes the user feel stupid, and we explore ways to avoid that trap.
The essence of good interaction design is devising interactions that achieve the goals of the manufacturer or service provider and their partners without violating the goals of users.
Constructing Personas
As previously discussed, personas are derived from patterns observed during interviews with and observations of users and potential users (and sometimes customers) of a product. Gaps in this data are filled by supplemental research and data provided by SMEs, stakeholders, and available literature. Our goal in constructing a set of personas is to represent the diversity of observed motivations, behaviors, attitudes, aptitudes, mental models, work or activity flows, environments, and frustrations with current products or systems.
Creating believable and useful personas requires an equal measure of detailed analysis and creative synthesis. A standardized process aids both of these activities significantly. The process described in this section, developed by Robert Reimann, Kim Goodwin, and Lane Halley at Cooper, is the result of an evolution in practice over the span of hundreds of interaction design projects, and has been documented in several papers.11 There are a number of effective methods for identifying behavior patterns in research and turning these into useful user archetypes, but we’ve found the transparency and rigor of this process to be an ideal way for designers new to personas to learn how to properly construct personas, and for experienced designers to stay focused on actual behavior patterns, especially in consumer domains. The principle steps are:
1. Identify behavioral variables.
2. Map interview subjects to behavioral variables.
3. Identify significant behavior patterns.
4. Synthesize characteristics and relevant goals.
5. Check for redundancy and completeness.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 98
98
Part I: Understanding Goal-Directed Design
6. Expand description of attributes and behaviors.
7. Designate persona types.
We discuss each of these steps in detail in the following sections.
Step 1: Identify behavioral variables
After you have completed your research and performed a cursory organization of the data, list the distinct aspects of observed behavior as a set of behavioral variables. Demographic variables such as age or geographic location may also seem to affect behavior, but be wary of focusing on demographics because behavioral variables will be far more useful in developing effective user archetypes.
Generally, we see the most important distinction between behavior patterns emerge by focusing 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 For enterprise applications, behavioral variables are often closely associated with job roles, and we suggest listing out the variables for each role separately. Although the number of variables will differ from project to project, it is typical to find 15 to 30 variables per role.
These variables may be very similar to those you identified as part of your persona hypothesis. Compare behaviors identified in the data to the assumptions made in the persona hypothesis. Were the possible roles that you identified truly distinct?
Were the behavioral variables (see Chapter 4) you identified valid? Were there additional, unanticipated ones, or ones you anticipated that weren’t supported by data?
List the complete set of behavioral variables observed. If your data is at variance with your assumptions, you need to add, subtract, or modify the roles and behaviors you anticipated. If the variance is significant enough, you may consider additional interviews to cover any gaps in the new behavioral ranges that you’ve discovered.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 99
Chapter 5: Modeling Users: Personas and Goals
99
Step 2: Map interview subjects to
behavioral variables
After you are satisfied that you have identified the set of significant behavioral variables exhibited by your interview subjects, the next step is to map each interviewee against each variable. Some of these variables will represent a continuous range of behavior (for instance, from a computer novice to a computer expert), and a few will represent multiple discrete choices (for example, uses a digital camera versus uses a film camera).
Mapping the interviewee to a precise point in the range isn’t as critical as identifying the placement of interviewees in relatio
nship to each other. In other words, it doesn’t matter if an interviewee falls at precisely 45% or 50% on the scale. There’s often no good way to measure this precisely; you must rely on your gut feeling based on your observations of the subject. The desired outcome of this step is to accurately represent the way multiple subjects cluster with respect to each significant variable (see Figure 5-4).
Service-oriented
Price-oriented
User 3
User 2
User 1, 4, 5
Necessity only
Entertainment
User 1, 4
User 2
User 5
User 3
Figure 5-4 Mapping interview subjects to behavioral variables. This example is from an online store. Interview subjects are mapped across each behavioral axis.
Precision of the absolute position of an individual subject on an axis is less important than its relative position to other subjects. Clusters of subjects across multiple axes indicate significant behavior patterns.
Step 3: Identify significant behavior patterns
After you have mapped your interview subjects, look for clusters of subjects 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 that will form the basis of a persona. Some specialized roles may exhibit only one significant pattern, but typically you will find two or even three such patterns.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 100
100
Part I: Understanding Goal-Directed Design
For a pattern to be valid there must be a logical or causative connection between the clustered behaviors, not just a spurious correlation. For example, there is clearly a logical connection if data shows that people who regularly purchase CDs also like to download MP3 files, but there is probably no logical connection if the data shows that interviewees who frequently purchase CDs online are also vegetarians.
Step 4: Synthesize characteristics and relevant goals
For each significant behavior pattern you identify, you must synthesize details from your data. Describe the potential use environment, typical workday (or other relevant context), current solutions and frustrations, and relevant relationships with others.
At this point, brief bullet points describing characteristics of the behavior are sufficient. Stick to observed behaviors as much as possible. A description or two that sharpens the personalities of your personas can help bring them to life. However, too much fictional, idiosyncratic biography is a distraction and makes your personas less credible. Remember that you are creating a design tool, not a character sketch for a novel. Only concrete data can support the design and business decisions your team will ultimately make.
One fictional detail at this stage is important: the personas’ first and last names. The name should be evocative of the type of person the persona is, without tending toward caricature or stereotype. We use a baby name book as a reference tool in creating persona names. You can also, at this time, add in some demographic information such as age, geographic location, relative income (if appropriate), and job title. This information is primarily to help you visualize the persona better as you assemble the behavioral details. From this point on, you should refer to the persona by his or her name.
Synthesizing goals
Goals are the most critical detail to synthesize from your interviews and observations of behaviors. Goals are best derived from an analysis of the behavior patterns comprising each persona. By identifying the logical connections between each persona’s behaviors, you can begin to infer the goals that lead to those behaviors. You can infer goals both by observing actions (what interview subjects in each persona cluster are trying to accomplish and why) and by analyzing subject responses to goal-oriented interview questions (see Chapter 4).
To be effective as design tools, goals must always directly relate, in some way, to the product being designed. Typically, the majority of useful goals for a persona are end goals. You can expect most personas to have three to five end goals associated with
09_084113 ch05.qxp 4/3/07 6:02 PM Page 101
Chapter 5: Modeling Users: Personas and Goals
101
them. Life goals are most useful for personas of consumer-oriented products, but they can also make sense for enterprise personas in transient job roles. Zero or one life goal is appropriate for most personas. General experience goals such as “don’t feel stupid” and “don’t waste time” can be taken as implicit for almost any persona.
Occasionally, a specific domain may dictate the need for more specific experience goals; zero to two experience goals is appropriate for most personas.
Persona relationships
It sometimes makes sense for the set of personas for a product to be part of the same family or corporation and to have interpersonal or social relationships with each other. The typical case, however, is for individual personas to be completely unrelated to each other and often from completely different geographic locations and social groups.
When considering whether it makes sense for personas to have business or social relationships, think about:
1. Whether you observed any behavioral variations in your interview subjects related to variations in company size, industry, or family/social dynamic. (In this case, you’ll want to make sure that your persona set represents this diversity by being situated in at least a couple of different businesses or social settings.) 2. If it is critical to illustrate workflow or social interactions between coworkers or members of a family or social group.
If you create personas that work for the same company or have social relationships with each other, you might run into difficulties if you need to express a significant goal that doesn’t belong with the preestablished relationship. While a single social relationship between your set of personas is easier to define than several different, unrelated social relationships between individual personas and minor players outside the persona set, it can be much better to put the initial effort into development of diverse personas than to risk the temptation of bending more diverse scenarios to fit a single social dynamic.
Step 5: Check for completeness and redundancy
At this point, your personas should be starting to come to life. You should check your mappings and personas’ characteristics and goals to see if there are any important gaps that need filling. This again may point to the need to perform additional research directed at finding particular behaviors missing from your behavioral axes. You might also want to check your notes to see if there are any political personas that you need to add to satisfy stakeholder assumptions or requests.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 102
102
Part I: Understanding Goal-Directed Design
If you find that two personas seem to vary only by demographics, you may choose to eliminate one of the redundant personas or tweak the characteristics of your personas to make them more distinct. Each persona must vary from all others in at least one significant behavior. If you’ve done a good job of mapping, this shouldn’t be an issue.
By making sure that your persona set is complete and that each persona is meaningfully distinct, you ensure that your personas sufficiently represent the diversity of behaviors and needs in the real world, and that you have as compact a design target as possible, which reduces work when you begin designing interactions.
Step 6: Expand description of attributes
and behaviors
Your list of bullet point characteristics and goals arrived at in Step 4 points to the essence of complex behaviors, but leaves much implied. Third-person narrative is far more powerful at conveying the persona’s attitudes, needs, and problems to other team members. It also deepens the designer/authors’ connection to the personas and their motivations.
A typical persona description should be a synthesis of the most important details observed during research, relevant to this person
a. This becomes a very effective communication tool. Ideally, the majority of your user research findings should be contained in your persona description. This will be the manner in which your research directly informs design activities (as you will see in the upcoming chapters).
This narrative should be no longer than one or two pages of prose. The persona narrative does not need to contain every observed detail because, ideally, the designers also performed the research, and most people outside the design team do not require more detail than this.
The narrative must, by nature, contain some fictional situations, but as previously discussed, it is not a short story. The best narrative quickly introduces the persona in terms of his job or lifestyle, and briefly sketches a day in his life, including peeves, concerns, and interests that have direct bearing on the product. Details should be an expansion of your list of characteristics, with additional data derived from your observations and interviews. The narrative should express what the persona is looking for in the product by way of a conclusion.
Be careful about the precision of detail in your descriptions. The detail should not exceed the depth of your research. In scientific disciplines, if you record a measurement of 35.421 meters, this implies that your measurements are accurate to .001 meters. A detailed persona description implies a similar level of observation in your research.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 103
Chapter 5: Modeling Users: Personas and Goals
103
When you start developing your narrative, choose photographs of your personas.
Photographs make them feel more real as you create the narrative and engage others on the team when you are finished. You should take great care in choosing a photograph. The best photos capture demographic information, hint at the environment (a persona for a nurse should be wearing a nurse’s uniform and be in a clinical setting, perhaps with a patient), and capture the persona’s general attitude (a photo for a clerk overwhelmed by paperwork might look harried). The authors keep several searchable databanks of stock photography available for finding the right persona pictures.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 17
