Personas

To create a product that must satisfy a broad audience of users, logic tells 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 successfully accommodate a variety of users is to design for specific types of 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 may please some users will likely interfere with the satisfaction of others (see Figure 5-1).

click to expand
Figure 5-1: A simplified example of how personas are useful. If you try to design an automobile that pleases every possible driver, you end up with a car with every possible feature, but which pleases nobody. Software today is too often designed to please too many users, resulting in low user satisfaction. Figure 5-2 provides an alternative approach.

The key is in choosing the right individuals to design for, ones whose needs represent the needs of a larger set of key constituents (see Figure 5-2), and knowing how to prioritize design elements to address the needs of the most important users without significantly inconveniencing secondary users. Personas provide a powerful tool for understanding user needs, differentiating between different types of users, and prioritizing which users are the most important to target in the design of function and behavior.

click to expand
Figure 5-2: A simplified example of how personas are useful. By designing different cars for different people with different specific goals, we are able to create designs that other people with similar needs to our target drivers also find satisfying. The same holds true for the design of digital products and software.

Since they were introduced as a tool for user modeling in The Inmates Are Running The Asylum (Cooper, 1999), personas have gained great popularity in the usability community, but they have also been the subject of some misunderstandings. This section attempts to clarify and explain in more depth some of the concepts and the rationale behind personas.

Strengths of personas as a design tool

The persona is a powerful, multipurpose design tool that helps overcome several problems that currently plague the development of digital products. Personas help designers:

  • Determine what a product should do and how it should behave. Persona goals and tasks provide the basis for the design effort.

  • Communicate with stakeholders, developers, and other designers. Personas provide a common language for discussing design decisions, and also 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 because, as the authors have found, it is easier to understand the many nuances of user behavior through the narrative structures that personas employ.

  • Measure the design's 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 doesn't replace the need to test on real users, it provides a powerful reality check tool for designers trying to solve design problems. This allows design iteration to occur rapidly and inexpensively at the whiteboard, and it results in a far stronger design baseline when the time comes to test with real users.

  • Contribute to other product-related efforts such as marketing and sales plans. The authors have seen their clients repurpose personas across their organization, informing marketing campaigns, organizational structure, and other strategic planning activities. Business units outside of product development desire sophisticated knowledge of a product's users and typically view personas with great interest.

Personas also resolve three user-centered design issues that arise during product development:

  • The elastic user

  • Self-referential design

  • Design edge cases

We discuss each of these briefly in the following sections.

THE ELASTIC USER

Although satisfying the user is our goal, the term user causes trouble when applied to specific design problems and contexts. Its imprecision makes it unusable as a design tool—every person on a product team has his own conceptions of the user and what the user needs. When it comes time to make product decisions, this "user" becomes elastic, bending and stretching to fit the opinions and presuppositions of whoever has the floor.

If programmers find it convenient to simply drop a user into a confusing file system of nested, hierarchical folders to find the information she needs, they define the elastic user as an accommodating, computer-literate power user. Other times, when they find it more convenient to step the user through a difficult process with a wizard, they define the elastic user as an unsophisticated first-time user. Designing for the elastic user gives the developer license to code as he pleases while still apparently serving "the user." However, our goal is to design software that properly meets real user needs. Real users—and the personas representing them—are not elastic, but rather have specific requirements based on their goals, capabilities, and contexts.

SELF-REFERENTIAL DESIGN

Self-referential design occurs when designers or developers project their own goals, motivations, skills, and mental models onto a product's design. Most "cool" product designs fall into this category: The audience doesn't extend beyond people like the designer, which is fine for a narrow range of products and completely inappropriate for most others. Similarly, programmers apply self-referential design when they create implementation-model products. They understand perfectly how it works and are comfortable with such products. Few non-programmers would concur.

DESIGN EDGE CASES

Another syndrome that personas help prevent is designing for edge cases—those situations that might possibly happen, but usually won't for the target personas. Naturally, edge cases must be programmed for, but they should never be the design focus. Personas provide a reality check for the design. We can ask, "Will Julie want to perform this operation very often? Will she ever?" With this knowledge, we can prioritize functions with great clarity.

Personas are based on research

Personas must, like any model, be based on real-world observation. As discussed in the preceding chapter, the primary source of data used to synthesize personas must be from ethnographic interviews, contextual inquiry, or other similar dialogues with and observation of actual and potential users. The quality of the data gathered following the process (outlined in Chapter 4) directly impacts the efficacy of personas in clarifying and directing the synthesis of design solutions. Other data that can support and supplement the creation of personas include, in rough order of efficacy:

  • Interviews with users outside of 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 gathered from literature reviews and previous studies

