Finally, when usability testing, be sure that what you are testing is actually measurable, that the test is administered correctly, that the results will be useful in correcting design issues, and that the resources necessary to fix the problems observed in a usability study are available. Jakob Nielsen’s Usability Engineering is the classic volume on usability and provides excellent guidance on the subject.
08_084113 ch04.qxp 4/3/07 6:02 PM Page 72
72
Part I: Understanding Goal-Directed Design
Card sorting
Popularized by information architects, card sorting is a technique to understand how users organize information and concepts. While there are a number of variations on the technique, it is typically performed by asking users to sort a deck of cards, each containing a piece of functionality or information related to the product or Web site. The tricky part is analyzing the results, either by looking for trends or using statistical analysis to uncover patterns and correlations.
While this can undoubtedly be a valuable tool to uncover one aspect of a user’s mental model, the technique assumes that the subject has refined organizational skills, and that the way that they sort a group of abstract topics will correlate to the way they will end up wanting to use your product. This is clearly not always the case. One way to overcome these potential challenges is to ask the users to sequence the cards based upon the completion of tasks that the product is being designed to support. Another way to enhance the value of a card sort study is to debrief the subject afterwards to understand any organizational principles they have employed in their sort (again, attempting to understand their mental model).
Ultimately, we believe that properly conducted open-ended interviews are quite capable of exploring these aspects of the user’s mental model. By asking the right questions and paying close attention to how a subject explains his activities and the domain, you can decipher how he mentally associates different bits of functionality and information.
Task analysis
Task analysis refers to a number of techniques that involve using either questionnaires or open-ended interviews to develop a detailed understanding of how people currently perform specific tasks. Of concern to such a study is:
Why the user is performing the task (that is, the underlying goal)
Frequency and importance of the task
Cues — what initiates or prompts the execution of the task
Dependencies — what must be in place to perform the task, as well as what is dependent on the completion of the task
People who are involved and their roles and responsibilities
Specific actions that are performed
Decisions that are made
08_084113 ch04.qxp 4/3/07 6:02 PM Page 73
Chapter 4: Understanding Users: Qualitative Research
73
Information that is used to support decisions
What goes wrong — errors and exception cases
How errors and exceptions are corrected
Once the questionnaires are compiled or the interviews are completed, tasks are formally decomposed and analyzed, typically into a flow chart or similar diagram that communicates the relationships between actions and often the relationships between people and processes.
We’ve found that this type of inquiry should be incorporated into ethnographic user interviews. Further, as we’ll discuss in the next chapter, the analysis activities are a useful part of our modeling activities. It should be noted, though, that while task analysis is a critical way of understanding the way users currently do something, as well as a way of identifying pain points and opportunities for improvement, we want to reiterate the importance of focusing first and foremost on the users’ goals. The way people do things today is often merely the product of the obsolete systems and organizations they are forced to interact with, and typically bear little resemblance to the way they would like to do things or the way they would be most effective.
User research is the critical foundation upon which your designs are built. Take the time to plan your user research and match the appropriate technique to the appropriate place in your development cycle. Your product will benefit, and you’ll avoid wasting time and resources. Putting a product to the test in a lab to see whether it passes or fails may provide a lot of data, but not necessarily a lot of value. Using ethnographic interviews at the beginning of the process allows you, as a designer, to truly understand your users, their needs, and their motivations. Once you have a solid design concept based on qualitative user research and the models that research feeds, your usability testing will become an even more efficient tool for judging the effectiveness of design choices you have made. Qualitative research allows you to do the heavy lifting up front in the process.
Notes
1. Schön, D., and Bennett, J., 1996
2. Pinker, 1999
08_084113 ch04.qxp 4/3/07 6:02 PM Page 74
09_084113 ch05.qxp 4/3/07 6:02 PM Page 75
5
Modeling Users:
Personas and Goals
Having gone out into the wide world to understand your users’ lives, motivations, and environs, a big question arises: How do you use this research data to come up with a design that will result in a successful product? You have notebooks full of conversations and observations, and it is likely that each person you spoke to was slightly different from the others. It is difficult to imagine digging through hundreds of pages of notes every time you have to make a design decision, and even if you had the time to do this, it isn’t entirely obvious how these notes should inform your thinking.
We solve this problem by applying the powerful concept of a model. Models are used in the natural and social sciences to represent complex phenomena with a useful abstraction. Much as economists create models to describe the behavior of markets, and physicists create models to describe the behavior of particles, we have found that using our research to create descriptive models of our users is a uniquely powerful tool for interaction design. We call these user models personas.
Personas provide us with a precise way of thinking and communicating about how users behave, how they think, what they wish to accomplish, and why. Personas are not real people, but they are based on the behaviors and motivations of real people we have observed and represent them throughout the design process. They are
09_084113 ch05.qxp 4/3/07 6:02 PM Page 76
76
Part I: Understanding Goal-Directed Design
composite archetypes based on behavioral data gathered from the many actual users encountered in ethnographic interviews. Personas are based upon behavior patterns we observe during the course of the Research phase, which we then formalize in the Modeling phase. By using personas, we can develop an understanding of our users’
goals in specific contexts — a critical tool for using user research to inform and justify our designs.
Personas, like many powerful tools, are simple in concept but must be applied with considerable sophistication. It is not enough to whip up a couple of user profiles based upon stereotypes and generalizations, nor is it particularly useful to attach a stock photograph to a job title and call it a “persona.” For personas to be effective tools for design, considerable rigor and finesse must be applied to the process of identifying the significant and meaningful patterns in user behavior and turning these into archetypes that represent a broad cross-section of users.
While there are other useful models that can serve as tools for the interaction designer, such as workflow models and physical models, we’ve found that personas are the strongest, and it is possible to incorporate the best from other modeling techniques into a persona. This chapter focuses on personas and their goals. Other models are considered briefly at the end of the chapter.
Why Model?
Models are used extensively in design, development, and the sciences. They are powerful tools for representing complex structures and relationships for the purpose of b
etter understanding, discussing, or visualizing them. Without models, we are left to make sense of unstructured, raw data, without the benefit of any organizing principle. Good models emphasize the salient features of the structures and relationships they represent and de-emphasize the less significant details.
Because we are designing for users, it is important that we can understand and visualize the salient aspects of their relationships with each other, with their social and physical environments, and of course, with the products we hope to design.
Just as physicists have created models of the atom based on observed data and intuitive synthesis of the patterns in their data, so must designers create models of users based on observed behaviors and intuitive synthesis of the patterns in the data.
Only after we formalize such patterns can we hope to systematically construct patterns of interaction that smoothly match the behavior patterns, mental models, and goals of users. Personas provide this formalization.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 77
Chapter 5: Modeling Users: Personas and Goals
77
Personas
To create a product that must satisfy a diverse audience of users, 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 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).
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 that 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 to this approach is first to choose the right individuals to design for —
those users whose needs best represent the needs of a larger set of key constituents (see Figure 5-2) — and then to prioritize these individuals so that the needs of the most important users are met without compromising our ability to meet the needs of secondary users. Personas provide a powerful tool for communicating about different types of users and their needs, then deciding which users are the most important to target in the design of form and behavior.
Since they were introduced as a tool for user modeling in The Inmates are Running The Asylum,1 personas have gained great popularity in the user experience community, but they have also been the subject of some misunderstandings. We’d like to clarify and explain in more depth some of the concepts and the rationale behind personas.
09_084113 ch05.qxp 4/3/07 6:02 PM Page 78
78
Part I: Understanding Goal-Directed Design
Alesandroís goals
▶ Go fast
▶ Have fun
Marge’s goals
▶ Be safe
▶ Be comfortable
Dale’s goals
▶ Haul big loads
▶ Be reliable
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.
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:
09_084113 ch05.qxp 4/3/07 6:02 PM Page 79
Chapter 5: Modeling Users: Personas and Goals
79
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 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; it’s easier to understand the many nuances of user behavior through the narrative structures that personas employ. Put simply, because personas resemble real people, they’re easier to relate to than feature lists and flowcharts.
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 with 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 actual people.
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 can resolve three design issues that arise during product development:
The elastic user
Self-referential design
Edge cases
We discuss each of these briefly in the following sections.
The elastic user
Although satisfying the users of our products is our goal, the term user causes trouble when applied to specific design problems and contexts. Its imprecision makes it dangerous as a design tool — every person on a product team has his own conceptions of who the user is and what the user needs. When it comes time to make product decisions, this “user” becomes elastic, conveniently bending and stretching to fit the opinions and presuppositions of whoever’s talking.
If the product development team finds it convenient to use a confusing tree control containing nested, hierarchical folders to provide access to information, they might
09_084113 ch05.qxp 4/3/07 6:02 PM Page 80
80
Part I: Understanding Goal-Directed Design
define the user as a computer-literate “power user.” Other times, when it is more convenient to step through a difficult process with a wizard, they define the user as an unsophisticated first-time user. Designing for the elastic user gives a product-development team license to build what it pleases, while still apparently serving
“the user.” Of course, our goal should be to design products that appropriately meet the needs of real users. Real users — and the personas representing them — are not elastic, but rather have specific requirements based on their goals, capabilities, and contexts.
Even focusing on user roles or job titles rather than specific archetypes can introduce unproductive elasticity to the focus of design activities. For example, in designing clinical products, it might be tempting to lump together all nurses as having similar needs. However, if you have any experience in a hospital, you know that trauma nurses, pediatric intensive-care nurses, and operating room nurses are quite different from each other, each with their own attitudes, aptitudes, needs, and motivations. A lack of precision about the user can lead to a lack of clarity about how the product should behave.
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. Many “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 the data is structured and how software works and are comfortable with such products.
Few nonprogrammers would concur.
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.
Typically, edge cases must be designed and 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, like any models, must be based on real-world observation. As discussed in the preceding chapter, the primary source of data used to synthesize personas should be in-context interviews borrowing from ethnographic techniques, contextual
09_084113 ch05.qxp 4/3/07 6:02 PM Page 81
Chapter 5: Modeling Users: Personas and Goals
81
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 design activities.
Other data that can support and supplement the creation of personas include (in rough order of effectiveness):
Interviews with users outside of their use contexts
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 14