Yes, you should be using personas

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 :)

Design starts with Proposition (ergo Usability)

Layers of Customer Experience

Here’s a typical story.

A project is in its final phases when it gets to the part of the Gant chart that says ‘usability testing’, and so they do.

People come in and are asked to perform tasks, and so they do, with greater or lesser degrees of difficulty. And yet, something else is wrong.

It’s not so much that they *can’t* use your website, it’s just that they don’t want to.

People ask me all kinds of questions about usability. What are the most common usability problems? What’s the best way to make sure our site/application/system is usable? That kind of thing.

It’s pretty clear when they ask these questions that they’re thinking on the presentation layer. Is that button in the right place? Is it big enough? Has it got the right label.

Now, don’t get me wrong, the presentation layer is important, but it’s not the biggest usability problem I see in my work. The biggest problem is that you’re designing something that people don’t care about. You’ve got your proposition wrong.

What’s your proposition? Well, basically it’s the value you’re offering to your customer. Are you offering something they want? Are you solving *real* problems for them? You’d be amazed how often this is not the case, and how often people don’t know about this until they’re about to launch their product or, worse still, once it has launched and is failing.

The diagram above is one that I pull out fairly often these days (it’s another one I’ve borrowed from Flow). It talks about how you need to design from the proposition down. You need to get the value offering right, then look at the model for delivering that value to clients at a conceptual level, then start looking more at what elements go on a page, what functionality is included, how it is structured and ordered. Unless you have all of these in order, it doesn’t really matter where your buttons go or what they’re labeled. Appearance level usability is the most superficial, easily remedied and perhaps even least important of all of the levels of design.

If you’ve got a flaw in your thinking at the top of the chain, then no amount of surface usability is going to save your product.

So, how do you approach this kind of Proposition design and usability? It’s pretty simple really, you test your proposition. This kind of testing (or really, research) is more about talking than tasks, and it’s about understanding your customers better and checking whether you are conceptually on the same page as they are.

I’ve been involved in several projects just in the past twelve months where doing this kind of research has saved companies tens of thousands of pounds (double that if you’re talking dollars) in *not* designing and developing functionality that either was unwanted by their customers or was designed to solve the wrong problems.

Working this out when you have a few pencil sketches or a couple of visio wireframes with a few days invested is an awful lot better than working it out when you get to the ‘usability testing’ line in your Gant chart.

So, if you really want my advice about usability, it’s that it starts right at the very beginning. Before a line (or a box) has been drawn. If you’re not designing the *right thing* then no amount of design expertise is going to get you a really usable product.

Talk to the people you’re designing for.

You’ll save lots of time and money and look really smart.  


WWAD? (What would Apple do?)

Apple Store 

People say that it is some kind of Steve Jobs special sauce that makes Apple the company that it is, but as this Fortune article reveals, they reap rewards from using design techniques that we all have access to, and should *all* be doing. All the time.

These techniques include prototyping:

“One of the best pieces of advice Mickey ever gave us was to go rent a warehouse and build a prototype of a store, and not, you know, just design it, go build 20 of them, then discover it didn’t work,” says Jobs. In other words, design it as you would a product. Apple Store Version 0.0 took shape in a warehouse near the Apple campus. “Ron and I had a store all designed,” says Jobs, when they were stopped by an insight: The computer was evolving from a simple productivity tool to a “hub” for video, photography, music, information, and so forth. The sale, then, was less about the machine than what you could do with it.

But looking at their store, they winced. The hardware was laid out by product category – in other words, by how the company was organized internally, not by how a customer might actually want to buy things. “We were like, ‘Oh, God, we’re screwed!'” says Jobs.

But they weren’t screwed; they were in a mockup. “So we redesigned it,” he says. “And it cost us, I don’t know, six, nine months. But it was the right decision by a million miles.”

and User Research:

“When we launched retail, I got this group together, people from a variety of walks of life,” says Johnson. “As an icebreaker, we said, ‘Tell us about the best service experience you’ve ever had.'” Of the 18 people, 16 said it was in a hotel. This was unexpected. But of course: The concierge desk at a hotel isn’t selling anything; it’s there to help. “We said, ‘Well, how do we create a store that has the friendliness of a Four Seasons Hotel?'” The answer: “Let’s put a bar in our stores. But instead of dispensing alcohol, we dispense advice.”

OK. So maybe you don’t have budget to build a store twenty times over, but everyone has time and budget to do a paper prototype and show some people. Even if that’s all you can do, do it. 

Both of these techniques have been key in helping Apple make more dollars per square foot than stores like Saks or Tiffany – a pretty successful outcome by any measure, not to mention the way that the experience of the Apple store contributes to the over all Apple brand equity.

WWAD? Prototyping and user research. Go crazy.