UX in the Real World: There's no such thing as "No Persona"


Published on

You've either got Good Personas, or .... you've got Zombies!

How zombie peronsas are created, how they can eat your project team's brains and how to protect your project team from them.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • ///re: title: …to put it in Texan////////Terms coined in this presentation:////////The light of collaborative day////: That space in which good personas thrive and zombies are scared to tread////Zombie Personas////: personas which exist but are not “alive to the project”////Undead, Unicorn and Frankenstein Personas////: specific types of zombies in addition to two which I did not coin: “mirror personas” and “stupid-user personas”////Project team ego-quicksand////: the sort of endless looping discussions that project teams sometimes get stuck in and usually learn ways to avoid wherein the point of reference for making a design decision is the speakers own preferences and interests.////Persona Constellation////: a collection of potential end users for an application that consists of rough-draft personas (aside from them definitely all having pictures and names – other details need not be 100% complete). These are then used as props for a meeting with the main business stake holders to validate, improve and select the actual target for the project (the Target Persona Exercise).////Definition looking for a term////:////“tools embedded in a process”//// – I describe good personas this way, trying to draw attention away from the target-persona poster that is the most visible component of a persona’s life-cycle and focus instead on all of the ways in which the good persona is kept from becoming a zombie. I’m curious whether this sort of thing has a name – a tool that is both an object and the structured activity in which it plays a role…? Anybody?////
  • I’m on Xing & LinkedIn:::Xing: http://www.xing.com/profile/Tom_Allison:::LinkedIn: http://de.linkedin.com/in/thomaslawrenceallisonii:::and you can email me at: tallisonATgmail.com
  • Why do you need research? Basically this is about constructing a very sophisticated model that will inform every aspect of your project and its outcome. If you are unaware of significant potential users, then the selection of a target persona for the project may be flawed; if your understanding of the target persona is not an accurate reflection of a likely end user in a likely context of use then most of the power of the persona as a model is lost – and the inaccuracies can both mislead the project at every step and erode confidence in the model amongst the team as these inaccuracies are revealed as the project proceeds. Everything about the hunt for persona models – that is, the conversations with all stake-holders about who the end users are and the discovery involved in going into the field to discover their actual context of use – will greatly improve both your modeling of believable personas (thus increasing your credibility with sponsors and other team members and improving your further discovery efforts by soliciting information in response to your models) and their value to your team’s design and development efforts throughout the projects life-cycle.
  • Here‘s a perfectexample of anprocess-embeddedtool (whateverthewordforthatmightbe).////Thisis anexercisewhich was inventedwhile I was working at MenloInnovations, Inc in Ann Arbor, MI (I helped).////http://www.menloinnovations.com
  • OK, I may be mixing my vampires and my zombies, here, but I really like the expression “the light of collaborative day” ;)
  • //////////Mirror Personas://////////These are the end user models that get used in the absence of any other reference or description. Anyone on the project team that needs to make a design decision simply asks themselves what they would want in that situation (i.e., they metaphorically look in the mirror). Usually that is not a very good reflection of what the targeted end-user would actually want. Often the difference in these two perspectives can render a result anywhere from terribly frustrating to completely useless to the eventual end-users. //////////Undead Personas:////////// These are personas that were in fact constructed at one point in a project but that are no longer truly “alive” to the project. They may be hanging on the design team’s wall, or sitting in a report somewhere online or in a drawer. They exist (that’s the “undead” part), but they exert none of the positive effects that a “good persona” can. They may be the worst sort of persona in that they give the team the false confidence that they have “done personas” and they are probably most responsible for the bad reputation that personas sometimes have – in that, the team “did personas” but “it was a waste of time” because they did not keep them alive to the overall process in order to reap the benefits of their work.//////////Unicorn/Frankenstein Personas:////////// These are personas dreamed up or slapped together from pre-existing parts by someone in the project team. Regardless of how they are used, the signal they give is not a true one. They no more reflect the actual end user than the programmers mirror persona does and team members who understand that they are based on nothing more than someone’s imagination tend to resent them rather than view them as a resource. The don’t work like good personas and they are resented by those in the know. These along with their undead brethren lead to many with limited experience with personas to have a negative impression of them.//////////Stupid User Personas:////////// These are perhaps the hardiest of the zombie personas. If personas are built or even just thought about and kept out of the “light of collaborative day” – that is, are not shared and publicized widely and integrated into every stage of a process – then they tend toward negative or dismissive models of the end user. Teams whose only access to the end user is a combination of direct communication, interruption and negative feedback to their delivered product are very likely to cultivate these personas in the absence of “good personas”.
  • OR
  • This is a scene from Shaun of the Dead – currently my favorite zombie movie (though it is hard to choose).
  • Response to hallway question 1
  • Response to hallway question 2
  • This was a quickly assembled list. I’d love to hear your thoughts on the best resources – and I’ll be happy to update this list as I find more.
  • Stories of zombie personas and other creatures that haunt the lives of UX professionals
  • UX in the Real World: There's no such thing as "No Persona"

    1. 1. Personas: Love ’em or Hate ’em, you can’t NOT use ’em.<br />
    2. 2. Who am I?<br />Tom Allison, UX Researcher and Designer <br />Masters in Human Computer Interaction from University of Michigan School of Information 2004<br />Six solid years of zombie persona hunting<br />
    3. 3. Who are you?<br />How many of you know what personas are?<br />How many of you have made one?<br />How many of you use them regularly?<br />How many of you believe in them?<br />
    4. 4. PERSONAs<br />At varying levels of detail depending on the project need.<br />The Parts: Picture, Name, any formal title, description of physical, emotional and aspirational context surrounding interaction with system<br />
    5. 5. Life-cycle of a “good persona”<br />Research to discover potential personas<br />Selection (e.g., Target-persona Exercise)<br />Central to Design, Specification and Acceptance<br />> Not simply an imaginary construct, but based on immersive research with real users<br />> Not an endpoint – not “a deliverable” or an “artifact” – it must be a tool-embedded-in-a- process<br />
    6. 6. TARGET-PERSONA EXERCISE<br />A good example of “collaborative sense-making“<br />This exercise, conducted early-on by the design team with the full participation of the project sponsor, integrates early research, helps to establish “common ground” across all project participants going-forward, brings conceptual issues to the surface early and contributes, perhaps more than any other single activity, to a truly UX-focused project outcome. Personas alone are not enough. They must be made an on-going part of the design and development process. The Target-Persona Exercise is a tool to help that happen.<br />=<br />Prospective Personas<br /> + Project Sponsors <br /> + Design Team<br />
    7. 7. Good Personas<br />Have these characteristics:<br />Are the result of field observation<br />Are collaboratively selected from a constellation by the project sponsor<br />Are well-known and referenced by all the members of the team throughout the project<br />and perform these valuable services:<br />Engage empathy for the end-user in all phases of decision making <br />Shift discussions away from ego-quicksand<br />Guard against Zombie Personas…<br />
    8. 8. Why “Zombies”?<br />They thrive in obscurity<br />They’re not really “alive” (to the project) and, at the same time, they’re hard to kill<br />They don’t seem that dangerous, but they’ll eat the brains of your project team<br />They are afraid of “the light of collaborative day”<br />
    9. 9. The most common (and dangerous) types of Zombie Personas*<br />Mirror Personas<br />Undead Personas<br />Unicorn/Frankenstein Personas<br />Stupid User Personas<br />*If you’re viewing this slide deck without narration, be sure to check out the notes – especially for this slide.<br />
    10. 10. My thesis, one last time:<br />There’s no such thing as “not using personas”.<br />Either, you have a Good Persona:<br />+ Process<br />Or…<br />
    11. 11. You’ve got ZOMBIES!!!<br />
    12. 12. Why not use a real user?<br />Either as a persona<br />Practicality: privacy – a useful persona needs to be widely and freely shared<br />Can’t pull info from all stake-holders by having them contribute to the persona when it’s not a fictional construct<br />Or, as a member of the team<br />Stockholm-syndrome<br />Would a typical user volunteer to do this?<br />People lie (inadvertently, mostly) – People don’t have conscious access to learned routines, but they will try to be helpful and answer your questions, none-the-less<br />
    13. 13. When might personas not be needed? (exceptions which prove the general rule)<br />Project’s success or failure has nothing to do with end-user acceptance – then again, UX is unlikely to be a role in such a project<br />Designing for a very small number of easily available users (but don’t make the mistake of thinking you can “just ask them”, cf. distinction between explicit and implicit knowledge)<br />Designing in a small team for exactly the mirror persona (e.g., 37Signals) – that is, when Zombies are a passable match for your end users ;)<br />
    14. 14. Some resources for the war against Zombie Personas:<br />Alan Cooper: About Face 2.0, Wiley Publ. Inc. (2003)<br />“Real or imaginary: the effectiveness of using personas in product design” by Frank Long <br /> From conclusion: “This study demonstrates the effectiveness of using personas in the product design process…”<br />“Before Creating the Car, Ford Designs the Driver” NYTimes: July 17, 2009. If you’re skeptical about taking personas seriously for big projects, definitely check this out.<br />Both this talk and my talk regarding Menlo Innovations (the most zombie-persona-free zone I’ve ever worked in) are available on SlideShare<br />
    15. 15. This talk and other juicy bits of UX lore will be featured on a new podcast from Berlin:<br />
    16. 16. Questions?<br />See my profile on Xing and LinkedIn:<br />http://www.xing.com/profile/Tom_Allison<br />http://de.linkedin.com/in/thomaslawrenceallisonii<br />Check out our UX Café podcast to hear the audio of this presentation – and join the discussion:<br />http://www.uxcafe.de/2010/06/zombie-personas/<br />