Jared Spool: Welcome, everyone, to another episode of the SpoolCast. I am very excited today because we have Tamara Adlin with us. She recently gave a UIE virtual seminar called "The Power of Ad Hoc Personas: Truly Practical Methods to Get Your Organization on the Same Page." She's an expert in developing personas. She has actually written not just one but two books on the subject, including her brand-new one, "The Essential Persona Lifecycle," which she co-wrote with John Pruitt. Tamara, welcome.
Tamara Adlin: Thanks. I'm delighted to be here again.
Jared: So, you gave us this fabulous seminar. Everybody loved it. And it was a whole 90 minutes. So, I'm going to ask you, in three sentences, to tell us what you said in 90 minutes.
Tamara: I'll do my best. Basically, what we talked about was the value of getting an executive team super-duper clear on their business and brand objectives, and then creating what I like to call ad hoc personas that really capture the goals and needs of key target users, and then align those according to business objectives. And then all sorts of glorious things happen when you do that, including the ability to effectively triage features and design great end-to-end experiences and lots of other delightful things.
Jared: I like this method because it's like a beautiful project kick-off method. It has structure to it. It gets the executives and stakeholders involved. It gets everybody sort of on the same page about what you're trying to do from a user-experience perspective. And it has a nice, lovely deliverable that's more than just, "Hey, I'm about to tell you what we're going to do," and then you all go away, and then you come back in a few months and will have done whatever that was.
Tamara: And even more powerful is that it creates this common language, and it also, all of a sudden, effectively communicates what the business goals are, and forces the executive team to actually articulate those. So, yeah, it's great for a kick-off.
Jared: Yeah, and articulate that in the context of what users need from the design. It's beautiful all the way around. And for those people who didn't get a chance to listen to the seminar, I highly recommend that you go do that.
But, what you can do, while you're waiting to go do that is, listen to Tamara answer some of the questions that came up during the seminar that we didn't have a chance to answer because we got a ton of them. And so I'm just going to start right in with those.
And the first one has to do with using legacy categories as the first step. So, in the seminar, you suggested that you start by using the categories that the organization always used, even though, after you've refined the stickies with all the people's needs on them, you may reorganize them in a different way.
Jason had a question, which is, "Why have them originally classified as stickies by this sort of legacy thinking if you're just going to have them reclassify them immediately after that?"
Tamara: This whole process is really based on getting assumptions out into the light. It's the idea that the only assumptions that can hurt you are the ones you don't know about. And basically, I think that you really have to recognize what people are saying today and what language there is today, in order for them to show themselves that that language doesn't work as well as another language could.
If you don't start with those categories and sort of demystify them and bring them out into the light and show that there's a better way, those categories will stick around in people's brains, and they'll always be thinking, "Well, what about enterprise? We could just call them enterprise, couldn't we?" That's the logic behind it.
It sounds wacky, because you are going back to an old way, but the only way you can get to something new is to recognize what happened before and really show why it's not as effective a way of thinking as people think.
Jared: I've got to tell you, the first time I heard you talk about this, that sort of jumped out at me too, this idea that the whole point of this process is to get them to not think in those old-fashioned terms anymore, so why are we going back there first?
But, I think you hit the nail on the head. If you don't deal with it, it's sort of the elephant in the room. That makes perfect sense to me, that you would go there, you'd say, "OK, this is the old way we thought about it, but is this really the way we should be thinking about it?" And then they sort of talk themselves out of that categorization scheme.
Tamara: There's another very pragmatic reason for doing that. When people are standing there holding 20 stickies in their hand, it can be very intimidating to look at a blank sheet of paper and do an assimilation exercise. Lots of people haven't even ever done an assimilation exercise before.
So, if you put down these old categories, it turns out to be much quicker to get everybody just to shove those stickies down under the old categories. They're familiar. It's quick. And then what you do is this sort of brain flip, where you say, "All right, we're taking these old categories away." Now that all the stickies are down on the paper, suddenly, everybody's able to sort of look at them and not be as intimidated as much by reorganizing them.
Jared: Yeah, that just makes perfect sense to me.
Now, you've got all these executive stakeholders in the room. And I've got to tell you, when I first heard about this, I was nervous about this too. A lot of people get nervous, those of us seasoned UX professionals, saying, "Look, the reason that we were going through this whole persona thing to begin with was because nobody really knows who these users are."
And Chris brought up a question. She says, "Don't the stakeholders in the meeting need to know the consumers before they can make these assumptions about building personas?"
Tamara: The answer starts from the answer to the previous question, which is you have to get all of these assumptions out into the light. In the best of all worlds, yes, everybody would be aware of the actual users, based on really strong data and really great analysis. But, the fact is that it just isn't true, and you have to start somewhere. And again, there's all these sacred cows moving around in people's brains, and you have to get them out into the light.
There's something else that I think is, again, a very pragmatic thing to remember. So many companies are so far away from thinking about their users at all that even just getting the existing assumptions, right or wrong, organized at least enables you to create an experience that makes sense, end to end, for somebody.
And also, every company was formed for some reason: "We can build X product to make Y people happy." And many companies that I work with, personally, have drifted and haven't even thought about that in an incredibly long time. That's why I do that.
Jared: And when you're doing this, you have in the room the boss, and then you have what you call the grand-boss and the great-grand-boss, right? So, you've got these different layers in there. Is it the case that when you have these different layers in there, you actually get different perspectives from each layer, and all of a sudden you realize that everybody is sort of working on different assumptions?
Tamara: Well, there you go, right? First of all, if you can get the boss and the grand-boss and the great-grand-boss in the room, that's fantastic. If you can't, there are other ways around it, and I think that there are some questions about that coming up.
I love it when that kind of confusion comes up, or when your boss and your grand-boss don't disagree, because I just say, "OK, here's part of the problem." And I point it out. It's a lot harder to do that if you're not an outside consultant [laughs] because you can get yourself in trouble, but that's the problem we're trying to solve.
Also, when we put all the sticky notes down and there's dozens of them, I point to them and say, "Here's the problem. What we're working on now is..."
Somebody said something great to me: you all can't be on the same page if there isn't a page. [laughs] So, part of it is really about creating that page, and showing people if there isn't one.
Jared: Right, right. That makes perfect sense.
So, along these lines, Jason asks, "How do you get the stakeholders to actually get into the room? How do you get the boss and the grand-boss and the great-grand-boss to participate?"
Tamara: Well, if you're a consultant coming in from the outside, you set up the project that way. But, if you're coming in from the inside, it may not be possible to do it that way from the very beginning. And if it isn't, then what I like to do is create a pull rather than a push. What I mean by that is, maybe you can do a smaller project first and show some results from it.
Or you can do some personas and some goal definition and then approach your boss and say, "Here's what I think our goals are and I'm sure they're wrong. Can you help me clarify these for myself?" And then that person might say, "Well, we've got to get several people together," or whatever.
As long as you can get those business goals and brand goals nailed, or at least signed off on from your boss or grand-boss, the rest of the stuff you can kind of do on your own and then present it: "Here's how we understand you. We know that the business goal is x, and pretty sure we're right that this Susan is one of the people we have to satisfy in order to do that. Do you agree? Does this sound right to you?"
And then once people see some success or they realize that it's a little easier to talk about Susan than the user, there does tend to be a pull on their part. They want these things that are easier to use and then maybe for the next project you can say, "Maybe we can do this as a team."
Jared: Right. So, you're basically working with the personas as almost this bait to get them to participate further, because they begin to see the value of having this specific person involved. You have the specific personality to work with.
Tamara: Here's a great way to think about it. Use personas to mirror back to the executives what you think you hear them saying. You can say, "Well, OK, bear with me, and this is going to seem silly at first, but what I think I hear you saying is that Susan is more important than Phillip. Is that right? Do I understand you correctly?"
And they will humor you. Go in with your belly showing. Go in begging for clarity from them. And you really are doing them a service by reflecting back to them what you heard, what you didn't hear, what's clear, what's not clear, in a way that's non-offensive and non-political.
Jared: Now, the folks at Expeditors International, they had a question during this session which had to do with the fact that they're the IS organization, and so they need to get cooperation not just from their own executive tree but from folks in other parts of the organization who they don't report to. Is it basically the same process for doing that or are there tricks for presenting this stuff to the business units that you work for when you're in an IS organization?
Tamara: I mean, I think it's the same thing, right? I think what you do is you use that to ask if you got it right or to say, "Here's a kind of an easy way to be thinking about this. Susan really needs these four features, and so this is why we're bulking up our server, or capacity, or whatever."
And then again, people will start to recognize, "Well, maybe this is kind of an easier way to talk about this." And then they can ask, "Where did these personas come from?" or what have you. Then you can pull people into a more rigorous way of creating and vetting those personas.
Jared: I've seen a lot of teams sort of present the personas as a fait accompli. "Here are our seven users. We've got Mary and Bob and Bill and Ahmed and all these different people." But, what you're saying is, "We sat down. We came up with this first-cut group of folks and I want to now see if you think we got it right. Here's what we came up with. Is this what you think our users look like?" And be a little bit more open to getting their input in that way, to get them to engage with that content a little more.
Tamara: Yeah. I think there are two responses I would have to that. One is, I just don't think that it works to have personas thrown over the fence. You can certainly go hire somebody to do a bunch of market research and a bunch of behavioral research and come back with shiny documents and big posters and whatever.
But, I just don't think that works, and the reason I don't think it works well is because you have all those mooing sacred cows. You have people still thinking the words "enterprise" and "small business," and if you don't get that stuff out it will never disappear. And the only way to get that stuff out is to have people convince themselves that it's not so great, it's not as useful as they thought.
In terms of, if you are doing an ad hoc persona exercise and you're doing it with the poobahs in the organization who really do have a say over the definition of the business goals and brand goals and are able to express them in terms of these ad hoc personas, you're not really asking for feedback once you present them, because they're coming from the top down and they've got this buy-in already.
However, if you're using them to try to mirror back to execs what you think you hear them saying - the trick that I use is, "Well, let's imagine this person," like you said, Ahmed, "who is someone who is a program manager and has to manage this incredibly remote team all over the world and somehow has to have our product to do that. Isn't it true that if we don't satisfy him, we failed? I mean, isn't he right smack-dab in the middle of the people that we're trying to help?"
And people will say, "Yeah." So, it's not a matter of saying, "He's the most important." It's more like saying, "If we don't satisfy this dude, what are we doing?" Isn't that true?
Jared: Exactly. OK, that makes sense. Now, you brought up the idea of remote, so let's go down that road. Shannon asked, "Is this a technique that you can use in a remote environment? If you've got team members that are spread across the globe, can you use your ad hoc personas technique? Can you actually create the personas remotely?"
Tamara: It's tricky for me to answer that question because I rely so much on people proving to themselves that they're confused that it's difficult. But, you can use that mirroring technique. You can say, "Let's first get clarity on what we think the goals are and then let's get them signed off on or let's get them changed. Then let's work together on some goal statements and just try to put together some quick personas, some ad hoc personas, that we feel will meet our needs."
You just have to try it, I think, and go from the perspective that you're probably not going to nail it at first, but what you can nail at first is sort of those "Doy!" personas. [laughs] Like Ahmed - if we don't satisfy him, what are we doing?
So, I don't have a great answer for that. I really don't, because people think they're hiring me to do personas, but what they're really getting - the symptom, the cause of the problem is that there is unrecognized confusion or disagreement among the executive staff and, therefore, everyone else is confused as well.
Jared: There are advantages to having everybody in the same room to do this.
Tamara: Oh, it's huge. Huge, huge, huge.
Jared: We've been getting this question. Every time we talk about user experience techniques, the question comes up: Can you do this remotely? Can you have a team where each member of the team is spread in a different city and a different time zone and somehow pull this off? And the answer seems to be coming back - no matter what the technique is, not really as well - that there really is something to the collaborative activity that you get when everybody's in one room.
Tamara: Yeah, absolutely. I think there's a very interesting question about doing some of these user-centered design techniques remotely. Because to me, I always think of the Maslow's pyramid thing, which has to do with - you can't really worry about shelter until you've got food, and you can't worry about a job until you've got shelter. And I think that with great user-centered design, you can't even get started until you have a shared focus on who you're trying to satisfy and with what.
And that shared focus depends on a shared language. It depends on clear goals. The more I work in this industry the more I just see proof of that again and again and again. So, this shared focus, this shared language, this shared understanding of actual business goals is necessary - not sufficient, but necessary - to move on and do other methods in user-centered design. And I don't know great ways to get that clarity without doing it in person. It's hard enough to figure out how to do it in person. So, I don't have great answers on that.
Jared: Right. It's a big struggle for the folks who are working remotely, because it really does present that.
Maybe as time goes on, we'll learn how to do this stuff better, and the online tools will develop such that we can do the same things. But, I think that lack of simultaneously getting everybody's body language and nonverbal communication that happens when you're in meetings, particularly when you've got stakeholders and executives and all sorts of people there, there's something about all gathering around the table or all gathering around the wall and putting the stickies up that changes the dynamic of all that power, in a way that you can't do that online in any easy way.
Tamara: And sometimes you can't do it all, because it's a political nightmare if you're in an organization.
If I'm remote, what I think about is the old empathic listening technique, where you repeat back to somebody what you think you hear them saying. And I would use my goal documents, or these ad hoc, quick-sketch personas to mirror back what I think I'm hearing and ask if I'm right. You will get some good results from that. It's not the same as having everybody in the same room, but if you can get clear on prioritized, ad hoc personas, e.g., "If we don't make these three people happy, we've failed," that's going to help a lot of people.
Jared: Yeah. So, once you've got them developed, it's going to help a lot. But, getting them developed, that's still sort of an in-person thing.
Tamara: Well, you're going to get the right neighborhood if you're developing something for highly technical program managers. And the value of having a name to refer to is so high that the risk of having it be the wrong persona is vastly outweighed.
Jared: So now, a lot of what we've talked about has been for designing for products. But, Sue wanted to know, "Could you use this approach for services. If you were designing a customer experience for an organization that produces services, could you use the same technique?"
Tamara: Sure. Why not? I mean, you're delivering a product. It's an experiential product, or it's an ongoing product because it's a service, but you're still trying to figure out how to make this service appealing to and satisfying to a specific set of people. And there's absolutely no reason that I can think of that you couldn't try it and get value from it.
Jared: So, in the seminar, you showed this wonderful matrix, where, basically, you had the different features in the product and you assigned what scores a given persona would give that feature, so you could decide how important it was. And Jonathan wanted to know, "If you don't have actual data that you've gathered from real people to build these personas, how do you know what the scores should be?"
Tamara: That's a great question. None of these methods are flawless, nor should they be used by themselves, nor are they golden, as John Pruitt, my co-author, likes to say. It's just one thing you can try.
And if you have this gigantic pile of feature ideas, this can be one way to sort through them quickly and say, "Let's look at this from a different perspective. Now that we have these personas and now that we have these weights, which are themselves based on business objectives, let's quickly run through this list of 100 features and just see what perspective this tool gives us."
There's going to be all sorts of reasons that it doesn't work, like you need a feature that doesn't look so attractive, but you have to have it for competitive reasons or for marketing reasons or for legal reasons. And that's fine. This can just unclog that list, which has been sitting around for ages, in which one person has this huge favorite feature that they won't shut up about. It's just one more tool to try.
Jared: So, it seems to me that what we want to think about this as is sort of a first-cut approximation. Even though you don't have the best, most-researched data going into this, you do have a lot of experience that people within the organization are bringing from their talking to customers and going out and hawking the services and listening to support calls and all those types of things.
So, there is data there. It's just not as formally collected as you might get if you went out and did 15 home visits and took 100 pages of notes and analyzed transcripts and all that stuff.
Tamara: Exactly, and you can certainly do that.
What I find when I do this exercise is that there's some that are really obvious: "Oh yeah, everybody expects this," or "Wow, this is really a killer feature," or "You know what? She's really going to hate that because it's going to take up time that she doesn't have." And then there's a bunch of them where you just get completely stuck, and that's great information. Maybe it means that the feature isn't well-defined enough. Maybe it means that you do need to go out there and do some research. But, that's good information. Then you can go out there and do it.
Jared: Right. And you've now got management saying, "Hmm, we should research this more." When management says that, that's a good thing, because that's almost like permission.
Tamara: [laughs] That's almost permission. That's right. That's right.
Jared: A few weeks ago, we were doing a virtual seminar on prototyping. And Todd Zaki Warfel was doing a fabulous virtual seminar. He did a fabulous job. And he got a question that we get a lot for these things, which was, "This seems to work for brand-new products, but does it work for a product that's been ongoing and evolving?"
And I was amused because, in your session, Lee asked the opposite question. She said, "I think your method works great for evolving products, but does it work for brand-new ventures where you don't have the data?" What do you think about that?
Tamara: Oh, I think it absolutely does. In fact, when I work with companies, I work with companies that are tending to behave like startups, either because they are a startup or because they're a big company that realizes that something has gone horribly wrong [laughs] with one of their products.
And so, you mentioned earlier that this is a good thing to do in the very, very beginning. And it absolutely is, because, essentially, what a new product is is some idea for satisfying some group of people with some fabulous new thingy, or service or whatever. Getting from that sort of vision and business plan to an actionable set of features, or everybody now has to actually build something before they can get funding, figuring out what that should be should be a user-centered process.
Jared: It's interesting to me that nobody starts a project saying, "Well, we're going to build a product, and we're going to assemble a team. But we don't know what the product is, and we don't know who the customer is, and we don't know what they're going to build." There's always some constraints.
I mean, if you're in the phone industry, you're going to build something that has to do with phones. There's something that you're bringing to the table that starts with that. And typically, you're going to go with either new customers or existing customers. But, in either case, you know who the customers are, or you know who they're not, and you can narrow it down. So, there really isn't anything that is so brand-brand-new that you know nothing about anything.
Tamara: Yeah. But, you know what? What happens next? Now you start hitting technical obstacles, or you go through build-versus-buy decision-making. And you get into all the practicalities of it, and you start to slide away from remembering what you were doing in the first place. Plus, you need a good way to make those decisions.
And so, you're going to build-versus-buy a shopping cart. Well, does Eileen really need something fancy in the cart, or is it fine just to send her through the templated cart? You know what? Eileen doesn't care if you can drag and drop into the cart. It's no big deal. It's not like she needs that fanciness there. So, let's put our effort somewhere else.
Jared: Makes perfect sense to me. So, we were working with a client a few months ago. It came out while we were working with them that they had 22 marketing segments that they had broken their customer base into. This was a large consumer-technology company. And they were labeled things like "young and hopeful" or "older athletics," really sort of wacky names, and they couldn't keep them straight. But, a lot of companies have these marketing segments that they build their marketing plans around and their advertising campaigns and all sorts of stuff.
Can personas align with those marketing segments, or is it something completely different, in your mind?
Tamara: They're not completely different, but the summary of the way I think about it is this. Marketing is about getting eyeballs to your product or your website or your service. So in that case, you have to know where those eyeballs live in normal life. The older athletics, those eyeballs are looking at, I don't know, magazines about yoga or whatever. And the young and hopefuls, where are their eyeballs? They're on TV, or they're on YouTube or whatever.
And that's how you decide where to put your message that's going to attract those eyeballs to the site. And those are differences that make a difference. If their eyeballs are on yoga today versus YouTube, it matters, to getting them there.
But, the differences that make a difference once they show up, that's what personas are all about. So, once those eyeballs show up, if you're introducing a brand-new product that enables you to exercise without knee pain, it could be that the young and hopefuls want to prevent injury and the older athletics want to deal with injuries they already have, but they're more similar than they are different. They're shopping for alternatives. They're wondering about medical benefits of these things. They're approaching exercise from an injury perspective.
Maybe it doesn't matter that they're from different market segments, because when they show up and you want to move them around the site, it's the same call to action. Maybe they have the same concerns.
It's a little tricky to think about, but you do have to think about: what do we want people to do? And does it matter if they're old or young? Not necessarily.
Jared: Absolutely. Yeah. We were working with a gaming company that said, "Well, our primary market are 18-to-22-year-old boys." And then we started to do research and we found 30-year-old women who were enjoying the games. It was like, should we just not talk to them? It turned out to be that the market segments that they had defined, while they might be helpful in pinpointing advertising or figuring out what TV shows to get product placements in, it wasn't helping us figure out what are the behaviors that we need to design for, from a design standpoint.
Tamara: That's right. And maybe the behaviors are different depending on if you've ever been to the site before versus you've bought several of the products and downloaded them. And that's a more interesting difference than how old you are, whether you're male or female, or whatever.
Jared: Yeah. So, it turned out that we met 35-year-old, avid-gaming women who basically exhibited the same behaviors as 19-year-old, avid-gaming boys. But, at the same time, we met 22-year-old guys who hardly gamed at all. So, their behavior was very different than those other groups, even though they were in the demographic, so to speak.
Tamara: Right. So, the personas might have been based on "I like to do a little bit of gaming every day to take a break," versus "I'm always looking for the latest game because I really want to get into it and solve it." And it could be that there's both 18-year-old males and 30-year-old females in both of those categories, or 24-year-old guys, or whatever.
Jared: Right. Yeah. And the differences that began to emerge were things like "I like to sit down and play the game for the whole weekend and then be done with it and never play it again," versus people who like to get on the system with five of their other buddies and play the same game over and over again, and it isn't so much about the actual game as it is just hanging out with their buddies in this virtual space.
Tamara: Exactly. And those may line up with demographic stuff, like maybe 18-year-old guys are more likely to want to hang out with their friends online, and 30-year-old women are more likely to just want to do a puzzle once in a while. And that's fine if they do line up. But, it's not necessarily true that different segments have different goals.
Jared: Right. Makes sense to me.
So, one last question here. Lately, I've been dealing with a lot of organizations that have tried to do a personas project in the past because they heard really awesome things about it. And they don't really know very much about it, so they go off and they do these massive projects where they try and define every possible person who would ever use the product or service, and then come up with these really glossy sheets of paper that have these funny descriptions of "Mary was a hippie in the '70s and has two children and drives a Hummer now and has a dog named Bart," and, somehow or other, try and do something with this.
And of course, after they've spent all these resources to do this, nothing comes of it, and now the idea of a persona is this, "Oh, we did that once, and it was a disaster. We're not going to do that again." How do you sell what you're talking about here with ad hoc personas into a project where they've been down that road and it was a complete failure?
Tamara: I can't tell you how many times I've heard this, which is part of what went into all of this thinking about this ad hoc persona process. Listen, you can't fight the bad taste that people have in their mouths about personas, and many of them do. And so always start tiny after that.
You could do your first little persona effort, again, trying to reflect back, at least get the goals nailed. But, maybe nobody has to know about these personas except you and your small team. And maybe you can go, after you've launched something or done something or come up with some great idea, and say, "We just decided to maybe try that technique again." But just do it on the cheap, do something small, and see if it actually does work for your team.
Jared: You think about this, right? A carpenter doesn't come blasting into the house when they're going to do the kitchen remodeling and say, "I'm going to use this hammer. That's what's going to make this kitchen remodeling great." Right? Personas are just a tool. They don't have to be expensive, and they don't have to be widely publicized, and you don't have to have wholesale adoption to make them work on just a small part of the project. They're just a tool in the toolkit.
Tamara: And they're not necessarily for everybody. Another important part of this is I like to ask the core team to identify the problems they're trying to solve with the personas. So, maybe everybody's confused about business goals, and they want to try to solve that. Maybe there's current language that just isn't helpful in making design decisions. But, maybe there are problems they are trying to solve that personas aren't the right tools for.
Jared: Yeah. That makes perfect sense. Well, Tamara, it's always wonderful to talk to you about this, and I'm really glad we spent the time today to do that.
Tamara: Oh, it was an honor to talk to you about this. And thanks so much. I had fun.
Jared: And everybody who's listening, if you want to hear the seminar, you can come to uie.com, click on "Virtual Seminars" and look for the "Power of Ad Hoc Personas: Truly Practical Methods to Get Your Organization on the Same Page" by Tamara Adlin, who is my favorite personas person in the whole wide world, and the author of the really awesome new book, "The Essential Persona Lifecycle," which will be in bookstores everywhere. Think of this as like the perfect Christmas gift. Give one to your mom, to your brother. They're going to be perfect.
Tamara: For heaven's sakes, don't do that.
Jared: OK. Tamara, thank you very much.
Tamara: Thanks, Jared.
Jared: And I want to thank our audience for listening today. And once again, thank you for encouraging our behavior. Take care.