However, none of this supplemental data can take the place of direct interaction with and observation of users in their native environments. Almost every word in a well-developed persona's description can be traced back to user quotes or observed behaviors.

Personas are represented as individuals

Personas are user models that are represented as specific, individual humans. They are not actual people, but are synthesized directly from observations of real people. One of the key elements that allow personas to be successful as user models is that they are personifications (Constantine and Lockwood, 2002). They are represented as specific individuals. This is appropriate and effective because of the unique aspects of personas as user models: They engage the empathy of the development team towards the human target of the design. Empathy is critical for the designers, who will be making their decisions for design frameworks and details based on both the cognitive and emotional dimensions of the persona, as typified by the persona's goals. (We will discuss the important connections between goals, behaviors, and personas later in this chapter.) However, the power of empathy should not be quickly discounted for other team members. The authors have observed that personas not only make the decision process for incorporating specific design elements easier from a design standpoint, but more compelling from a stakeholder-adoption standpoint. When personas have been carefully and appropriately crafted, stakeholders and programmers begin to think about them as if they are real users.

Grudin and Pruitt (2002) have noted the power of fictional characters in television programs (the authors would draw a comparison to an earlier form, the novel) to engage viewers. They note, as well, the power of method acting as a tool that actors use to understand and portray realistic characters. In fact, as we shall see in Chapter 6, the process of creating personas from user observation and later role-playing scenarios from the perspective of these personas is in many ways analogous to method acting. One designer has described the authors' Goal-Directed use of personas as the Stanislavsky Method of interaction design.

Personas represent classes of users in context

Although personas are represented as specific individuals, at the same time they represent a class or type of user of a particular interactive product. Specifically, a persona encapsulates a distinct set of usage patterns, behavior patterns regarding the use of a particular product (or analogous activities in the domain if a product does not yet exist). These patterns are identified through an analysis of ethnographic interviews, supported by supplemental data if necessary or appropriate. These patterns, along with work- or lifestyle-related roles define personas as user archetypes (Mikkelson N. and Lee, W. O., 2000). The authors refer to personas as composite user archetypes because personas are in a sense composites assembled by clustering related usage patterns observed across individuals in similar roles during the Research phase.

PERSONAS AND REUSE

Organizations with more than one product often want to reuse the same personas. However, to be effective, personas must be context-specific—they should be focused on the behaviors and goals related to the specific domain of a particular product. Personas, because they are constructed from specific observations of users interacting with specific products in specific contexts, cannot easily be reused across products (Grudin and Pruitt, 2002) even when those products form a closely linked suite. Even then, the focus of behaviors may be quite different in one product than in another, so researchers must take care to perform supplemental user research. The authors believe that, in most cases, personas should be researched and developed individually for different products.

ARCHETYPES VERSUS STEREOTYPES

Don't confuse persona archetypes with stereotypes. Stereotypes are, in most respects, the antithesis of well-developed personas. Stereotypes represent designer or researcher biases and assumptions, rather than factual data. Personas developed drawing on inadequate research (or synthesized with insufficient empathy and sensitivity to interview subjects) run the risk of degrading to stereotypical caricatures. Personas must be developed and treated with dignity and respect for the people whom they represent. If the designer doesn't respect his personas, nobody else will either. Personas also bring to the forefront issues of social and political consciousness (Grudin and Pruitt, 2002). Because personas provide a precise design target and also serve as a communication tool to the development team, the designer much choose particular demographic characteristics with care. Ideally, persona demographics should be a composite reflection of what researchers have observed in the interview population, modulated by broad market research. Personas should be typical and believable, but not stereotypical. If the data is not conclusive or the characteristic is not important to the design or its acceptance, the authors prefer to err on the side of gender, ethnic, age, and geographic diversity.

Personas explore ranges of behavior

The target market for a product describes demographics as well as lifestyles and sometimes job roles. What it does not describe are the ranges of different behaviors that members of that target market exhibit regarding the product itself and product-related contexts. Ranges are distinct from averages: Personas do not seek to establish an average user, but rather to identify exemplary types of behaviors along identified ranges.

Personas fill the need to understand how users behave within a given product domain—how they think about it and what they do with it—as well as how they behave in other contexts that may affect the scope and definition of the product. Because personas must describe ranges of behavior to capture the various possible ways people behave with the product, designers must identify a collection or cast of personas associated with any given product. Multiple personas carve up continuous ranges of behavior into discrete clusters. Different personas represent different correlated groups of behaviors. These correlations should become evident upon examination of the research and should be logically connected. The process of clustering behaviors is discussed in greater detail later in this chapter.

