The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #175 Whitney Quesenbery - The Characteristics of Effective Personas

July 20, 2012  ·  20 minutes

Listen Now

Download the MP3

It’s impossible to design something if you don’t know who you’re designing for. Developing personas through user research is a great way to create a portrait of your users. But once you have your personas, what do you do with them? That’s a question Whitney Quesenbery says she encounters more and more lately.

Show Notes

It’s impossible to design something if you don’t know who you’re designing for. Developing personas through user research is a great way to create a portrait of your users. But once you have your personas, what do you do with them? That’s a question Whitney Quesenbery says she encounters more and more lately.

Whitney is a UX researcher and co-author of Storytelling for Usability. In her Next Step Series virtual seminar, Give Your Users a Seat at the Table: The Characteristics of Effective Personas, Whitney outlines her seven characteristics of effective personas. She ran short of time to answer all of the questions during the live seminar. She’s circling back to address the remaining questions with Adam Churchill in this podcast.

  • How important is it to have personal information in your personas?
  • Should you establish a one-to-one relationship between a persona and an actual individual?
  • How actively should you use personas in Agile user stories?
  • What are the best ways to bridge qualitative personas to your quantitative analysis?
  • How do you do quick personas if they're based on real data?
  • How do you match up your personas with your customer base?
  • How many personas are enough?

Full Transcript

Adam Churchill: Welcome to another edition of the SpoolCast. Recently Whitney Quesenbery joined us for her Next Step Seminar, "Give Your Users a Seat at the Table: The Characteristics of Effective Personas."

In her seminar, Whitney shows the seven characteristics of effective personas, and describes how to use them for improving her experiences. She explains how to bridge research with design, lead collaborative brainstorming activities with teams, and build products that users will love.

Now "The Characteristics of Effective Personas," a Next Step Seminar that we have created in cooperation with Rosenfeld Media, it's been added to UIE's User Experience Training Library, which presently has over 95 recorded seminars from wonderful topic experts just like Whitney. Giving you the tips and technique you need to create great design.

Hey, Whitney, welcome back.
Whitney Quesenbery: Hey, glad to be back.
Adam: Now for those that are listening that weren't with us for your presentation, can you give us an overview?
Whitney: Sure. I've been talking about personas for a long time. Most of the time we focus on what they are and how to create them. But I started talking to people. More and more people are actually doing personas already. They started asking me questions about -- well what do you do once you've done them? Once you've made a persona, what then?

I began to realize that we needed to think about how we take the fabulous research that we wrap up into these wonderful portraits of our users, and how do we carry that into the development process?

In away it kind of recapitulates the whole history of user experience, which is how do we get the things we know how to do more embedded in how we design, conceive, make, develop products?

So I thought of seven things. One is that we really need to be able to be the persona. We need to be able to know how to speak for them. That is we need to know them well enough to be confident that we can represent them. We can do things like, if someone asks you to do an expert review, instead of giving your expert opinion, you can channel the persona and say, "You know, I think that our Mary persona would think this." Now you're not just having a battle, you're actually bringing user research into that review process.

You can do things like role play and exploration, where you actually interview the personas. You think about, what kind of questions would the team like to ask them? Or maybe, what kind of new questions have come up on something new that you're working on?

Of course, once you've got them made you really want to invite them to meet all your friends. You don't want to make them a secret; you want to get them out into the company. Make sure that everybody knows them, well maybe not actually as well as you do, but pretty close.

You might actually let them vote. You're having one of those big meetings where you have the list of 500 features that you want to implement, and you know you're going to do 25 of them. Well maybe the personas get a vote, too. And that lets you think about not just what's good for the business and what's easy to develop and what you can maintain, but which persona each feature is really helpful for, and you can add that to your weighting.

You can also, the sixth thing, is tell their stories. Not just their actions. Not just -- they clicked on this or they bought that or they investigated that, but what are their hopes and their dreams? What could you do in your website or your app or your product that would really fulfill their wildest dreams? Can you help bring that kind of emotional information about delight into the process?

Finally, as you're doing any further research you can keep finding out about them. Because your personas, if they're done right and reflect your real audience, ought to be also the basis for your recruiting. So that every time you talk to another person you should be saying, "Oh, that sounds like that persona. That's a good story to go in there." It lets you keep validating them, and of course the other extra benefit you get from that is that if your personas start to shift away from your user base, you find it that much sooner.
Adam: Let's get to some of the great questions that were left over. Seda wonders, "How important is it to have personal information, like a name, personal background, things like that, on your personas?"
Whitney: I think it's pretty important. In fact, I think it's what makes a persona grow up from being a profile, right? A profile is sort of the assembly of data that you've collected to represent that person: their tasks, their roles, how proficient they are at using computers, that sort of thing. But when you're taking that information and turning it into a persona, you are trying to make something that represents a person.

