Should we kill personas? (Marine Barbaroux)

Download Should we kill personas? (Marine Barbaroux)

Post on 18-Oct-2014




5 download


UXPA 2014 Unconference presentation from Marine Barbaroux.


Should we kill personas?

Should we kill personas?Marine Barbaroux - @miss_embeHead of UX, Red Gate24th JUL 2014

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?


image: hugh mcleod - @gapidvoidThis 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....

2image: Ben Melbourne - @benmel1) the "cooper"

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 often.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 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 ?32) the Lean UX ad-Hoc (or proto) personas

image: Jeff Gothelf 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 checkComplexify hypothesis (don't know if your product or customers is wrong)4images: @alanklement

3) No persona: Job stories instead of User stories

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 dont acknowledge causalityAssume 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".5image: (c) 1993 Steve McConnell

... but fundamentally, are they so different? 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

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.7image: @miss_embeproduct maturitycustomer base/company sizead-hoc personapersonaJTBDtimelineI 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.

8These tools are complementaryAlways keep an eye on your users/customersKeep an eye on their enviroment too: it might change their goalsIt doesn't matter what persona artifacts look likeUnderstand the forces that drive your users/customersModify your views and product accordinglyconclusionAll 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! the job by C.Christensen:

referencesHere are a few references, if you are interested.I'd love to discuss what your experience is...

... questions?10