Death To Personas! Long Live Personas!

2 years ago

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

3 comments

Comments 1 - 3 of 3 comments previous next Post a comment

  • ebacon Elizabeth Bacon 2 years ago
    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!

    Cheers,
    Liz
  • haveaword Tanveer Iqbal 2 years ago
    Thanks for sharing
  • ebacon Elizabeth Bacon 2 years ago
    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.
Login or Signup to post a comment
Login to SlideShare
Login to Twitter
Edit your comment Cancel

Notes on slide 1

55 Favorites

Follow SlideShare

Death To Personas! Long Live Personas! - Presentation Transcript

  1. Death to Personas! Long Live Personas! Elizabeth Bacon & Steve Calde Catalyze, July 23, 2008
  2. Your Presenters Steve Calde Liz Bacon 1992-1994 Rational Software 1998-1999 dba MuseAll 1994-1998 GW Associates, Inc. 1999-2002 Cooper 1998-today Cooper 2002-2007 St. Jude Medical 2007-today Devise + Vice-President, IxDA Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  3. Our talk today covers: Reasons to dismiss personas—and why those reasons might be missing the point Tips for successfully using personas Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  4. Not all good ideas are made to last Jay Adachi, Call Center Agent Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  5. What’s a persona? Profile of an archetypal user Represents the needs of many Based on research Tom Brodie, Shop Manager Tom’s Goals: • Keep the cars coming. “Sometimes I’m so busy fighting • Reduce labor percentages without alligators that I sacrificing customer service. forget about draining • Meet or exceed last year’s numbers for the swamp.” this month. Persona copyright ISI, Inc. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  6. Origins of personas Invented at Cooper Publicized in Alan Cooper’s “The Inmates are Running the Asylum” (SAMS, 1999) Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  7. What some people are saying about personas “Forget about personas.” - Don Norman “We don’t use personas. We use ourselves.” - 37signals “What is actionable about a persona?” - Robert Hoekman Jr “Personas are user-centered bullshit.” - Steve Portigal Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  8. The question: Do we really need to create personas to design fantastic, innovative, user-centered solutions? Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  9. The question: Do we really need to create personas to design fantastic, innovative, user-centered solutions? Of course not! Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  10. The question: Do we really need to create personas to design fantastic, innovative, user-centered solutions? Of course not! But they sure can help... Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  11. Why people hate personas • Personas are fluffy! • Personas are expensive! • Personas don’t design my product for me; they aren’t actionable • Personas really cramp my style; I just want to design what I like • How is understanding today’s users going to help me innovate a new product? Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  12. Fluffy Expensive Don’t Design Products Cramp My Style Fluffy Today vs. Innovation Helpful Tips
  13. Personas are fluffy! Barbie® is a property of Mattel, Inc. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  14. Bad personas are fluffy “Bad” personas are fluffy. And yes, fluffy personas aren’t helpful for doing design or making decisions. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  15. Fluffy personas aren’t really personas Demographic info, photographs, and representative quotes are just small parts of a persona description. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  16. Personas are based on real data “Real” personas are not: • Made up • Job roles • Statistical averages • Based on one person • Use case actors • Market segments Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  17. Traceable details By definition (well, ours at least) personas are based on data that design researchers heard or observed firsthand. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  18. 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!
  19. Tom Brodie Tom has 8 years of experience in lube shop operations. He’s married with two young kids, and his wife jokes that the last time his hands were completely free of grease was on his honeymoon 5 years ago. At the shop he manages, Tom constantly puts out little fires. He works on the floor most of the day, trying to be everywhere at the same time although he prefers to act as greeter and cashier. Most shop trends get measured on a monthly basis, since Tom has to meet sales targets defined by the owner, Eddie, in order to get his manager’s bonus. On a daily basis, Tom frequently monitors car counts, ticket average and employee productivity (especially individual service statistics). Sometimes his team needs a kick in the pants, but he tries to lead by example. Tom Brodie, Tom’s Goals: Shop Manager • Keep the cars coming. Tom has to rely on Eddie’s marketing efforts but car count is his make-or-break figure; he focuses on customer service to “Sometimes I’m so generate repeat customers. busy fighting • Reduce labor percentages without sacrificing customer service. Staffing alligators that I is a tricky balance between keeping the shop’s labor costs down while forget about draining ensuring employees get enough hours and bay times stay low. the swamp.” • Meet or exceed last year’s numbers for this month. The Owner’s sales targets aim for year-on-year increases across the board, but in the current business climate Tom is happy simply meeting last year’s numbers. Persona copyright ISI, Inc.
  20. Goal-Directed Design Cooper’s methodology drives product definition through persona goals. Goals have three flavors: • End goals • Experience goals • Life goals Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  21. Power of human faces We respond viscerally to the human face in ways that we do not respond to other images. Persona copyright ISI, Inc. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  22. Fluffy Expensive Don’t Design Products Cramp My Style Expensive Today vs. Innovation Helpful Tips
  23. Personas are expensive! Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  24. The cost of creating personas The real questions to ask are: 1.Is it worth interviewing and observing users as part of product research? 2.How much will research in the field cost? 3.What are viable alternatives? Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  25. Is it worth spending time with users? Whether you create personas or not, spending time with users: • reveals current behaviors and priorities • challenges—or validates—internal assumptions Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  26. How much does research cost? Considerations include: • Numbers of participants • Research techniques • Travel • Other expenses Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  27. How long does persona creation take? After identifying your key findings, it should take a few days to create a robust set of personas. Field Research Analysis { { Approximately equal duration Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  28. What cost not doing research? The cost really depends on how good a guesser you are... Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  29. What are our alternatives? Try to establish a shared understanding of users with your product development team Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  30. Provisional personas “Provisional” personas are a way to capture & communicate shared assumptions about users so everyone stays on the same page. Mark 40s Financial analyst Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  31. Fluffy Expensive Don’t Design Products Don’t Design Products Cramp My Style Today vs. Innovation Helpful Tips
  32. Personas don’t design my product for me We understand our users. Now what? Persona and research copyright ISI, Inc. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  33. Personas aren’t actionable Personas are not actionable by themselves. Now what? Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  34. Personas are a design tool Personas don’t design products; designers do! Personas help us create scenarios Personas help us communicate design solutions Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  35. April 10, 2008 Personas support scenario-based Introduction This document contains Usage Scenarios along with their derived Product Requirements, and includes additional detail on the Data Elements of the Dashboard system. This revision approach to design reflects the outcome of discussions held at a check-in meeting on April 10th attended by Liz, Wayne, Michael, Mark and Bill. Key scenarios were agreed-upon by the team, while some areas were simplified (see strikethrough) and other items were identified for further investigation. Principally, we VIEW SHOP STATUS PERSONA: Tom (Primary), Manager create personas Context of use: 10:30 am Tuesday at Eddie’s quick-lube shop #3 so that we can Key Scenario Product Requirement build realistic, Tom logs in to his Dashboard, where he has access to Manager-level information. Log-in controls Role-based app display logic meaningful He reviews today’s ticket average, in reference to the month’s target. Date Ticket average: today; vs. target scenarios He looks at the monthly running total for car count. Car count: month-to-date; vs. target Today’s car count is low because cars haven’t really Shop view: Car count, today started rolling in yet. Maybe the rain will clear up Traffic and bring people in? Time Weather Tom wonders if other stores are also seeing lower Chain view: Car count, today volume today, perhaps due to the weather. Tom wonders how impacted his manager’s bonus will Ticket average, car count: year- be this month if the pace remains slow. How’d things on-year basis fare last year? Future: bonus tracking feature Later... Scenario copyright 9 Inc. Page 1 of ISI, Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  36. Communicate reason Expressing product imperatives using personas in scenarios allows for clear prioritization of product requirements. Scenarios with personas: • maintain context • make requirements traceable • represent a persuasive communication Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  37. Personas as validation They minimize risk by letting you know whether your design solutions will be appropriate, disruptive, and/or useful. The same or similar insights can be had from usability testing. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  38. Fluffy Expensive Don’t Design Products Cramp My Style Cramp My Style Today vs. Innovation Helpful Tips
  39. Personas cramp my style! Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  40. Genius design I just want to design what I like. I know what’s best. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  41. Are you a genius? A doctor? Really ask yourself…are you representative of the entire market you are trying to reach? Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  42. Maybe you’re just making it up Major buzz-kill time... The Simpsons were created by Matt Groening Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  43. Fluffy Expensive Don’t Design Products Cramp My Style Today vs. Innovation Today vs. Innovation Helpful Tips
  44. How are personas going to help me innovate? Could personas—which are based on today’s users —help me design the next iPod? iPod/iPod Touch are property of Apple, Inc. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  45. Uncover contextual implications Personas describe people’s current behaviors in the context of their lives. Understanding their context reveals design opportunities and potential for disruption. Optimize flow Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  46. PhotoBook example from Cooper U Cooper conducted design research for the PhotoBook in 2002, and the research & personas had been used in Cooper U for almost six years. Real people are It felt sort of dated, consistent. but... Technology solutions match or don’t match their world. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  47. Personas increase shared team understanding Personas facilitate productive brainstorming for teams comprising various disciplines. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  48. Art within constraints Design is not art—it happens within constraints. Personas help to channel your creativity. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  49. Fluffy Expensive Don’t Design Products Cramp My Style Helpful Tips Today vs. Innovation Helpful Tips
  50. Writing good descriptions • Don’t focus on controversial tomorrows • Don’t give them funny names “Jo-Jo Smoker” Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  51. Writing good descriptions • Make a list of all of the attributes your team described for the persona • Group the attributes under headers • Craft paragraphs that tie the attributes together Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  52. Keep them data-driven • Conduct design research in the field with users • Screen persona goals for applicability to product design Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  53. Be as informal as needed • If the word “Personas” gets peoples’ backs up, then why not rename them? • If they’re used primarily for your design work, don’t make output extremely formal Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  54. Work quickly • Use lightweight recording methods in the field • After user research, analyze findings and create personas as quickly as possible Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  55. Work transparently • Make the process transparent to your colleagues • Don’t introduce your personas in a vacuum Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  56. Maximize usefulness of sets • Show how the persona set describes a range of user behaviors • Embody context of entire product/service workflow involving separate individuals Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  57. Adjustable documentation • Create several weights of persona descriptions to share in different contexts Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  58. Don’t stop with descriptions • Use personas as a tool within a scenario-based approach to interaction design Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  59. Times not to use personas • Product space and target users are extremely well understood by you and all of your decision makers • You’re designing for a very narrow group of users to which you have direct & easy access • Your users are also your stakeholders Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  60. Conclusion
  61. A useful tool Personas are a tool. A useful hammer, but not everything is a nail.... Personas are a means to an end. They are not an end in and of themselves. Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!
  62. Thank you! Steve can be reached at: Liz can be reached at: steve@cooper.com liz@devise.com Elizabeth Bacon & Steve Calde • Catalyze, July 23, 2008 Death to Personas! Long Live Personas!

Elizabeth BaconElizabeth Bacon + Follow

9087 views, 55 favs, 28 embeds more

About this presentation

Usage Rights

© All Rights Reserved

Stats

  • 55 Favorites
  • 3 Comments
  • 347 Downloads
  • 8,342 Views on
    SlideShare
  • 745 Views on
    Embeds
  • 9,087 Total Views

Embed views

  • 309 views on http://uxfactory.com
  • 137 views on http://www.devise.com
  • 94 views on http://www.uxfactory.com
  • 59 views on http://uxd.forumone.com
  • 36 views on http://www.slideshare.net

more

Embed views

  • 309 views on http://uxfactory.com
  • 137 views on http://www.devise.com
  • 94 views on http://www.uxfactory.com
  • 59 views on http://uxd.forumone.com
  • 36 views on http://www.slideshare.net
  • 22 views on http://designative.info
  • 13 views on http://www.adrianchong.com
  • 13 views on http://www.hanrss.com
  • 12 views on http://devise.com
  • 7 views on http://www.uxrefresh.com
  • 7 views on http://www.dymecki.pl
  • 7 views on http://veebikas.blogspot.com
  • 5 views on http://bit.yonsei.ac.kr
  • 3 views on http://uxthink.wordpress.com
  • 3 views on http://oliveyoo.egloos.com
  • 3 views on http://www.forumone.com
  • 3 views on http://aquaclean
  • 2 views on http://mail.naver.com
  • 1 views on http://mail19.paran.com
  • 1 views on http://daumin.daumcorp.com
  • 1 views on http://mail.teaminterface.com
  • 1 views on http://adrianchong.com
  • 1 views on https://kinection.centraldesktop.com
  • 1 views on http://www.veebikas.blogspot.com
  • 1 views on http://192.168.10.100
  • 1 views on http://wildfire.gigya.com
  • 1 views on http://localhost
  • 1 views on http://uxfactory.tistory.com

less

Accessibility

View text version

Additional Details

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint

Categories

Tags

0 tweets
0 shares
WordPress
Blogger
More
options
What's New

© 2010 SlideShare Inc. All rights reserved.