Robust Personas Brian Usability Tools podcast episode 10: Robust Personas. Recorded at Christiansen: the studios of User Interface Engineering November 19, 2007. [music] Welcome. I'm Brian Christiansen, producer of UIE Podcasts. Each week, we'll be sharing tools for improving your site's user experience based on our research at User Interface Engineering. If you're interested in the topics we discuss in the podcast, sign up for our popular free newsletter UIE Tips. I'll have more details on how at the end of the podcast. And now, this week's episode. [music] Welcome back to another episode of the Usability Tools Podcast. This is Brian Christiansen sitting with Jared School. If you're a longtime listener, you may expect to hear Christine Profetti's voice. Jared, where in the world is Christine Profetti? Jared Spool: She is traveling somewhere in Europe right now. I heard recently that she was atop Mount Vesuvius at one point. Brian: Wow. Jared: I think she's touring the volcanoes of the world. Brian: What are we doing here? Jared: We're deep in something. Brian: [laughs] Here we are in beautiful North Andover. Anyhow, so, yesterday we had a virtual seminar regarding building robust personas. It was very successful; everybody seemed to enjoy it. We got a lot of great questions, and we're going to answer some of those that didn't get answered during that time. But we also want to make it so if you haven't heard the virtual seminar, and maybe you are considering purchasing access to the archive, we want to give you kind of an overview of what went on in that. Do you want to tell the audience a little bit? You know, we had 90 minutes. Can you boil it down to two, what we talked about in the seminar? Jared: Oh, yeah. Yeah. We laughed, we cried, it was better than "Cats". The seminar basically was called "Building Robust Personas in 30 Days Or Less". For those of you who haven't gotten into what personas are, personas are a way to basically capture the essence of who you're designing for by creating some characters that are based on research that you've done, taking those characters, and designing those individuals. Because it's much easier to design for someone you can relate to and talk to and think about than it is to design for someone who is just a collection of people. Designing for a group is much harder than designing for an individual. So personas is a tool for getting an individual created so that you can then design for them, and we talked about the process. It's basically a four-stage process. You go out, you do interviews in the first stage; interview real people to find out basically how they're approaching the problem space, and what they do today, and how they refer to things. And then you take that data and you analyze it by basically coming up with attributes that define the differences between the people and then you plot the individuals that you saw on the attributes. You then look for clusters of folks, and those clusters become the personas that you're going to create. And then you create an imaginary person who is just like the attributes that fall into the cluster, so maybe someone who is a finicky eater who doesn't like to go beyond the foods they always eat, doesn't experiment very much. Or it might be someone who's very much into trying new cuisines; those would be two different persona types. And then you take those personas, you give them names like Mary and Charlie, and then you start to use them as part of the development process and say things like, "Well, how would Mary do this?" or, "How would Charlie do it?" And it turns out that this technique works really, really well when you've created the personas nicely. It works really well to really hone the design and get a lot of those real details into the design process that you wouldn't normally get if you just treat things in the sort of generic, generalizations. Brian: And these are especially helpful for designing for a group that you may not be super-familiar with yourself. Jared: Well that's the whole point, right? If you are designing a system that's going to be used for nurses in the pediatric intensive care unit, it's really important that you be able to role-play what it's like to be that nurse. You're going to have to go out and do the research, you know, just like Dustin Hoffman goes out and studies the characters he's going to be playing. You go out, you study the people you're going to be designing for but then you create a character, and you sit in the role of that character and you actually go through the process. And because you've done the research, your behaviors will be accurate and you'll know, "Well, wait a second. As my character, English is my second language, I'm Hispanic, I grew up speaking Spanish, so I may not... but I'm trained in medicine, so I'm going to know all the medicine terms, but there may be just sort of standard English stuff that I have a little trouble with and I'm going to want to be able to work around that." Those types of details are things that you'd never, ever think of unless you go out and do the research. Brian: And it's beneficial to fictionalize these characters as opposed to design towards a real ICU nurse that you've met? Jared: Well, you can do it both ways, and I've seen it done both ways. And there's advantages and disadvantages to both. If you use a real ICU nurse, the problem is that you're always going to think about that nurse. Now if that nurse truly is representative of a lot of nurses, then that's fine. But if she's idiosyncratic in some ways, you're going to end up putting things in the design that are geared towards those idiosyncrasies that may not match directly. So the other approach which primarily has been promoted by the folks at Cooper, Alan Cooper and Kim Goodwyn and those guys; they argue that you fictionalize a character, but you fictionalize based on real people you saw. So the attributes that that fictionalized character will have will be a composite of what you saw in real life. So now, the fictional character, you know, it may be that one person that you saw always has to do things in a rush because the nature of their particular clinic is always very rushed. Another person is Hispanic, but they weren't in a rush. Another person deals a lot... because of the nature of their laboratory... deals a lot with premature babies and twins. And so, you're going to need to combine those various attributes to make a persona that is a single individual that has all those things, even though you saw it in three different people. And so... Brian: And that helps you filter out the idiosyncratic characteristics that you may not want to design for... Jared: Exactly. Brian: ...while getting all the important parts. Jared: Exactly. Exactly. So that's the entire idea, is to do that. At first when I started working with these I was more in the camp of using real people, because, after all, there's enough real people on the planet, why do we have to make up some? Brian: Right. Jared: But I really see the advantage of often using fictionalized characters to sort of smooth out the rough edges, as it were, and get a character that really is... a persona that really is designed to help you capture a group of people. And I think that that's very helpful. I think that's very helpful. And what you don't want to do is confuse them. You don't want to give that person the name of a real person, because then you're going to think of that real person. Brian: Right. Jared: You're going to picture them in your head... Brian: And then you're going to pull back the filter. Jared: Exactly, exactly. And you're going to miss out the things that person didn't do. Brian: Great. So, I have here collected some of the excellent questions that we got. Jared: We got like 70 or 80 of them. Brian: We really got a lot of great questions. Jared: Yeah. Brian: A lot of smart people attended our seminar, so... I have a few here that are particularly interesting. Jared: We only let smart people attend our seminar. Brian: Yes, there's a checkbox. "Are you a smart person?" Jared: That's right. The not-so-smart people, they go and attend other people's seminars. Brian: Absolutely. So, here are some of the highlights... the questions that didn't get answered during the session, and one that did get answered in the session but I think is worth mentioning on the podcast as well, so our friend Brad wants to know: "Are personas defined as part of a development project or should the UX team have team members dedicated to maintaining updated personas?" Jared: I think dedicated people to maintaining personas is overkill, frankly. And I'm not sure it would work because part of the process of the persona, see, the actual deliverable persona document that just, you know, is a two-page document that describes the person, has a picture of this person, lists out the attributes, there's little narrative stories that talk about their lives and the scenarios that they have... That document is not that important. I mean, you need it. But that's not what you're driving for. That's not the end result of a persona project. The end result of a persona project is, when you're sitting in a meeting and one of the developers goes, "But, what would Mary do in this instance?" Then, that conversation that follows, where everybody talks about that persona and walks through that design problem with that persona in mind, that's the end result. If you get to that point you've succeeded. For one thing, personas don't need much updating, per se. You do them, and we recommend that personas are done on a functional level. So you don't design a persona for an entire redesign of a website, you would design a persona for just some key functionality that you're working on right now, and focus on that. You actually want the personas... My recommendation, and what we've found works best amongst the teams we've researched, is you want the personas to be as low-level as possible because then you get to the real details, you get to the rich details. If you go too broad, then you get these various sort of sketchy things like, "Our persona loves fun things, " you know, and that's not helpful. It doesn't tell you anything. Brian: I personally don't like fun, so... Jared: [laughs] Well there you go. Brian: I would break that persona. Jared: I've noticed that about you, actually. That's probably we don't hang out. So, you're going to have these very detailed personas. They're going to be living for the duration of the project. When that functionality is done you're probably going to retire them. You can come back to them later if it turns out to be useful to do so, but most of the time, you won't. You're going to create new personas for the next one, borrowing liberally from the research you've already done. So what you'll see is that they don't require much updating, and if the team is... The more members of the development team that are involved in the creation and maintenance of these personas, the more likely those conversations are going to happen. So that's a key piece. Brian: Great. Jen asks, "Do you think that this process can be done in 30 days if you only have one person to do all the work? If not, how long would it take one person?"|. Jared: Yeah, so in the seminar, I talked about how it takes 30 calendar days, which is basically 22 work days. And even then, I suggested that... we were counting on them being on average 5-hour days. So that's... it's basically 25-hour weeks. So it's not a 40-hour work week by any stretch of the imagination because people have meetings and they have other stuff. I think you could have one person do it all. That wouldn't be hard to do. But I don't think you'd get decent results, and the reason is that the value of this type of work is when different people are going on the field visits, they're seeing different things from their own perspective, they come back and compare notes, they have conversations about that. When you're going through and identifying the attributes and creating the personas, it's the conversations that make it interesting. And while a single person can go out, do the research, and bring this back, unless that person's also doing the coding, I don't think the value is going to be there. I think it's going to be very hard for that one person to get what they learned communicated to the rest of the world, and I think that one person is going to miss a good part of what they saw because they don't have a second set of eyes to bounce things off of. So I think you want to do this on a team, a minimum of two. And, frankly, if they're people who are going to be making design decisions down the road, you want them involved. You want to get as many of them involved as possible. Brian: Great. Wen-Chi wanted to know how narrow of a functionality would you want to make a persona for? In other words, we've just mentioned that we don't want to necessarily use a persona to help for design of an entire site, but rather more of a focused part of that site. So how narrow can you go? Jared: It's not so much how narrow as how important something is, right? How important is this, that you get this right for some group of key users? Here's an example: eBay has a form on their site for sellers, people who post stuff for sale. If people can't post stuff for sale, nothing goes up, nothing gets sold, eBay doesn't make any money. So this turns out to be a very important piece of functionality. Now, only a small subset of the users of the site ever sell stuff. The vast majority of people buy stuff. There are far more buyers than there are sellers. But that seller functionality has to work. And there's probably dozens of different types of sellers, right? There are people who are just... they've just found something in the back of the garage that they want to get rid of. They have people who have their old baseball collection, which they had somebody appraise at thousands of dollars, and they're trying to decide if they want to sell it off in pieces, or they want to sell the whole thing, right? You've got people who make their living selling stuff on eBay. 68,000 people apparently make... Brian: A guy down the street from me actually has a storefront that says, "I'll sell your stuff on eBay." Jared: Well that's a different type of person, right? That's a person who sells other people's stuff. There are people who make their living just selling their own stuff on eBay. Brian: With a lot of stuff. [laughs] Jared: So those are different types of folks. So now you've got these different groups. You may decide that you're working on a feature that's only going to appeal to one or two of those groups. Let's say the home... cleaning out the garage person. Brian: OK. Jared: So you're putting in some feature that allows those people to show off the quality of it a little differently than other stuff, or add more pictures, or something. Who knows what it would be, right? So first, you focus on that. That's the scope of functionality, is this new feature to help enhance the thing. That's the level you want to be thinking of, is some key piece of feature that's going to make a difference, and if you get it right, you're going to see real business returns, and if you get it wrong, it's going to fall flat, you're not going to get there. At first, you're probably going to go broader than you probably should, but that's OK. You'll get a lot of folks, and you'll hone in, and you'll realize, "Oh my gosh, " there's a lot to this. As you get better at this, as you do more personas... Because keep in mind, you're going to keep doing these over and over. It's not a one-time thing; you're going to keep doing them. As you do more and more of them, you'll get better and you'll get more focused, and my guess is that the scope of the functionality will actually decrease. You'll go finer grain and finer grain as you do more of these. And because you're doing fine grain, they'll go very fast. You'll be able to go very quickly. Brian: Great. Andrea asks, "Do you develop scenarios for multiple personas that all fit one task to highlight differences, or is each persona accomplishing a different task?" Jared: Beats me. Brian: OK. Phillip asks... No. [laughs] Jared: [laughs] Absolutely. Scenarios and tasks are different things. The task is what the user actually does, so if we're talking about booking a reservation for an airplane trip, the task is, you know, choosing the flight, booking the reservation, putting in the credit card, getting the ticket, right? The scenario is a much bigger thing, right? Scenario would be: Your boss says, "Hey, you've got to go to Kansas City tomorrow and meet with this client; it's an emergency, they're having a crisis." Right? A different scenario would be your boss saying, "How would you like to go to this conference in Aruba, and take a couple extra days, bring the wife." OK? Those are completely different scenarios. They involve the same task, which is booking the reservation. Brian: But the context is very different. Jared: But the context is very different and the way someone approaches the task will be very different. Thinking about booking a flight with you and the kids and the wife is a very different process than an emergency trip for business that's going to be one day in and out. Brian: Different needs. Jared: Exactly. So to Andrew's question, you have personas, right? And those personas are each going to have several scenarios associated with them. And then you're going to figure out what tasks they need to accomplish to achieve the scenario for that persona. Brian: So you can use... So Bruce the Businessman could both have that emergency trip and that more leisurely, long trip... Jared: Absolutely. Brian: ... and you could use him in both of those. Jared: Absolutely. And two people could be booking the same flight to the same city at the same time but have completely different scenarios that they're working for, and so the site needs to be flexible for that. Little details like suggesting hotels... the type of hotel that you suggest is going to be very different for someone who's just staying overnight, going to get up at seven, go to his meeting, fly back home for dinner than someone who's going to be there all week and wants something with a view and has a nice pool for the kids and all sorts of other stuff. So the details that the site has to provide for those two travelers could be very different. Brian: Absolutely. Kind of along similar lines, Phillip asks, "How might personas supplement the Rational Unified Process, or RUP, concepts such as actors and use cases?" Now, I have to admit, even though I'm asking this question I don't really know what RUP is. Could you help me with that as well? Jared: So, RUP... Rational is a company that was purchased a few years back by IBM. But despite the fact that they were purchased by IBM they're a pretty cool group of people. [laughs] Brian: I'll tell them you said that. Jared: Yeah. [laughs] And they came up with these various processes for develop... Their claim to fame is that they come up with all these sort of tools and processes for building software better. Brian: OK. Jared: And there's a guy named Ivar Jakobson who came up with this idea of what are called use cases. Use cases are specific, basically, flows through an application that you document, and so they're like a task. If you think of a task as booking a reservation, the use case is actually to define what the user puts into each field... Brian: OK. Jared: ... and what options the user is going to want to choose. And so, if you think of this as a hierarchy, at the highest level you've got the scenario. Actually, even higher than that, you've got the goals of the user. And so the goal of the user is to go have fun with the family. The scenario is, we're going to book the vacation in Aruba. The task is going to be the actual act of logging into the site, finding an airplane, finding a hotel, thinking about a rental car, deciding on that. And then the use case is going to be specifically going to the field that says From, putting in Boston, going to the field that says To, putting this, checking the dates, saying, "I'm flexible on my dates, " checking that option. You know, hunting for price. It translates all that down. So now the use case you can use for... Developers can match the use case directly to the screens, and say... Brian: So when you're making forms, or something... Jared: Exactly. Exactly. So that's the whole idea is you've got this nice little hierarchy of design, and it all works together really nicely. And the notion of actors in RUP has to do with systems that multiple people are involved in, so for example if I'm doing a travel expense system, you have the employee who enters their expenses, and then you have the manager who approves the expenses, and then you have the purchasing person who says, yes, these follow corporate guidelines, then you have the payroll person who adds it into the weekly payroll. So you've got these different actors, each who've touched the data. And each of them have use cases associated with them. And so the RUP unified process basically makes sure you take all those different viewpoints into account so that all the exception cases and the edge cases are followed through. You know, what happens when you go over budget, who's the one who decides when you've gone under budget? You know. So the purchasing person says, "Oh wait a second, the department's gone over budget, " kicks it back to the manager, the manager now has to tell the employee... you know. There are all these different details, right? Brian: My head's spinning. [laughs] Jared: Yes. Welcome to the world of enterprise software. Brian: Absolutely. So, Grace wants to know, "Can you create personas based solely on survey results?" Jared: I mean, you can create personas based solely on cartoon characters, but I'm not sure that they're going to be useful, right? The key thing, when you're done at the end, the key thing is that you're having that conversation with the development team and someone says, "Well, what would Mary do?" and the answers that the team gets from that thing is based somewhat on reality. The problem with survey results is that surveys are so hard to collect data. I'll give you an example. We recently did a study; we're working with a client that is studying how people prepare meals. I can't really say much more than that about it, but we're going into people's kitchens; we're seeing how they cook. We're seeing what cookbooks they use, and how they experiment with food and how they do their shopping. We're building personas based on this. One of the things that took the team completely by surprise... We call the work we do "the science of the obvious", because once I say this, you're going to go, "Yeah, of course that's what it was, " but I've got to tell you, no one predicted this going into it. Basically, there are two different types of cooking. And they mean completely different things to people. One type of cooking is, you're preparing Thanksgiving meal. And you're thinking... Or better than Thanksgiving, you're going to have a big party coming up, right? The reason I say that is because you might go off and search for interesting recipes versus making the standard turkey and gravy and stuff that you always make, right? So you want to get some cool recipes; you want to do something that's really flashy; you want it to have great presentation. You're going to really cook, so you're going to do a lot of research before that one. The other type of cooking that people do was, basically, you're picking the daughter up from soccer practice, bringing her home at 5:30, the boy has to go to hockey practice at 7:30. You've got to get them fed, you've got to get the homework done, you've got to get the daughter into bed at a reasonable time, you know. So you've got this period of time where you've got to get a meal on the table. And that type of cooking is very different from the other type of cooking. And in fact, there were several people that we discovered that didn't even refer to that as cooking. That wasn't the word they used, that's just getting dinner on the table. Brian: So cooking... so if they were given a survey and asked about cooking... Jared: Exactly. Brian: ...they might even exclude that. Jared: Exactly, exactly. And that's the problem with surveys, is that you'd never find out that there's two types of cooking, or that when you use that term, people are taking... Brian: ... react to it differently. Jared: React to it very differently. And as a result, you don't know if people are answering the same questions you're asking. It's very, very hard to design a survey to get that type of information. It's much easier to get that type of information by going into the field. And yes, you can get far more responses from the survey, but you don't know what the responses mean. You and I were just looking at a survey a few minutes before the podcast started where we realized that one of the attendants had completely inverted the scales... Brian: Absolutely. Jared: ...and put down that they... It was a satisfaction survey, and they put down that they were highly dissatisfied for everything, and then their comments were how great it was. And it was clear that they had given ones when they should have given fives, and they completely misread the scale. Brian: And people do that; I mean I think I've done that. Jared: Absolutely. Absolutely, we see it all the time. So it turns out that you can't tell from your data what you're getting. And as a result, it's very, very hard to design it. Surveys also require that people be aware of things, and much of the stuff you get when you go out and do the field studies are things that the individuals themselves are not aware of. Like the distinction the way they talk about cooking, which one they're talking about. The people themselves probably don't realize that there are two types of cooking. Brian: Right. And this all dovetails a lot with a couple of questions we got about people who had very limited budgets or manpower or time who wanted to know if there was a way of doing this without the travel, without going and visiting people in person. If they could do it in tele-presence, or something to that effect. Jared: I mean, you can... Yes, doing a little bit of it is always better than doing a lot of it. And frankly, the visits are not the expensive part of this. It's the analyzing the data and building the scenarios. The visits take, if you do it on the schedule that we set out, take six days. Analyzing the data takes 10 days. So you're going to be spending far more analyzing. Now, if you don't do as many visits, you have less data to analyze. But now, the problem with any of this stuff is that the whole point of going out and doing this research is to make sure that you are not playing against the probabilities. You know, if you only talk to two people, the chance that, had you talked to a third person, that person would be radically different is pretty high. If you talk to six people, the chance that the seventh person is different is going to be lower. If you talk to 10 people, the chance that the 11th person is different is going to be even lower... than somebody you've already seen before. So the more people you talk to, the more likely you're going to get decent results. If you can't talk to the people all at once, then do what you can do. Talking to someone is better than talking to no one. Talking to one pediatric ICU nurse is better than just guessing what pediatric ICU nurses do based on your experience of watching television shows. So absolutely, just do one. And if you can only do it through a webcam connection, then do that. But you know, the problem with the webcam connection is that it requires that the person sort of wave the camera around and show you the things that they thing you're going to be interested in, versus you discovering the things that you're going to be interested in. Those subtleties, those things that they don't know to show you, are not going to show up in that kind of environment. And so you're going to miss a lot of the real value. You could combine them, right? You could do some visits in person, some visits on the webcam. That may work. Brian: So for small teams that may have global audiences that they have to address, doing some of this stuff, you know, a virtual mode would be better than nothing, but certainly not as rich. Jared: All the evidence says that people are basically the same. For all we talk about individual differences, we're basically the same. You know, the human genome project, right? This project that maps out the chromosomes that is now the basis of modern pharmacological and medical research was all based on one guy. Brian: Right. Jared: The genes they mapped out was a 38-year-old guy from Buffalo, New York. And it turns out that when they mapped out his genes; they found out that he was 80 percent identical to the genes that they mapped out from a yeast cell. So it turns out we're not that different. We're all made of the same bones and meat and muscle... I guess muscle and meat are the same things, but we're made of... whatever it is. We're all made of the same stuff. I'm made a little bit of butterscotch, but other than that... I had it surgically implanted years ago. But we're all basically made of the same stuff. And so we all basically respond the same, we all basically do the same thing, so if you can only visit a handful of people, you're going to get enough detail from those people to build something useful. The more people you can see, if you have to spread it out across five projects to get it done, then you know, you go see two people now, you go see two people later, you combine the data, you pull it off. That's the way we do it. Brian: Great. All right. One last question comes from Wen-Chi again, some great questions. "How do ethnographic personas tie to other behavioral data such as a click-stream on the web? How do we synthesize these two sets of data?" Jared: Well, it's very hard to do because you don't know... When you have a click-stream, it's an anonymous thing. You don't know who that click-stream was from; you don't know what that click-stream tells you. I mean, if a user spends a lot of time on a single page, was it because they found that page really interesting, or because they'd stepped away from the machine or because they were really confused? You don't really know anything about it, so frankly we haven't found much use, particularly with personas but in general, we haven't found much use from click-stream data. There are a handful of things you can use the click-stream data for, such as figuring out what trigger words should be on the page by looking in the search portions of the click-stream and seeing what people were searching on and what page they're searching from and they're basically telling you what you should've had on that page. But other than that, there's really not much that you can do that makes that work. I wouldn't try to spend a lot of time combining the two. You can't tell which subsets of the click- streams you have fall into which personas purely by looking at their click behavior. Brian: It sounds like you might be able to get more data in a standard usability test and actually watch somebody click through... Jared: Exactly. Brian: ...than looking, like, at a log of that type of... Jared: That's right, that's right. That's right. Now, what you could do, and some tools will let you do this, is you could designate a panel of users and give them special access to the system and then the system will know when those users are using it. And if you've identified beforehand which personas those users are most like, you could then start to collect click-stream data for those users. And then, if you got really sophisticated in your analysis, you could see how many other people have similar patterns and infer, though it's a dangerous inference, that those people are in the same groups, and go from there. But... that's really sophisticated analysis, it's really tricky, and the odds that you're going to draw conclusions that are off the mark and are going to lead you down the wrong path of design are so strong that you'll just drive yourself insane. Brian: It sounds like an expensive route for so-so data. [laughs] Jared: It is, it is, it is. But you know, I was just thinking about Grace's question about survey results. Steve Moulder actually talks about this in his book "The Users Are Always Right", and he actually has a way of using survey results in the persona development process to enhance the data that you have. We were talking about... when she's questioned... it occurred to me that... So if you're really interested in that sort of thing, I highly recommend, it's called "The Users Are Always Right". It's a book about designing personas. It's a great book. There are a couple of good books about designing personas. That's one of them. Alan Cooper's got some good stuff in the third revision of "About Face". Of course the initial work on personas was first described in Alan Cooper's "The Inmates Are Running the Asylum". And then there's a book called "The Persona Life Cycle" by John Pruit and Tamara Adlin. Those are excellent books too, and we can put links to these books up on the web. Brian: Absolutely. Jared: So we'll put those in the show notes. But those are good resources for doing just that, so if you're really interested in this sort of, how do you use this other data and combining it, I would point you off to those things, because they do have something to say about that. But in general, now we're sort of at rocket scientist level stuff here where before when we were talking about this, we were at car mechanic mode. [laughs] You know, just sort of general stuff, so... Brian: Click and clack. Jared: Exactly, exactly. Brian: All right, well, great. Those were some great questions; I wanted to thank the audience for submitting those. If you have questions, of course, we always welcome your questions. You can add a comment to the blog post that you got this podcast from, or you can send us email directly at mailbag@uie.com, and we may even make a whole show out of your question if... Jared: We've done it before. Brian: We have done it before, and mark my words, we will do it again. Jared: We will. Brian: Yes. So, that concludes this week's episode, thanks for listening, and we'll see you next time. Thanks a lot, Jared. Jared: Take care. [music] Brian: We hope you've enjoyed this usability tools podcast. If you're interested in more of UIE's research, sign up for our free email newsletter. You can subscribe easily at uie.com. If you'd like to attend our next virtual seminar for free, just fill out our short podcasting survey at uie.com/audio. We give away free admission to one lucky respondent each week. We love hearing from you. Send us your comments at mailbag@uie.com. That's all for this week. Thanks for listening. Goodbye.