Personas must have motivations

All humans have motivations that drive their behaviors; some are obvious, and many are subtle. It is critical that personas capture these motivations in the form of goals. The goals we enumerate for our personas (which we will discuss at length later in this chapter) are shorthand notation for motivations that not only point at specific usage patterns, but also provide a reason why those behaviors exist. Understanding why a user performs certain tasks gives designers great power to improve or even eliminate those tasks, yet still accomplish the same goals.

Personas versus user roles

User roles and user profiles each share similarities with personas; that is, they both seek to describe relationships of users to products. But personas and the methods by which they are employed as a design tool differ significantly from roles and profiles in several key aspects.

User roles or role models, as defined by Larry Constantine (1999), are an abstraction, a defined relationship between a class of users and their problems, including needs, interests, expectations, and patterns of behavior. Holtzblatt and Beyer's (1998) use of roles in consolidated flow, cultural, physical, and sequence models is similar in that it attempts to isolate various relationships abstracted from the people possessing these relationships.

It is the authors' argument that these methods can be problematic for these reasons:

  • It is more difficult to properly identify relationships in the abstract, isolated from people who possess them—the human power of empathy cannot easily be brought to bear on abstract classes of people.

  • Both methods focus on tasks almost exclusively and neglect the use of goals as an organizing principle for design thinking and synthesis.

  • Holzblatt and Beyer's consolidated models, although useful and encyclopedic in scope, are difficult to bring together as a coherent tool for developing, communicating, and measuring design decisions.

Personas address each of these problems. Well-developed personas incorporate the same type of relationships as user roles do, but express them in terms of goals and examples in narrative. This makes it easier for both designers and stakeholders to understand the implications of design decisions in more human terms. Personas also use goals to provide contexts to and structure for tasks, incorporating cultural and workflow information and translating it into behavioral drivers.

In general, personas provide a more holistic model of users and their contexts, where many other models seek to be more reductive. In any case, personas can certainly be used in combination with these other modeling techniques; and as we'll discuss at the end of the chapter, some models make extremely useful complements to personas.

Personas versus user profiles

Many usability practitioners use the terms persona and user profile synonymously. There is no problem with this if the profile is truly generated from ethnographic data and encapsulates the depth of information the authors have described. Unfortunately, all too often, the authors have seen user profiles that reflect Webster's definition of profile as a "brief biographical sketch." In other words, user profiles are often a name (and possibly a picture) attached to brief, usually demographic data, along with a short, fictional paragraph describing the kind of car this person drives, how many kids he has, where he lives, and what he does for a living. This kind of user profile is likely to be a user stereotype and is not useful as a design tool. Although we give our personas names, and sometimes even cars and family members, these are employed sparingly as narrative tools to help better communicate the real data and are not ends in themselves. Supporting fictional detail plays only the most minor part in persona creation and is used just enough to make the persona come to life in the minds of the designers and the product team.

Personas versus market segments

Marketing professionals may be familiar with a process similar to persona development because it shares some process similarities with market definition. The main difference between market segments and design personas is that the former are based on demographics and distribution channels, whereas the latter are based on user behaviors and goals. The two are not the same and don't serve the same purpose. The marketing personas shed light on the sales process, whereas the design personas shed light on the development process. This said, market segments play a role in persona development: They can help determine the demographic range within which to frame the persona hypothesis (see Chapter 4). Personas are segmented along ranges of behavior, not demographics or attitudes, so there is seldom a one-to-one mapping of market segments to personas. Rather, market segments can act as an initial filter to limit the scope of interviews to people within target markets (see Figure 5-3).

click to expand
Figure 5-3: Personas versus market segments. Market segments can be used in the Research phase to limit the range of personas to target markets. However, there is seldom a one-to-one mapping between market segments and personas.

User personas versus non-user personas

A frequent product definition error is to target people who review, purchase, or administer the product, but who are not end users. Many products are designed for columnists who review the product in consumer publications. IT managers who purchase enterprise products are, typically, not the users of the products. Designing for the purchaser is a frequent mistake in the development of digital products.

Although you cannot ignore the IT managers' needs, they will ultimately be better served if the product serves the real end user well. If the end user is satisfied and productive, the IT managers are successful as well.

In certain cases, such as for enterprise systems that require maintenance and administrator interfaces, it is appropriate to create non-user personas. This requires that research be expanded to include these types of people. These personas may have their own, separate interfaces, or they may simply be useful from a rhetorical standpoint to delineate what the product should and shouldn't do. Non-user personas also often provide additional business goals that must be balanced with the user goals embodied by the user personas.




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