Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Good descriptions Personas should capture: Death To Personas! Long Live Personas!


Published on

Good descriptions
Personas should capture:
• Attitudes
• Work or activity flows
• Environmental factors
• Skill level
• Current frustrations
• Goals
Let’s read a persona description...

Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!

Published in: Design, Education, Business
  • Hey guys! Who wants to chat with me? More photos with me here 👉
    Are you sure you want to  Yes  No
    Your message goes here
  • Nice presentation. Thanks for posting!
    Are you sure you want to  Yes  No
    Your message goes here
  • It appears that the link to the original event presentation (a WebEx recording done through Catalyze) was stripped out of my earlier comment. [EDIT] Additionally, I have just found out (April 2009) that the event recording is no longer available.

    Thanks for your interest, and please don't hesitate to get in touch to talk more about personas!

    Are you sure you want to  Yes  No
    Your message goes here
  • This presentation was delivered as a Catalyze webinar on July 23, 2008. The event recording is accessible at (as a WebEx playback/download).

    Here is the full set of questions posed by attendees, with answers provided by Liz Bacon:

    [Q] Are there generic personas available for designers (web beginner, cardiologist, small business owner, etc)?

    [Liz] I'm not aware of any resources for 'generic personas' and I'm definitely ambivalent about the concept. Although there are some widely-shared behaviors and qualities of people that get captured with personas, particularly with respect to consumer-oriented design problems, it is very important that personas be researched and created within the context of a specific domain. You don't necessarily need a very specific design problem (for I have found that personas often have longevity above and beyond the initial project scope), but you really do want to focus your field research within a particular domain in order to identify and capture the most pertinent patterns of behaviors and human qualities that are needed for design.

    [Q] Can you describe how personas and use case actors differs? Seems like they are very similar.

    [Liz] My deepest experience with use case actors was in the context of an employer's application of Alistair Cockburn's use case methods. Although the use case model created in this environment was able to absorb the idea that a given Actor was an Electrophysiologist persona named Dr. Langston, or a Sales Rep persona named Brad Shore, there was no room in the use case documents themselves for the biography or other humanizing aspects of the personas that were so important for design decisions. However, if you can imbue use case actors with the key qualities of personas (i.e., behaviors, attitudes & goals) then more power to you! Go forth with richer, human use case actors that improve the whole team's efforts!

    [Q] How do you educate the team on the difference between user personas and marketing/buyer personas?

    [Liz] There's been lots of discussion lately about buyer personas, which is a marketing-oriented type of persona. It seems direct enough to state: the buyer persona will be purchasing the product while the user persona will be using the product, and these two people are not always the same person. Perhaps the latter point is most difficult to convey, especially if your marketing team works diligently to characterize their buyers but the engineering team may not have the same focus on characterizing their users. If your marketing department has had success with applying buyer personas in defining their product messaging, then probably this success could be a helpful wedge to introduce the idea of researching and developing *user* personas for the purpose of defining products.

    [Q] Could you talk a little bit about how to go from user research to personas?

    [Liz] Sorry, no, I can't talk 'a little bit' about it! :) It's quite a big subject. However, I could say that what happens in going from user research to personas is that you identify the patterns in your data in so far as they relate to human qualities. Ask yourself, for example: what were the main behaviors that we learned about from talking to users? What were the main motivations of the people we talked to? Write each of your insights on a whiteboard, and then start to map all of your research participants against those qualities. For example, if a key behavior was technical ability, write that on the board and then map your users on a scale from low to high. Do the same with all other behaviors and motivations. The patterns that emerge among people's placement on these scales will indicate the presence of user archetypes. For example, you might find that highly technical people are motivated by gadget lust, and thus you have what I call a proto-persona.

    [Q] Are there best practices about the types of questions to ask in usability testing, observations in order to create accurate personas?

    [Liz] Firstly, usability testing is not the kind of research activity that can generate the depth of information required for a helpful persona. Usability testing, at least in a broad definition, involves observing (and/or recording, measuring, judging) users performing tasks with various stimuli. This type of controlled experimental activity is unlikely to elicit the underlying behaviors, attitudes and goals that you want to understand about your users. Now, user *frustrations* may be well represented in this activity! But it's not as helpful as open-ended observation and dialogue. When observing and interviewing users, good questions to ask at the beginning of the effort are extremely open-ended questions such as: 'What do you do in a typical day?' in order to understand workflow and tasks, and also: 'What sort of things cause problems for you?' to understand obstacles as well as motivations.

    [Q] You talked about how not to name your personas. How should you name them?

    [Liz] I follow a common practice of finding age-appropriate candidate names by using the U.S. Social Security Administration website. I then work with my team-mates to vett possible names, since the name has to feel natural to the team so that it will be used regularly. As I mentioned, it's also important to stay away from names of stakeholders, even if distant. Usually, I hold off on last names until the persona picture is selected, since surnames can invoke ethnicity and you don't want a mismatch between a name and a face.

    [Q] How can key scenarios and product requirements help inform user workflows when using personas?

    [Liz] Here's another deep question, although I will re-arrange the terms a little bit! In my practice, personas are the principal players in the key path scenarios that I define for a given product. These key path scenarios represent the full set of product requirements. For example, the step of 'Tom logs in to his dashboard' embodies the system functionality of Tom logging in to a website as well as the system using Tom's role to display the right dashboard components. These key path scenarios also represent the new, improved user workflows that I have crafted to design an innovative, satisfying and appropriate product. So essentially, personas lead to key path scenarios (which represent new user workflows) which lead to product requirements.

    [Q] Do you see any value in creating a 'negative' persona, i.e. a non user? What would be the impetus for creation of this persona?

    [Liz] Yes, absolutely! The negative persona is a type of persona to employ when you're facing deeply-entrenched internal expectations about typical users. Negative personas are a political tool, because they explicitly represent a user for whom we are *not* designing. In my experience, the negative persona is often one who represents an expert user while in point of fact the most important user for a product design is usually the 'perpetual intermediate'. However, I want to note that negative personas are not typically needed in persona sets, and generally should be used only when you really need to beat back a dangerous assumption.

    [Q] Does one product have one primary persona? Can a product have two primary personas?

    [Liz] The relationship of a product design to the number of primary personas is a complex area, the answer to which depends on the particular product scope at hand. One product can have one primary, or two primaries, or multiple primaries. What the primary persona indicates is a target user who will not be satisfied with a solution designed for somebody else. Thusly, you might have aspects of your system that serve different personas, such that individual personas could be considered primary for a given aspect or feature. However, the *secondary* persona designation is also pertinent here. The secondary persona is satisfied by the system designed for the primary persona but has additional needs that must be met. I want to also mention that the topic of persona classification is under some discussion among those who debate formal persona methodologies. The simple 'one primary, one interface' prescription may be insufficient for the kind of multi-layered and large-scaled design problems (not to mention more frequent re-design and renovation efforts) that we often face these days.

    [Q] Can you describe the process of how you came up with the fleshed-out persona with the embedded table (with the repairman).

    [Liz] Hey now, Tom is a quick-lube Shop Manager, not a repairman! :) That aside, I conducted several days of user research in the field observing and interviewing quick-lube shop managers, assistant shop managers and lube technicians. Then I spent a couple days finding patterns among my research findings (working at the whiteboard as alluded to above). Then I spent a couple days fleshing out my three proto-personas with names, biographies and narratives, including locating pictures through an online image service. The process concluded with a face-to-face meeting with my client to review the personas, which discussion resulted in some minor refinements to the final descriptions.

    [Q] How would you characterize/describe the difference between personas created for the purpose of designing a product/solution vs. personas that companies need or want to learn more about how their users interact with them in general?

    [Liz] Hmm! I don't really see a difference, because the persona that is useful for designing a product/solution is one that will represent how users interact with companies in their domain. Perhaps this question relates back to the issue of user personas vs. buyer personas? If so, please refer to my earlier answer. If I'm still missing the point, please don't hesitate to ping me for more discussion!

    [Q] Resources for ROI arguments?

    [Liz] Yeah, sorry, there really aren't any. Next question? Sorry, I don't mean to be rude, but it's a bedeviling question that I now believe designers should redirect towards a discussion of *risk*. Quantifying ROI on qualitative user research and interaction design is extraordinarily difficult, if not impossible. By contrast, asserting that a company's risk of *not satisfying* users appropriately is too great to not address through investment in research & design is a much more appropriate ground on which to base our arguments.

    [Q] An ideal communication tool is self-evident; the audience focuses immediately on the content, not the tool. Isn't there a lot of baggage with scenarios to use with novices/stakeholders, like the quant. vs. qualitative nature, etc.?

    [Liz] On the contrary, I think that personas and scenarios have an inherently clear and self-evident quality that lets them speak volumes at every stage of product definition and design. Real personas -- those based on field research -- will represent known truths that get stakeholders nodding their heads in agreement. It should be considered a very positive thing that they are possible to create based on best practices in qualitative research subject numbers. Then when personas are used in scenarios, they create a compelling vision of the future that is easily understood. Most people like to be entertained, and personas can tell excellent stories. In my experience, the only people who get hung up on quant. vs. qual. tend to be marketing folks who are only familiar with quant. methods.

    [Q] You talked about doing field work such as interviews for each of the specialized roles. Are there types of data to examime initially to come up with the persona roles in the first place, such as customer support files or customer surveys?

    [Liz] Good question -- yes, definitely, those are good data to examine! The 'persona hypothesis' that guides field research scoping and scheduling is ideally informed by turning to internal resources. These can include sources mentioned above as well customer support staff, web site statistics, and any existing points of contact with the user population. This step is an important one, especially when you have limited time & budget to discover roles in the field.

    [Q] Who should own the persona ideally? UIX designer, Product Management?

    [Liz] Ideally, the interaction designer should own the persona during product design & development because the persona is an essential tool of interaction design. However, many forces work together in the course of product development, and establishing team buy-in for your personas is best done collaboratively. Additionally, Product Management is going to be an important gate-keeper to help focus all team-members on satisfying the chosen primary persona(s). It's also likely that over time your company's emphasis on different personas may shift, and it is possible that Product Management is better placed to make decisions about target users for various releases. We should also recognize that every company has a unique internal team dynamic. Overall, I think that what's most important is that the persona identified at the beginning of a project remain the same for the duration of that project. After all, personas are used in part to establish the fundamental ground upon which to base design decisions; if that landscape shifts then all design work done to date might be cast into jeopardy.

    [Q] What differences do you see between personas for Web sites and personas for other applications?

    [Liz] I haven't found much if any difference, with perhaps half of my work being on rich internet applications and half being on desktop and proprietary software/hardware systems. People who use various such products are all, ahem, people. What changes between personas for various types of systems is that you focus your research and insights on the particular domain in which you're working (as I mentioned above). So, a persona for a web site in the banking domain is going to have significant details related to financial attitudes, etc., whereas a persona for a mobile device is going to have significant details related to mobility. However, such differences are not as related to technology per se as they are to the overall context of the design problem.

    [Q] Do you use 'special needs' personas in your research? For example, Good Grips products were originally designed for individuals with severe arthritis but the product found mass appeal.

    [Liz] I generally do not use 'special needs' personas in my research, with the noteworthy exception of sometimes having a persona represent a member of the population who may have challenges using digital technologies (for example, a senior citizen). However, to date I have never chosen such a persona to be the primary persona for the design solution. This is an interesting topic, and one that I'd like to think more about. I think that it's entirely possible that principally considering the needs of individuals who face visual or mental challenges may result in an interaction design that represents extreme simplicity and elegance. Then again, it may result in one that fundamentally frustrates the more capable user....

    [Q] How do you know when you've 'gone overboard' and provided too much information in the textual description of a persona?

    [Liz] This is where I would recommend review by a friendly colleague who's not afraid to be honest. If their eyes glaze over as you're reading the persona description to them, or if you email it to them and s/he can't get done reading it in a timely fashion, then you've probably got a verbosity problem. And if you *yourself* start to feel this way about your persona description, then you're almost certainly right! Sometimes judicious 'bulletizing' can work wonders in a dense persona description, and sometimes you can slim down an entire persona set by illustrating their workflow or environment with diagrams and information visualizations.
    Are you sure you want to  Yes  No
    Your message goes here