UXPA Unconference presentation : Is it time to kill personas?
3 likes1,288 views
This document discusses the author's experience with personas and different approaches to using them. It begins by asking who is familiar with personas and their use. The author then describes initially finding personas useful for understanding customers but they later became less used. Alternative approaches discussed include proto personas, arguing personas are unnecessary, and focusing on the "job to be done." The author concludes that the most useful type of persona depends on a company's customer base, size and product maturity.
UXPA Unconference presentation : Is it time to kill personas?
- 1. Before I start, I'd like a show of hands... - who doesn't know what personas are? - Who has created/used personas before? - Who is using persona now? 1
- 2. This talk is mainly about my Love/Hate relationship with persona, and how I came recently to term with it. There are still areas of turmoil, sometimes, so I'd love if people can come and share their experience afterwards... It started at UNI (more than 20 years ago already!) when we used "user stories", scenarios and story boards to design objects.... 2
- 3. And then, Cooper invented this template. *THE* persona with a capital "P". This is what I grew up with, in my designer career. It's designed to create empathy between groups of people working on a product, particularly useful in larger organisations, when developers don't have contacts with customers. It contains: photo, name, status, quotation, short narrative and motivations, and some demographics when relevant, so when I joined Red Gate, I started to create and share some of them . At first, it was good. It was particularly good to me, because it meant I was able to talk and understand customers to create them. I shared them with Dev, and everyone was happy. But as time passed by, they became less used, because: • Requires significant research up front we most of the time don't have the time to do. • Once we've done them once, do we need more of them? everyone know who our customers are in the company: our customers don't change that o en. • So after a few projects, our personas are implicit, and they die in a drawer... They have a bit of bad press, (possibly because there is some confusion between 3
- 4. MKT and UX personas... can you tell me why it is important to know that person owns a Dog? ) Moreover, in our case, they are not aligned with MKT personas (MKT comes after design) • But most importantly, they *REQUIRE CUSTOMERS*, in order to be designed. ... so what if you don't have any yet, because you are working on a new product ? 3
- 5. • To address a few of those points (generation time and lack of customer) Lean UX promoted the concept of "proto persona". • In many respect, this is against the Cooper principle, although I think Norman accepted the concept in 1997) The idea is that you INVENT a persona and you treat it as an hypothesis as the other ones. The main advantage is that it FOCUSES and create alignement within the team. However, they have problems too: • Quicker to do, but can be very wrong, so you need to check your model exist --> there are many more things to check • Complexify hypothesis (don't know if your product or customers is wrong) 4
- 6. • As if it wasn't enough, there is another school of thoughts, recommending we need to *BURN* personas, and that they are actually *USELESS* because: Personas are imaginary customers defined by attributes that don’t acknowledge causality • Assume personas are reduced to demographics(and frankly, sociological profile doesn't impact how you use a website) • Implementation needs to be decouple from motivations and outcomes. Also they claim the context, situations and anxiety of the user is more important than its demographics, so this brings context(The fact that Peter has a degree in MKT, and 2 dogs is irrelevant to the fact he ate a snickers after work.) This is derived from the "job to be done" concept first explained by Clayton Christensen . The impact of this in "scrum" terms, is that you have to replace "user" stories by "job stories". 5
- 7. Now... at this point, my head hurts, my belief are all collapsing, and when I talk about it I hear arguments that are scarily close to what I'd call a religious war... 6
- 8. Although, at the end of the day, if you look at all of them, they look rather similar... they are all designed to know who you are designing for, and what the goals are, sometimes driven by behaviours, sometimes not . The goals in the Cooper persona are designed to give context of the jobs and tasks. The thing is, when you have no real clue about what "job" you are talking about, it is easier conceptualise it in the form of a stereotype. Then you can formulate tasks. Often (particularly in new products) you have an idea of the product/feature to build because you have a profile in mind (it can be you). So, I can see all of those techniques valuables, but at a different time in the development process. 7
- 9. I started to formulate the idea that the type of persona you'll find useful is function of your customer base/company size and yur product maturity: • When you are a startup, not quite sure about what you are building, you can use the Lean "proto personas" to frame your thinking. For example, let's say you want to "develop a screen and face recording device for professional UX people used in user tests" • Then, your product works, you sell many of them, your company grows. You need to prioritise your work. Talking to customers, you realise you also have "dev" or "amateur UX people" and you have to think about what is the most valuable segment to pursue (see morae vs camtasia) • Last, let say your tool become mainstream, you see that more random people like business manager are using your tool. They do it to keep a record of their meeting, and get an automatic transcript. This is when who you are becomes irrelevant compare to "what you do" the task you are solving is universal. 8
- 10. All in all, what really matter is to keep an eye on your customers/users/prospect to understand their motivation, environment and what they do with your tool. The way you document it depends of your audience (dev, management, designers) and the maturity of your business! 9
- 11. Here are a few references, if you are interested. I'd love to discuss what your experience is... ... questions? 10