Now, I shop for shoes, but I don't think of myself as "the shoe shopper." Right? I think of myself as Whitney. And so, I think it's important to give personas a name, to round out who they are a little bit. Am I an avid shoe shopper but I don't like shopping for coats, or am I an avid clothing shopper? How do I fit into the bigger picture of me? How does the bigger picture of me fit into the context in which you're designing?

And it helps us remember that people are not just a role. Obviously, we have roles in the many things we do, but we're more than the sum of our roles, and I think personas help us remember that as well.
Adam: Antonio asks if you're suggesting to establish a one-to-one relationship between the persona--and he describes that as, say, a stereotype--and a person, the actual individual.
Whitney: I would actually call a persona an archetype, not a stereotype. An archetype is an expression of a type, whereas a stereotype, often, at least the way we use it in English today, has some negative connotations. So I like to use the word archetype.

Is there a one-to-one relationship? No, there really isn't. The context in which I get asked that question most often, and in which I've struggled with it myself the most, is in a context where I'm doing something, often an enterprise application, where there is a known body of users. Right? It's the budget managers for your thing, it's the HR managers, or it's the employees. And it's really easy, then, to think, "Well, why do I need all this user research and personas? I can just go ask people out in the office. I can go talk to those actual people."

In fact, I worked on a project once where there were probably 15 people who were the users. But they weren't all going to stay in that company forever. And individuals have quirks. So I think one of the things we want to do is not make the personas so quirky that if a different individual person stepped into that persona and those roles, that it would still work.

So when you get too specific, or when you start to say, "Well, we'll just pick that person over at desk four and they will represent all the other people like them," you start to drift towards their particular preferences or prejudices or things that they like and things that they don't like, instead of keeping your head above that individual level at a slightly broader view.
Adam: Whitney, there was a question that came in via Twitter during the seminar. Any recommendations about active usage of personas and Agile user stories?
Whitney: Well, I'm not a real expert in Agile. I know a little about it and I've worked on some teams that do some Agile work, but I've never lived deeply inside an Agile process. That said, I think that Agile is a fabulous place for personas. After all, the whole idea of user stories is embedded in Agile.

I remember the first time I read a user story. It was a typical short format -- a person in a role does something to achieve a goal. I said, "That's not a story." And the person who was mentoring me into the Agile team said, "But that's not the story. The story is a placeholder for a conversation or a series of conversations that you're going to have with the appropriate people for the card you're working on."

That really opened my eyes because now I can really see how personas work. Because maybe you talked to three or four different people in the course of working on that user story and developing it out into the piece of design that you're creating. Well, you need a way to tie them together.

You also need to make sure that if I'm thinking of this particular user in one way and you're working on another piece of the product for that same user, we have to have a way to make sure we're seeing the same things. Or, more importantly, if we're seeing differences, if maybe in feature A they want to do it in one way and feature B they're giving us very different answers to program from or to design from.

We need to figure out what's the gap. What's missing? How are we not connecting up? Either we're not asking the right questions, or maybe there's a real contextual shift there. We need to somehow show that in context A we have one behavior and one desire and in context B we have another. The persona is a way to hold all of that information across different user stories.
Adam: Milan asked a great question during the seminar, and it's one that you and I agreed we should follow back up on in this podcast. What are the best ways to bridge qualitative personas to your quantitative analysis?
Whitney: First of all, I think it's absolutely essential. I'm a big fan of Lou Rosenfeld's current, he's giving some great presentations on breaking down the silos. As organizations have matured, we have great analytics. We know who's coming to our site. We know what devices they're using. We know what they're searching for. We know what searches are giving us hits.

We probably have a lot of market research. We have a lot of user research. We have both qualitative and quantitative user research. If that stuff lives in separate silos, it's good data but it's not great information. Again, I think that personas are one of the ways to make that connection.

I've seen teams do some really awesome things, like take the characteristics of the persona and say, "Can we identify a visitor, can we identify a collection of visitors in our site analytics? Let's look and see if what we're seeing the aggregate mass of people who we think identify that persona, are they doing the same kinds of things that we're hearing in our qualitative research?"

We say personas ought to be built on data. That is, I think they have a kind of life cycle where they start with some quantitative data, because you don't want to build big massive personas about little tiny edge cases. You want to make sure that the weight of each persona reflects the weight within your audience, either that they're very important personas or that they're personas that need a lot of help or a lot of special attention in some way.

So they start with a kind of quantitative view of the audience. We then use all that qualitative data to really understand them, to get at the qualities, to flesh out the details about what's the skin that hangs on that frame. But then we want to go back to quantitative data, because we might think about behavior. After all, things like quantitative analytics reflect actual behavior.

I think that's a little different than market research, which is just another set of preferential data. But if we know that all of a sudden people are actually buying things. I think one of the famous examples was the Honda Element, which Honda thought they were building for kids. But it turns out that they're really quite popular with people who needed to carry things around, might have kids but don't want a minivan. So they had to shift the persona for whom they were doing advertising.

