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. In constructing a set of personas, we are looking to segment use across a set of observed behavioral variables (also called axes or ranges). Well-developed personas incorporate information about goals, attitudes, work or activity flow, environment, skills and skill levels, and frustrations.

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, is the result of an evolution in practice over the span of dozens of interaction design projects.

  1. Revisit the persona hypothesis.

  2. Map interview subjects to behavioral variables.

  3. Identify significant behavior patterns.

  4. Synthesize characteristics and relevant goals.

  5. Check for completeness.

  6. Develop narratives.

  7. Designate persona types.

We will discuss each of these steps in detail in the following sections.

Revisit the persona hypothesis

After you have completed your research and performed a cursory organization of the data, you next compare patterns 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. Demographic variables such as age or technical skill may also seem to affect behavior, but be wary of focusing on demographics during persona creation because behavioral variables have far more impact on the design. For enterprise applications, behavioral (and demographic) variables are often closely associated with job roles. Although the number of variables will differ from project to project, it is typical to find 15 to 30 variables per role.

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.

Map interview subjects to behavioral variables

After you are satisfied that you have identified the entire set of behavioral variables exhibited by your interview subjects, the next step is to map each interviewee against each variable range that applies. The precision of this mapping isn't as critical as identifying the placement of interviewees in relationship 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 feel based on your observations of the subject). It is the way multiple subjects cluster on each variable axis that is significant (see Figure 5-4).

click to expand
Figure 5-4: Mapping interview subjects to behavioral variables. This example is from e-commerce. 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.

Identify significant behavior patterns

After you have mapped your interview subjects, you see clusters of particular 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 (Goodwin, 2002). Some specialized roles may exhibit only one significant pattern, but typically you will find two or even three such patterns.

For a pattern to be valid, there must be a logical or causative connection between the clustered behaviors (Goodwin, 2002), 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 also seem to enjoy stamp collecting.

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 time period), current solutions and frustrations, and relevant relationships with others (Goodwin, 2002a).

Brief bullet points describing characteristics of the behavior are sufficient. Stick to observed behaviors as much as possible; a description or two that sharpen the personalities of your personas can help bring them to life. Too much fictional, idiosyncratic biography, however, is a distraction and makes your personas less credible (Goodwin, 2002a). 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. The authors 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.

PERSONA INTERRELATIONSHIPS

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.

It makes sense for personas to have social relationships between each other only if:

  1. You did not observe any behavioral variations in your interview subjects related to variations in company size, industry, or family/social dynamic.

  2. Doing so is critical to illustrate workflow or social interactions between co-workers 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 pre-established 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's much better to put the initial effort into development of diverse personas than it is to risk the temptation of bending more diverse scenarios to fit a single social dynamic.

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 group of behaviors 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 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.

Check for completeness and distinctiveness

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.

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 both distinct and complete, you will be able to maintain a manageable set of personas.

Develop narratives

Your list of bullet point characteristics and goals point to the essence of complex behaviors, but leaves much implied. Third-person narrative is far more powerful in 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 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 events and reactions, but as previously discussed, it is not a short story. The best narrative quickly introduces the persona in terms of his job or lifestyle (enterprise versus consumer), 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 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 m, this implies that your measurements are accurate to .001 m. Likewise a detailed persona description implies a similar level of observation in your research (Goodwin, 2002a).

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.

Designate persona types

By now your personas should feel very much like a set of real people that you feel you know. The final step in persona construction finishes the process of turning your qualitative research into a powerful set of design tools.

All design requires a design target—the audience upon whom the design is focused. The personas, which we have created, represent the possible candidates for that design target. A single interface can only be designed for a single persona.

AXIOM 

Design each interface for a single, primary persona.

What we then must do is prioritize our personas to determine which should be the primary design target. The goal is to find a single persona from the set whose needs and goals can be completely and happily satisfied by a single interface without disenfranchising any of the other personas. We accomplish this through a process of designating persona types. There are six types of persona, and they are typically designated in roughly the order listed here:

  • Primary

  • Secondary

  • Supplemental

  • Customer

  • Served

  • Negative

We discuss each of these persona types and their significance from a design perspective in the following sections.

PRIMARY PERSONAS

Primary personas represent the primary target for the design of an interface. There can be only one primary persona per interface for a product, but it is possible for some products (especially enterprise products) to have multiple distinct interfaces, each targeted at a distinct primary persona (for example, a healthcare information system might have separate clinical and financial interfaces, each targeted at a different persona).

A primary persona is not satisfied by a design targeted at any other persona in the set. However, if the primary persona is the target, all other personas are at least minimally satisfied (and thus not unhappy).

Choosing the primary persona is a process of elimination: Each persona must be tested by comparing the goals of that persona against goals of the others. If no clear primary persona is evident, it could mean one of two things: Either the product needs multiple interfaces, each with a suitable primary (often the case for enterprise and technical products), or the product is trying to accomplish too much. If your consumer product has multiple primary personas, the scope of the product may be too broad.

SECONDARY PERSONAS

Sometimes a situation arises in which a persona would be entirely satisfied by a primary persona's interface if one or two specific additional needs (not required by the primary) were addressed by the interface. This indicates that the persona in question is a secondary persona for that interface, and the design of that interface must address those needs without getting in the way of the primary persona. Typically, an interface will have zero to two secondary personas. More than that again indicates scope problems with the product.

SUPPLEMENTAL PERSONAS

User personas that are not primary or secondary are supplemental personas: They are completely satisfied by one of the primary interfaces. There can be any number of supplemental personas associated with an interface. Often political personas—the ones added to the cast to address stakeholder assumptions—become supplemental personas.

CUSTOMER PERSONAS

Customer personas address the needs of customers, not end users, as discussed earlier in this chapter. Typically, customer personas are treated like secondary personas. However, in some enterprise environments, some customer personas may be primary personas for their own administrative interface.

SERVED PERSONAS

Served personas are somewhat different from the persona types already discussed. They are not users of the product at all; however, they are directly affected by the use of the product. A patient being treated by a radiation therapy machine is not a user of the machine's interface, but she is very much served by a good interface. Served personas provide a way to track second-order social and physical ramifications of products. These are treated like secondary personas.

NEGATIVE PERSONAS

Like served personas, negative personas aren't users of the product. Unlike served personas, their use is purely rhetorical, to help communicate to other members of the team who should definitely not be the design target for the product. Good candidates for negative personas are often technology-savvy early-adopter personas for consumer products and IT specialists for end-user enterprise products.




About Face 2.0(c) The Essentials of Interaction Design
About Face 2.0(c) The Essentials of Interaction Design
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 263

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net