Personas seem to go in and out of fashion. Not long ago, people were advocating hyper-researched personas done in painstaking detail, these days designers seem more inclined to leave them out of the process.
So, are personas actually useful or should we stop wasting time and ditch them?
I first came into contact with personas in an academic context. They seemed like a nice idea but I tended to use them to justify my design rather than to guide design, which seemed kind of back to front.
Since then, I’ve worked in places where personas are more or less embraced as part of the process, and then longer I use them, the more I’ve come to the opinion that personas are incredibly valuable, but not for the reasons that many people think they are.
If I’m working on a UCD project (and thankfully, these days that is pretty much every project I do), then I would much prefer to include persona development in the process than not.
But, having said that – I find personas virtually useless when it comes to design, and I very rarely reference them in making design decisions. For me, personas aren’t about design, but that doesn’t mean they’re not incredibly powerful in other ways.
Personas communicate the user centred process like no other method
Having your clients view user research and testing is incredibly powerful in helping them realise that there is a problem in the way they’ve been approaching things to date (if you’re not encouraging stakeholders to actively participate in observing research and testing you’re missing out on a lot). But to get them to actually understand what user centred design is about – you need personas.
Personas should always be developed collaboratively with key stakeholders – as many as possible. They can often be derived from existing marketing personas or profiles (but, don’t be mistaken that personas that the marketing department gives you are personas you can use without any work). You should try to validate your personas with some kind of user research if at all possible – this can be in the form of some contextual interviews, lab based studies, or by talking to people in the company who interact with user directly on a regular basis (I’ve found people who work in call centres can often provide invaluable insight to what users are really like).
Personas should define the boundaries for which you will design. It’s a common misconception that personas are about creating a set of ‘typical’ or ‘stereotypical’ users. Much more useful is to use personas which incorporate edge cases behaviour or requirements. Including these kinds of personas means that you actually end up catering for a much greater portion of your user base, and it also offers the potential for ‘limiting’ personas (think Clevis McCloud if you’ve read Inmates – if he can use it, anyone can.)
Creating ‘edge case inclusive’ personas and then prioritising personas and their goals is much more useful in helping decide what functionality goes in and what doesn’t. And which of the tasks or outcomes are most common, or more important. Decisions which are critical foundations to allowing good design work.
Personas are powerful in guiding requirements definition.
Even before you start designing you need to know what the product is and what it does. What are it’s core feature and what are it’s advanced functions. Personas really help guide discussion and decision making on requirements.
It’s generally agreed that one of the biggest factors for bad user experience is featuritis. Products that do too many things, or that prioritise advanced functionality over core functionality.
Putting each function to the test using personas before letting it in the door is very helpful. Then giving features relative priority using the number and importance of personas who are using them helps guides the overall application or site’s design priorities.
Using this evaluation process makes putting the user at the centre of the design process habitual and natural, and is also very helpful in reaching concensus within a project team.
Personas kill the ‘elastic user’
If I’m managing to inspire you to use personas more or differently, and you haven’t read it recently, let me encourage you to take the time to read Allan Cooper’s ‘The Inmates Are Running The Asylum‘. It’s a classic text that is renown for making programmers angry because Allan isn’t particularly flattering to them, but it gives real insight into the original ideas behind personas and I think you’ll find yourself even more inclined to use personas regularly.
I re-read it earlier this year and I particularly took away the idea of the Elastic User. This is where stakeholders make statements about what ‘users’ want, what ‘users’ do, what ‘users’ prefer, and because the ‘user’ in that context is so undefined and broad, they are able to say almost anything they like and there is no real way to contradict that opinion.
The creation of personas means that user groups are much more defined, so broad sweeping statements about what users want can actually be tested against something. Rather than having a free pass to do anything to the requirements or design by just using the word ‘user’, these assertions can now be tested and validated against more closely defined user characteristics and goals.
Use what you’ve got to build personas
Sometimes you’ll have a whole lot of research, sometimes you’ll have practically nothing. Either way, personas can be useful. Obviously the more you know the better, but even just a quick verbal sketch can be extremely powerful.
Not long ago I used the following persona in a design workshop:
‘Betty is a pensioner who lives in suburban Newcastle and is in charge of the local Neighbourhood Watch chapter’
That’s it. But it made a huge difference because it created an edge case persona for a site that was originally targeted at statisticians. ‘Creating’ Betty allowed the team to see that designs would work perfectly well for people who understood the language of statistics would be completely useless for Betty. And we found that pages that were really *for* Betty hadn’t actually be designed appropriately for her at all.
Sometimes, a pencil sketch persona can provide massive bang for buck.
You should care what car your persona drives
One of the things that make personas easy to criticise is that sometimes they feel like an exercise in creative writing.
‘Clare is 28 and lives in Primrose Hill. She drives a Prius but only on the weekends and she has a puppy that she takes walking twice a day. Clare is single but dates frequently and likes to travel.’
For as long as you think personas are about design you’re right – what does this have to do with design? When you use personas predominantly as a communication tool, then these small details become all important. After all – what you are trying to do is humanise the ‘target audience’. As humans, it is exactly these little details we care about, it’s what helps us to relate to other people and what makes them real. Does it really *matter* what car Clare drives? Well… kind of. People choose things like cars to drive and places to live as a means of communicating who they are. It adds depth to Clare’s personality. But, I’d never advocate actually *researching* those details. They’re communication devices, if people don’t know what Prius *means* then there’s no point using it. Make sense?
Don’t design for personas
As I mentioned before – personas should include observed edge case behaviour and requirements. From your personas you can work out what functionality is included and what is the core functionality. Once you’ve got that information – and you’ve immersed yourself in understanding the users through the creation of the personas – put them away and use your skill as a designer.
If you use the personas to closely guide your design you will end up supporting a series of edge cases. This will invariably mean that your CORE functionality is compromised. That’s bad design.
Once you’ve designed the product, you can then use the personas to evaluate the design, and to help communicate to your stakeholders how and why your design supports the goals and tasks of your personas.
Don’t be tempted to use the goals and task lists you generate for your personas as a jigsaw puzzle to layout on a page. That way failure lies.
So. Personas. I’m a fan, but you have to know where their power lies and use them appropriately, and don’t get too caught up in the process of their creation – do what you can with what you’ve got, bring your stakeholders on board and teach them how to be user centred, and get on with the important business of designing great user experience.
(Need more background on personas. Austin Govella has collected a bunch of useful links)
Note: this post was edited on 30 April 07 to better clarify my position on ‘edge case’ personas in response to come of the comments received :)
Thanks for writing this. Especially the bits on using what you’ve got, and using personas for requirements instead of design.
I was in the midst of a post along similar lines, but you’ve said it much better, so I will point here.
I spent a fair while looking at personas recently – in my experience they only work if you’ve got total buy-in from the team that is supposed to be using them.
@ Austin – no problem. My pleasure :)
@ Matthew – yes, I agree. Buy in is very important. I think that getting that buy in is a big part of persona development and a key reason why they should be developed collaboratively.
Great points Leisa. I agree that using them to guide the design /directly/ ain’t a good use for them. But understanding the /motives/ of the user when designing is important. Kinda like – review your personas and get into the head of the user through personas before working on the design (a kind of osmotic process of sorts).
We recently used the “pencil sketch” approach to personas for the Future is man made site and it was incredibly useful, especially for stakeholders who weren’t across the level of thinking about our target audience as others. It helped a lot to put a “face” to it too – a cut-out from a magazine etc. to help make it feel a bit more real.
It served us well in defining features and content planning (being a content driven site, this was very important).
We then followed that up by running a research program with people that “fit” loosely with our personas to get first hand feedback about their motivations, and their use of the site. This filled in gaps, uncovered things we’d missed etc. and will inform future development. We’re also noticing patterns of use that will inform this future work.
We’ve really benefited from the process – I’m looking forward to doing more in my new role…
congrats on the new job Grant :) I’ve heard nothing but good about the Digital Eskimo crew!
The example you give of using personas sounds like a fairly typical one to me, with all the typical benefits. Glad to hear you’ll be getting to do more of it!
On a tangent, I was just reading some more of Simplicity Shift on the tube on the way to work today (for the London IA Bookclub I’m hosting on the 15th May – come along if you’re in or near London!) – there’s a chapter on User Blindness which is all about personas which is very interesting and helps illustrate some of these points even more.
The author, Scott Jensen, says that you have to get down to two personas only… what do you guys think of that? I definitely think the few personas you have the better, but there are some projects where I’d *never* be able to get down to two.
So, Betty, she’s that retired statistics professor, right? If you’re going to boil a persona down so much, you better focus on information most relevant to the product you’re designing. “Betty’s education is at the high school level and her skills in statistics are limited knowing how to read a bar chart and line graph and how to calculate and interpret an ‘average.’†Make a clear statement about the user’s limits in using the product, rather than relying on idiosyncratic assumptions given certain general personal attributes (e.g., about what a pensioner from Newcastle does and doesn’t know). If nothing else, it immediately short-circuits the boss from forcefully declaring silly things like “everyone knows what a standard deviation means.†A persona can indeed be as short as two sentences, but if it is, one sentence should state the user’s goal or motives in using the product (as Grant emphasizes), and the other should state the user’s constraints.
I agree with the general point you’re trying to make Michael, but in the case I was describing, it was enough to say that Betty was the local neighbourhood watch person as opposed to the site’s traditional audience of statisticians.
Making assumptions can be dangerous yes, and it would be nicer not to make them, but in some cases, those very assumptions and stereotypes are what you rely on when you’re doing a very shorthand sketch of a persona – they can be a very efficient form of communication.
If I’d have used the description you suggested I would have failed at creating a persona that people could actually empathise with – which for me is *more* important than ‘making a clear statement about the user’s limits in using the product’.
At any rate, I just thought I’d share Betty with you as a pencil sketch persona I’d used in a particular situation with success much greater than the effort that went into her creation. She’s by no means an example of the ‘perfect’ persona… but then I’m not convinced there is such a thing… except for the best solution for the project and challenges you’re facing at the time.
Thanks for the succinct post, Leisa. I completely agree. Too, I like the fact that your example highlights edge case personas–definining who is NOT the targeted consumer of the product, but whom some stakeholders might initially think the product IS for. In other words, when a stakeholder says, “Our product is for everyone,” you can say, “Is it really for Betty? I think not.”
Too, when finding personas, often we have to do work that we don’t show clients/stakeholders. That is, your team might have a whole bunch of edge case personas, core personas, and secondary ones, but only deliver the core.
On another note…here in Richmond there was a divey restaurant called Betty’s. Kind of a city redneck place. People bought it, refurbished it, made it hipper, and called it Not Betty’s
Thanks Leisa.
I meant to mention – I laughed when I read the “Prius” reference – in one of the personas we used, we did mention that they had a Prius. In our particular case the specific make of car had relevance.
The idea of getting down to 2 personas is interesting, but I’m not sure about it…
We got 6 personas in total, but quickly realised that 2 of them were a bit tenuous – were they really our audience? Were we just making them up, or were they “real”? The follow-up research identified that if they were our audience, we needed to rethink a few things.
We also recognised that the motivations of two very different groups – a business owner with kids, and a mum with kids – were very similar in the end, so we could probably roll them into one.
But that still leaves 3 or 4. Getting it down to 2 might be pretty tough – but I suspect the process of looking for the commonalities in motivation and skills would be useful, even if you end up with a couple more than 2…
Very handy reminder about the elastic users – helped me with our current persona-definition exercise (linked to my name) as part of an open product development exercise.
Thanks again
Thank you for this excellent write-up. It completely confirms my original feelings about using persona’s in the design process.
I am currently a graduate student of Communication & Multimedia Design in The Netherlands. Ever since I was introduced to the concept of persona’s, I loved it. However, it immediately became clear to me and my fellow students that the way they are actually used was different from the way they are advocated to be used. In reality, this resulted in interesting discussion with my teachers (who are always right).
Currently in my final internship and I did exactly the same as before. Create a persona to get an idea of who we are dealing with — the whole humanising aspect. On the other hand, like you said, it also implicitly excluded people, but I never actually realised that. :-)
But during the entire process, I never looked at them again. I wouldn’t even know the name I gave them. I just know who they represent and indeed, who they not represent.
I hope it will not go like it did in my final semester before my internship. During that assessment the teacher thought he was clever to ask us the names of the persona’s we created. Of course, we had no clue, but we could have told him everything about them if we wanted to. *sigh*
Bookmarking this article and I’ll keep it ready to send to my teacher if neeeded ;-)
Well, call me confused. You seem to be making the case that personas should be used, but that you should only model edge cases with them, which will essentially let you know what not to do.
Then you warn against using personas for core design because you will only end up designing *for* edge cases…. well yeah, if your personas are edge case personas, that only makes sense.
It seems to be if your personas are based on good, collaborative ethnographic research then you’ll have a good group of users that portray the whole user base. And using them as a design tool should reap you all the benefits that Cooper talks about.
I agree with your points about personas aiding the whole UCD process and being a tool for countering the elastic user.
But I’m not seeing the benefit of only designing edge case personas and then dropping them when it’s time to design. On what are you then basing your design solutions? I’m not seeing how knowing what not to do gives you the flip side benefit of knowing what is the right thing to do.
Grant: “But understanding the /motives/ of the user when designing is important. Kinda like – review your personas and get into the head of the user through personas before working on the design (a kind of osmotic process of sorts).”
Right on! I agree wholeheartedly with the post but also feel its nigh on impossible to be a designer without having some form of end user in mind when putting the nuts and bolts together. When a designer has a couple of possible interaction solutions in front of them, they can/should do some internal role playing to proceed down the right path. Right?
This can be done without and definition of formal communication personas, but I dont think I could do my job without instinctive internal personas.
I’m not really a fan of personas per se, not because they don’t work – they clearly do, however I feel they are just one way to achieve the desired result – there are other ways and the way that works best is often down to who is working on a project. Personally my feeling is personas are a fashionable approach to user-centred design – they often become less ‘real’ and more ‘fluff’ and can actually prove to be more of a distraction if not produced intelligently.
I’ve always found that one of the best uses of Personas is simply to facilitate a convergence of the design team’s conception of users with a client’s conception. Through a collaborative persona creation process with the client, a design team can come to this understanding and wipe away incorrect preconceptions. If research is added to this mix, it’s even better, but even a process without research is far, far better than skipping personas completely. Without research, this process presumes that the client generally knows more about users than the designers do, which is almost always the case with a client whose business is healthy, but a good design team can even help such a client come to new understandings of who their users are and how they behave by asking the client questions they’ve never asked before.
Great discussion of personas, though I disagree that personas should represent edge-case users. Too often we spend too much time focused on edge cases, resulting in user experiences that are optimized for 5% of our audience rather than the 95% that represent typical uses. Personas work because they represent the set of users who are most important to our organizations – not just the eccentric users.
Thanks for all your comments – this is a really interesting discussion.
I’m actually going to go back and edit my post a little bit because it doesn’t actually say what I mean about edge cases…
Having said that, I stand by the idea that your personas shouldn’t represent ‘typical’ users, what I mean is that within your personas you should include the reasonably edgecases that you wish to cater for in your design.
I originally got this idea from Allan Cooper, particular the example he gives of the persona Clevis McCloud – remember Clevis? Clevis wasn’t a ‘typical’ user by any stretch, but Cooper realised that it Clevis could use it then anyone else in his target audience could also use it. (It being the In Flight Entertainment system they were designing… if you don’t know this story, go read Inmates). This is what we’d call a limiting use case – if this person can use it, anyone can.
But the other thing that we find about intergrating edge case requirements or behaviours into personas is that you actually end up designing for a larger portion of your user base… I have a nice picture for this I’ll try to find and post for you that demonstrates this. If you are only developing ‘typical’ personas then you are missing out on the opportunity to define and design more sophisticated and advanced requirements… if you’re using personas properly that is :) Integrating edge case behaviour into personas solves this problem.
I hope that clears up the edge case situation, or at least fuels some more debate :)
Meanwhile – Jon B 0 you said there were other techniques that worked just as well as personas for doing what personas do. I’d love to hear more about these?
For a social media web site, the user who actually uploads original content generally comprises under 5%, and often as low as 1%, of the user base. By this measure, the “content contributor” user type is an edge case. But according to the business model, they are the most essential user type. So certainly such an edge case should be included.
Most businesses have edge cases that are so important to the business that they should be included as essential user personas.
Chris, good point. My use of percentages was hasty. In your example, the contributor is clearly key to the business and thus not an edge case.
An example I often use is designing for a real estate site. If I’m developing a persona for a home seller, I’ll create archetypal attributes for that persona so that he or she represents many users in that mode of use. I wouldn’t make my home seller persona a realtor, because that unlikely edge case will likely throw off the team from thinking about what more typical home sellers actually need. Some edge cases are critical to the business, and others are just unnecessary distractions from where we should be paying attention.
yeah Chris, that’s a great way of illustrating it. Just to be clear, the only edge cases that we’re interested in when it comes to personas are the edge case behaviours that we want to support in our design – even if they are not the most *typical* behaviours of our audience.
Doesn’t Allan mean the infrequent user type, who happens to come across your site or product, when he’s talking about edge-cases.
The Clevis guy you’re talking about is somebody who just needs a usable platform to work with. “If he can you use it, everybody can” should be a characteristic of a primary persona. But that’s not what a edge-case is. I haven’t read Inmates, but I have read About Face 3.0 and Allan is quite clear on the subject.