So that's a case in which they had a persona they started with, they built a product and the analytics -- all the quantitative data -- helped them understand the shift in their market. I'm sure many of the same things happen in software as well. I certainly have seen it in my projects.
Adam: Candace asks a pair of questions. Let me ask them both. I know you think that they're somewhat related. She wants to know -- How do you do quick personas if they're based on real data?
Whitney: Well I think what she's saying is personas should be based on real data, and I certainly agree with that. So the question then is, how can you put a bunch of people in a room and do quick personas without collecting that data?

I guess my answer to that is that there is always data in our heads. We have assumptions, we have ideas, and we need to get those out onto the table as a starting place. I mean those assumptions exist in the room. I used to call them assumption personas, but I actually like quick personas or thin personas better.

So we're building a quick persona which says -- What do we think now? Maybe it's based on market segmentation; maybe it's based on the last five usability tests we've done; maybe it's based on who we hope are audience is.

So we don't know that quick personas are accurate to the audience, but they are a place to start. It's easy to say you haven't done the research, but I work for a lot of organizations that have long and in-depth relationships with their audience. I work for a university; they know a lot about students. I work for a cancer organization. They do a lot of different kinds of work with cancer patients and cancer professionals.

So their presumptions really are informed. They're starting from a place of deep knowledge. Sometimes these are people who have worked in oncology centers.

So they're bringing data. What we're doing is trying to take that data and give it a shape. Get everybody to agree on that shape and we can then see whether it holds up.

I had someone who came to a workshop a couple of years ago, went back, and wrote some assumption personas based on what he had been told by the president of the company that the product was for. He took those to the sales staff and said, "Hey, can you help me fill out some details of these personas?"

They looked at them and said, "I don't know who these people are. They're not who we are meeting out on our sales calls."

So just the act of making and talking about those personas helped show a disconnect between who was really out there who might buy their products, and who they thought they were designing for.
Adam: How do you match up your personas with your customer base?
Whitney: Hmm. Well I think you use things like talking to the salespeople. You use things like looking at the technical support logs or the sales support logs. You look at your site analytics of who's coming into your site, or you look at your sales analytics of who's buying your products.

So I think that's often quantitative.

I have once done a persona myself where we just, in the end we decided that wasn't really a persona that it was something that we thought needed to be there, but we never saw those people. Not in any of the research we did.

I've also done personas where we got very fine grained with them, and in the end they kind of rolled up into -- two or three of them kind of merged into one because we were picking on little tiny differences that we, in the end, thought didn't really matter and weren't helping us design. They were just giving us more paralysis.
Adam: Our friends at Oracle want to know if you have any guidelines on how many are enough. How many should your pool of personas be?
Whitney: Well, boy, that's a tough question because you really have to ask the question, "How broad is your audience?"

Let me just use a medical example. If you're doing a big medical information site, you obviously have patients, but you might have people who are interested in learning about those medical conditions. You might have parents. You might have friends and family. You might have people supporting someone who's ill.

You could say, "Are all patients or all people who aren't medical professionals one persona or are they many personas?" Because you also have medical professionals. Specialists, generalists, nurses, doctors, researchers. You might have journalists as an audience, people who are writing articles and would like to look up information. You might have other kinds of writers. You might have a very broad number of audiences.

One of the things that I like to do is, and we did this at NCI, is we have a persona who is a researcher, but if we're working on a section of the website that's for researchers, we can break that person down. We can sort of unfold them like a matryoshka doll and pick out the three or four different kinds of researchers who have real differences in their information needs. So at a high level, we can look at the whole audience as about five personas. We can also look at individual segments of that audience as three to four personas.

I don't think I completely answered the how many question, so let me go back and try that. I think the answer is that it has to be a number of people you can remember. It has to be enough people that you're representing the variation in your audience and not so many that you need to get out an encyclopedia every time you have to refer to them.

I hate to say things like, "seven plus or minus two" because I'm not sure that completely applies here. Cooper talks about a primary persona, a secondary persona, and then tertiary personas. I think that works for some kinds of applications. I think it doesn't work for others. I might talk about sets of personas where we look at, for instance, say, a pre-university student, someone who's attending university, and an alum who's already graduated. They might reflect a process or they might reflect a set of attitudes.

I'm studying because I'm 18 and my mom told me I have to go to college. I'm studying because I'm trying to get a higher degree to increase my job, or I'm studying because I just enjoy learning.

You might take any of those different approaches, but it has to be something you can hold in your head, and that you don't get lost in the details. And if you need to break them down further at lower levels, then you can go ahead and do that.
Adam: Whitney, that was awesome. Thanks for circling back with us.
Whitney: Thank you, it's always fun.
Adam: Thanks everyone for listening, and for your support for the UIE virtual seminar program. Remember, you can get all the details on upcoming seminars at