Episode #272 Kim Goodwin - Using Scenarios to Solve Problems
Understanding is what user experience as a field hinges upon. After all if you don’t understand how users are interacting with your product or service, you don’t know what to design for. But how, as a team, do you come to that understanding? Telling the story of a user’s journey highlights areas where you’re right on point and where you’re missing the mark.
Kim Goodwin says that storytelling is the most natural form of human communication. She posits that if we’re trying to be as human as possible in the design process and come up with the most human solutions, why not use one of the most basic tools that we as humans have? The cognitive barrier to listening to and processing a story is relatively low. Being able to communicate that story is a key contributor to getting a team on the same page.
Using scenarios and personas you can craft customer journey maps to better gauge how and when people are using your product. Working through these scenarios, especially early on in the process can uncover valuable insights and allow you to iterate quickly to ensure you’re heading in the right direction.
Jared Spool: Hello there. You have dialed into yet another episode of the "Spoolcast." I am Jared Spool. I'm the guy in charge of these things, but today we have the real person in charge of all things Awesome UX. We have Miss Kim Goodwin, who is one my favoritest people in the world. This will be podcast number 751 with her and she is going to enlighten us about how we get scenarios to work in our organizations. That's because she is an expert on this and because of that, we have her teach a full day workshop at our "UI20 Conference" this year. She's always been a big draw and the audiences have always loved here. If you have not had the opportunity to take this workshop with her, then you have missed something awesome and you should fix that right away and you'll see why as we talk to her today. That conference is going to be in Boston on November 2nd through 4th. She does a full-day workshop on scenarios and designing with them. Kim, how are you?
Kim Goodwin: I'm well, Jared, especially after that fantastic introduction. How could I not feel pretty good?
Jared: That's how I feel. That's how I feel. I'm putting together this conference. Every year I go out and I find speakers who are talking about things that I'm most interested in. I invite them, and your stuff always ends up on the top of the list almost immediately. I'm putting them together, and I'm writing up the description of why I have each session. As I'm writing it up I keep finding myself writing the phrase "Get on the same page." We have Bruce McCarthy talking about production management, so it's like, "Get on the same page with your product manager." We have Jenn Lukas talking about creating a living style guide out of CSS. It's like, "Get on the same page with a living style guide." Nathan Curtis talking about design systems. "Get on the same page with your teams through a great design system." Of course, scenarios help us get on the same page. The thing is that I didn't do this on purpose. I crafted the conference in terms of the people I wanted to hear. It just occurred to me that everything I wanted to hear about was about getting people on the same page. This is because this is the thing that I deal with most when I'm talking to the companies I'm working with. I was wondering if you're seeing this, too. Are you talking to people a lot about "How do we get on the same page about what we're doing?"
Kim: Very much so, Jared. That's a huge focus for everybody working in this space right now. I think 20 years ago when your conference first started...
Jared: Yes, 20 years.
Kim: We were all trying to figure out what our profession was. We were trying to figure out the techniques for solving the design problems in the first place. Our message were just starting to come together and certainly drawing from other fields, like industrial design and HCI and other things. But I don't think we generally had coalesced a method. Where nowadays, I feel most practitioners have had some contact with pretty similar sets of methods in a pretty well understood way that we can solve problems. Now that that's done, everybody's focused on, "Wait, why are we still not getting stuff done?" Ultimately, it all comes down to aligning the organization around where you want to go. Some of that's about process. Some of that's about skills. Some of it's about culture, but it all comes down to alignment.
Jared: Yeah, that's exactly right. I'm thinking about the first UI conferences that we did. We had sessions every year about the basics of usability testing, for example, and the basics of what we would now call "Interaction design." Back then that wasn't what it was called, and the basics of these things. Now this year we have a session that is still usability testing and user research. But the way Erica Hall is going to deliver it, it's about coming to a shared understanding, getting to a common knowledge about it. It's the elements of that type of research that get everybody on that same page. I think you're right. We have moved past the basic tools. Yet, we're still struggling to produce great experiences all the way through. So, it isn't just having the tool in our hand that automatically makes us instantly producing a great UX, just like buying the most expensive blender does not make you a great cook. You have to know how to use those tools in a great way
Kim: Exactly. Alignment is honestly, not even just alignment within a product team, it's alignment across an organization and especially as a user experience now might be partly digital. It might be bricks and mortar retail. It might be on the phone. It might be a thing you get in the mail. All of that is wrapped up into the user experience. You have to get even more people on the same page. Now that I think about that, that's probably another reason why, just in the last few years, that need for cross-team, cross-silo, cross-functional focus is probably bigger than ever.
Jared: Yeah. In a lot of organizations it's like that old phrase about, "The future is here. It's just not evenly distributed." The knowledge of how to get to great designs is here, but it's not evenly distributed.
Kim: That's true. It's not even evenly distributed within an organization. Generally, I find that in a given organization there's one team that's maybe doing really sophisticated work. Where other parts of the organization, especially when they're internally focus groups like the IT group, often maybe lags behind the product group, because it wasn't that a customer facing driver for them, for example.
Jared: In this world where we're now putting together multi disciplinary teams, do you think that means that in a given team, there's going to be a distribution of knowledge of what it takes and just getting that entire team to have a shared understanding and being on the same page takes work? It doesn't just automatically happen.
Kim: Certainly, within that team you want a distribution of skill sets because that's why we're multi disciplinary in the first place. Where I find those teams often begin to struggle is because they don't have a sure understanding even of the problem they're trying to solve, they don't have a shared language or a shared perspective on what it is the solution needs to accomplish in the first place. It feels like requirements and even Agile user story, I think don't really make it clear for teams. So, in my experience the first step is to come together around a tool that helps everybody see the problem from the same angle.
Jared: You're absolutely right about that. Let's hone in on the role scenarios play there. It feels to me like they play a really critical role in helping that team and the parts of the organization that has to interface with that team, interact.
Kim: If I can rewind a little bit and look at something that you want to do, ideally is a precursor to scenarios, journey maps do a better job of aligning people around the problem, to prepare them to develop scenarios of the future solution. Some time ago when I first started teaching scenarios, which is probably more years than I care to count, I would find some people took to it naturally and others really struggled with the generative aspect of scenarios and didn't quite know where to go with them. When I started teaching journey mapping, which essentially takes your user research and lays it out in a timeline fashion. Imagine that you are outlining this person's encounter with your tools and with other tools in some way and then you're mapping that versus, "How do they feel about this? What are they trying to accomplish? What are they trying to learn at each stage of this journey?" That's a structure that starts to really open people's eyes around, "Oh, boy, this stage in our journey is really awful." Actually, we do OK here. People aren't too stressed about this. That's first to align the team around, "Where should we focus our energies?" because a whole user journey is usually quite large and touches probably every part of your product and maybe other people's products, too. That's a great starting point and it's a good jumping off point for generating a scenario that tells the future story of the product.
Jared: When putting the journey map together, when you're doing that, are people coming from the same place when you're doing that, or is this a tool that you gather around to synthesize where everybody on the team is coming from?
Kim: You could do it either way. In my experience journey map works best when you have people who have a shared base of user research, rather than just discredited assumptions and experiences. Ideally you pull together some qualitative research people have done and you start to map that out. In my experience actually, that journey mapping exercise tell people whether they're good or bad at qualitative research because you can't do a journey map that means it's a lousy interview. But if you want to use a journey map as a starting point when you don't have that shared context, that's not a bad thing. Because part of what it will probably reveal is that lack of shared context. You can say, "OK, if you all think we understand our users, let's sit down and try to do our journey map together." That's actually going to reveal the holes in the team's knowledge and probably reinforce that actually it is worth you going down and sitting down with at least a handful of users in their actual context.
Jared: Being able to get that journey map built, once you have it built, it feels to me that now it's a really useful tool to help people who weren't involved in that research to pick up and get up to speed quickly and tell those stories.
Kim: Yes. It's a way to make that tangible. It's a way to express a lot of what you saw in those interviews in a pretty compact and digestible way. Then from that journey map you can start to get people thinking, "All right. Now let's imagine what that future experience is like." You begin to tell the story of if you had a magic black box that you could put in people's hands, what would happen? How would that story unfold differently? That's where you start to build, Jared, understanding about the solution. In a universe where you just have a bullet list of requirements or you have some acceptance criteria detailed in an Agile user story, which to my mind is not really a story per se.
Jared: You mean as an administrator, "I want to be able to log in" is not a story of my experience? [laughs]
Kim: Yeah, because there's really no plot or character in that, is there?
Jared: No, no. You can see the authentication system as a villain. [laughs]
Kim: You want to log in, Jared? Tell me all about that. What an exciting story. That's the thing. Agile user stories are good scoping tools. They're effective communication tools in many ways, but stories they're really not whereas a scenario says, "Imagine if we had the magic new product or the improved functionality. Here's how that would unfold." That starts to imply a whole host of requirements. It's a generative tool that helps product managers understand requirements, helps designers influence those requirements, and helps all the engineers start to get a picture of, "Oh, that's going to have to connect to this, and we're going to have to build it this way." It starts to take shape very quickly that way when you've got a story to tell.
Jared: This idea of being able to tell stories seems to be a key piece of this "Getting people on the same page." Do you think this goes back to a basic human trait of just being storytellers? Are we just taking advantage of what thousands of years of evolution and sitting around the camp fire teaching our children how to be good humans has all been about and we're just moving that into the process?
Kim: Yes, I do. I think storytelling has to be our most natural form of communication as humans. It's something that we all learn to do at an early age. The beauty in that is through storytelling. As children we're generative. We're creative, which I think is a very critical part of the design process because if we can't be imaginative it's hard to come up with a future state that's going to be more desirable. We absorb stories very well. There's very little cognitive barrier to absorbing a story. We don't have to process a whole lot because everybody from Dr. Seuss and the star-bellied sneeches trained us to absorb the moral of the story without really having to think about it much.
Jared: It's interesting that we can use that as our touchstone in terms of helping people get on the same page. One of the things that I've always been attracted to your approach to scenarios about is how it's very much a human storytelling process. I guess going from the journey maps to the scenarios is really just a story-translation process. We've got this journey. We now have the scenario of what it is today, and we can come up with an aspirational scenario of what we could do. What's neat is in any given story what I learned about storytelling is it's not just the details you include. It's also the details you leave out. Scenarios are interesting because of what we don't say explicitly in them.
Kim: Yes. First I think that we're trying to be as human as possible in the design process, so we come up with the most human solutions. Why not turn to those tools that help us think in that form? You're right that we do leave certain things out. What I see often when people use cases or more formal structured tools is they'll start talking about how we hit this database table or this server does something or this part of the system behaves in this way. Who cares?
Jared: Or we sell more cookies or we sell more hotel rooms.
Kim: Right. Who cares? Whereas if we focus on what does this particular human being that we're envisioning, whether that's a persona or some real user we interviewed that we're using as a center point of our story, when we think about that and we just describe what they experience -- what do they see and encounter -- it doesn't matter how the back end does it. It doesn't matter if we buy that capability and plug it in. It doesn't matter if that's built using OAuth. Whatever technology doesn't matter because we're just getting at the gist of it. That helps keep requirements at the right level because I see a lot of teams that will do requirements that are actually lists of solutions instead of lists of problems that must be solved. The scenario focuses on, "This is the behavior we want to enable." Then from there we can figure out, "Oh. Well, there are three ways we might enable that. Which is the best?"
Jared: That's really interesting because that's very similar to something that...when I was talking to Bruce McCarthy about his workshop, which is going to be on "How can user-experience people work with product managers effectively," we got on the subject of something that separates a really good product manager from folks who are trying but don't quite get there. One of the things that separates is that the people who are trying go down that requirements route that you just talked about, but the people who are really good at being a product manager back away from the requirements. He has a word he calls themes. Themes are the overarching problem that we are trying to solve, but we're not going to make a list of requirements that are the solution. We're going to talk about that we need to solve this problem. Maybe the solution that comes to mind first is the one we'll take, but maybe there's a better solution. We want to leave ourselves open to that. When we talk about what the roadmap will be for the next three releases, we're not going to talk about specific functionality and features. We're going to talk about the themes we're going to tackle in each stop on the road map. It feels to me that pairing scenarios up with those themes would make them more human, more accessible to everybody, and more clear that this is the problem we're going to solve when we get to that part in the road map, but we don't necessarily know today what the right feature is. We're not going to commit to it. We're going to commit to solving the problem.
Kim: Yes. Better yet, Jared, in an Agile world where a lot of people are focused on what they're doing in the next one or two sprints...
Jared: People use Agile?
Kim: They use AgileFall or something of that nature...
Jared: Yes. [laughs] They use something.
Kim: ...but they call it Agile.
Jared: They call it Agile, right. OK.
Kim: Don't call it anything but Agile. In a world where people tend to be focused on the short term and the every chunkable functionality, what a scenario does when you attach it to one of those themes or whatever you want to call it is the first pass at a scenario is deliberately timeline agnostic. What I mean by that is it's not going to focus on, "What's the version one?" A scenario initially says, "What do we really want that solution to be?" Then we're going to pair that scenario with some sketches -- fast, cheap, low-fidelity -- but make it clear what we're envisioning for the solution. Speaking of getting people on the same page, nothing beats a sketch paired with a scenario to do that. From there you say, "OK, we all agree that this is the thing we're aiming at. Hmm, how long is it going to take us to get there or to get 80 percent of the way there?" because maybe from a product management point of view that last 20 percent isn't worth it. Even so, in order to get there, we're going to maybe come up with some interim sketches and figure out, "All right. Well, maybe this is a two-sprint project. Maybe this is a big, ambitious thing we're going to have to work toward over the course of the next year." That initial fast, cheap scenario puts all of the subsequent user stories into context, so that everybody knows, "Ah, this is about enabling that stuff that we're going to have fully implemented six months from now."
Jared: That's fascinating. I have this image of a designer standing in front of a wall with a whole bunch of sketches. They're actually play-acting the scenario as they talk about each sketch and walk through each sketch. The scenario...it's like those Bible stories that we all know the basic plot to, yet we tell them over and over again, the Passover story, the Easter story, Muhammad going to the mountain, or whatever the story is, Luke discovering R2D2 and taking it Obi-Wan Kenobi, all those religious stories. We all know the basic story and we can tell that story over, and over, and over again, but now we're using the sketches almost as props for how that journey will happen going from here out.
Kim: Scenarios can operate at a lot of different levels. You can do very low-level scenarios that are about iterating that thing in front of you that you're going to ship in a couple weeks. Scenarios also operate very well at the medium- to long-term vision level. I think you and I both have found in our work that organizations that have a crisp longer-term vision of, "What is the thing we want to build?" and it's not just a bullet point in a mission statement, but some concrete visualization of that thing, are more able to execute on that. Scenarios really help you with that. The best example of that I found is one that kind of stole from you. I use it in my workshops from time to time, which is the "Apple Knowledge Navigator" video. What was it, 30 years ago? Apple put together a kind of hokey video that includes Siri, except Siri looks like Bill Nye the Science Guy. It includes a clunky version of the iPad. It includes screen sharing and a whole bunch of other stuff that honestly has only shown up in the last 5 to 10 years. They've known for a long time roughly where they were going, and that's probably been a big part of why they've been able to execute.
Jared: Did you know that that video was part of a set?
Kim: No, I'd love to see the other one.
Jared: The only other one I've been able to find is a version of it that involved a digital camera. Again, this was years before anybody had digital cameras. It was 1987, and I don't think the first digital cameras showed up...Apple had one of the first digital cameras in the mid-'90s, like '94. Then the Kodak digital cameras came out right after that. All those were done by Hugh Dubberly. As far as we know, there were four done. Two of them have survived, and the other two, nobody seems to have any original footage of.
Kim: Definitely, for the folks on the podcast, I think that video is worth Googling and I'll probably drag it out in my workshop.
Jared: Yeah, "Apple Knowledge Navigator" is how you find it.
Kim: It's a great example of how putting it in the form of a story and illustrating it in some concrete way makes a huge difference in people's ability to see, "Ah, that's where we're going." Every time a team that I work with is able to start doing that, when you have a story and you have some sketches to go along with it, it really reduces the confusion and the swirl about what a requirement means. If you have a requirement that's just a bullet point, you can spin back and forth about what that means and whether the requirement's been met for months.
Jared: It's such a powerful way to get everybody talking about solving the same problems. It's still surprising to me that we have to re-learn this lesson over and over again.
Kim: If I could wave my magic wand and make design schools better at one thing, it would be at helping people ask the right questions and better define the problem. I really think that's the thing that many teams struggle with the most.
Jared: It's funny you say that. I do have a magic wand over a design school, and the conversations that we've been having at Center Centre, as we've been designing the curriculum, is just that. It's trying to push the emphasis less on finished product, and more on the process that got you there, which means you have to be able to tell the stories of why you did what you did and how you did what you did.
Kim: That's actually very important in getting people on the same page. As a designer, you can come up with, whether it's a crude sketch or a beautifully polished artifact...if you say, "Ta-dah! Here's the solution," you're going to get all kinds of pushback because people don't know how you got there. One of the great things about this progression from user research, to journey maps, to scenarios, to story board, to finished sketches is, "Wow, you can see how that evolved from the previous steps." People can follow you there, even if they aren't folks who can immediately look at a sketch and grasp, "Oh, yeah, that's the solution." When you show them the logic behind it, what that says is, "Oh, this isn't the designer just coming up with something out of thin air. There's a reasoning behind this and there's actually an argument for why this design is good." Of course, you want to do usability testing and other things to help you make sure that you're on the right track. But, in terms of selling that initial solution, you have a path that got you there that other people can see.
Jared: I sit through meetings where someone in a client is presenting a design they've come up with. They just launch into the screens, say, "Well, this is the home page, and this is the this page, and this is the that page." They don't talk about the scenario. More importantly, they don't talk about how they got to this design from the journey map or from the sketches. The audience is left to reverse engineer that in their head. Of course, they all do it differently. Then, there's all this conversation that happens around what they think the path was that got them there that turns out not to match. All of this is sort of lost. It's a struggle for a lot of folks. The best representations I've ever been with, before we saw the design, there was this statement of, "The research taught us this, and so we learned that the customers are trying to get to this result, but right now they get stuck here and here." It only takes a minute to say that, but they go back to that and make sure that everybody's on the same page. Then they say, "And then we tried a bunch of designs." In many cases, in the best of presentations I've even seen, they actually show some of the designs they threw out and talk a little bit about, "Well, we first tried this, because it seemed like the obvious thing. But then we realized it didn't work for this case or it didn't work for this reason. "And so we then evolved it and we got to this thing, and now here's the design we ended up with. And let's go back to that scenario. The user's going to start by telling us what they need, and then they're going to click on this, and that's because we want to be able to give them the right information," and then boom, all the way through.
Kim: In addition to that, an effective presentation is specific about which user. Every product in the world has more than one user. Regardless of whether you are a fan of personas or not, you want to be specific about, "Look, we're talking about users like this kind of person or that kind of person, and this is the one we're focused on right now." When people inevitably say, "Oh, well why didn't you design it this way?" or, "I think it should have this feature," or, "This whiz-bang button, that's my pet peeve as a stakeholder," you can say, "Ah, yes, but help me understand when this persona or this kind of user would do that, because they actually don't care." That way, you can take it out of the context of you, the designer, have a different opinion form the CEO -- which is an argument you're always going to lose -- to you, somebody with access to information about user behavior, can bring the conversation onto some neutral ground so everybody sees, "OK, yeah. We're using the same evaluation criteria here." That tends to make those conversations go so much better.
Jared: It's interesting. While you were saying that, I was just thinking. Twenty years ago, when we started this conference, the conversation was all about personas. We talked about personas. Then scenarios were sort of this thing that dangled off the persona. It's interesting now that the conversation is all about scenarios. When necessary, we bring the persona in to talk specifics about the users. As I thought that through while you were talking, it occurred to me that, to this day, personas are still a little controversial. There are still people who stand up and, for whatever reason, say, "Personas are a dumb idea. We create stupid personas, then we design for them, and we create bad designs." No one ever says anything like that about scenarios. I have yet to see anybody say, "Oh, we should never use scenarios when we design." [laughs]
Kim: It's funny because, to me, the personas and scenarios are intertwined. If, for some reason, you're allergic to personas, I think you can do something similar by picking an individual from your research who seemed to represent a behavior pattern. Either way, you really need to do the analysis about the behavior patterns, whether you give them fictitious names and faces or not. There's a lot of resistance to personas out there, mostly because people get them wrong. If people have had an experience with badly done, so-called personas, it tends to sour them on the tool. You get people who over-do the fiction part, who just make stuff up and don't really use behavior patterns based on research. Or, they focus on the creative writing aspect and worry about what the dog's name is and everything else. Who cares?
Jared: The dog and the Hummer.
Kim: Yeah. The essence of the persona is the behavior and the goals. If 95 percent of your persona details are not drawn from the research, then, yeah, you're doing yourself a real dis-service.
Jared: Have I ever told you my favorite dog and Hummer story?
Kim: Oh, no. Please do.
Jared: One of the red flags that I see in personas is when I get a persona description that's got some clip art person, almost always white. [laughs]
Kim: And smiling. Don't forget smiling.
Jared: Yup, smiling person, happy customer. They describe this thing in three paragraphs. They describe who this customer is, but there's at least two sentences that describe their pets and what they drive.
Kim: Because somebody saw that on a checklist somewhere and decided it mattered.
Jared: It makes it personal, right? We have the CEO, and he's got a greyhound and drives a Hummer. We've got the mom and she drives a Mini Cooper and she has an Irish setter, and they say what the name is, too, "The Irish setter's name is Butch and the Greyhound's name is Killer." A client says, "Hey, we've had another consulting firm. We worked with them to create a set of personas. Do you want to review them?" I said, "Yeah! I'd love to." Sure enough, first persona I read, there's a dog and a Hummer. They're both right there, and I'm like, "Huh. OK." This was a firm I had a lot of respect for, so I'm like, "Wow, I can't believe they went down that road." Then, as I got to learn more about the project, it turns out that the project was for the Home and Garden Television Network HGTV. The thing that these personas were for was a project search engine. The project search engine would help you find the best plans and recipes for home improvement projects.
Kim: So your Hummer is relevant.
Jared: Here is the deal. After doing their research, one of the things they found, and this surfaced in the research, was that if you're doing do-it-yourself home improvement projects, the car you have actually dictates some of the materials you can cart back and forth. People who have pets have special needs with regards to pet-safe materials. If you're re-doing the bathroom floor, what happens if the dog runs into the work, as it's being done, and gets into the grout or the chemicals as the flooring? Is it going to be a safe environment? They were trying to incorporate in the personas the fact that some people had pets, and some people and big cars and some people have small cars. If you drive a Mini Cooper, it's a different materials supply than if you have a pick-up truck.
Kim: Some of these biographic details in personas are totally legit. They're meant to reinforce certain things. For example, if I tell you, "This persona shops at Walmart and that persona shops at Nordstrom," that's going to reinforce certain characteristics about those personas, and that's totally legitimate.
Jared: The rule of thumb, I've sort of come to this, and you can tell me if you have a similar one, "Can I point to a design decision that would be effected by that sentence in that persona?"
Jared: If I can talk about, "Well, people with small cars will need certain types of projects than people with large cars, with huge payload capacity, will have different requirements for the projects. Then, boom, it should go in the persona. But, if I can't talk to a specific design element from day one, then maybe we should leave it out. Does that work for you?
Kim: Yeah. That's a fair criterion. One thing you have to be a little bit careful about is it's not always purely interaction design decisions. Sometimes, it's a visual design decision or a copy tone decision. Sometimes it's about the emotional aspect of the design that part of the persona speaks to. It's not purely functional stuff, too. If you're just telling me, "It's the dog, Henry. They went to college here and they drive this car," because you think in some formulaic way that should be part of a persona, no. All that's going to do is undermine the credibility of the tool and make your team roll their eyes and go, "What is this fictitious crap that the design team is getting paid to make?"
Jared: Again, if you can't tell the story of how this came from the research and how it makes a difference in the design, it gets in your way.
Jared: Wow. I always learn stuff when I talk to you. It's always a pleasure. I'm so excited that you're coming back this year for our 20th year to do this.
Kim: Twenty years, congratulations on that, by the way.
Jared: We're just going to keep doing it until we get it right.
Kim: All right. [laughter] It's pretty darn close to right, if you ask me.
Jared: Thank you.
Kim: I keep coming back, because it's a really awesome event.
Jared: Thank you for that. We try really hard. We focus a lot on the design. It's part of what we do. If you are listening, if you've listened to all of this and you are just excited about learning more about how to make scenarios work for you and to tell the stories that will get your team successful, then you're going to want to go to Kim's full-day workshop at the UI20 conference -- the User Interface 20 conference. It's going to be in Boston, Massachusetts, November 2nd through 4th, and you want to sign up for Kim's session right away, because that's one of the ones that fills up pretty damn fast. To do that, you got to U-I-C-O-N-F, uiconf.com and look at all the great sessions we have. In particular, make sure you sign up for Kim's, because that one's going to be pretty damned good. Kim, thank you so much for talking with me today.
Kim: Always my pleasure Jared, thank you.
Jared: For all you who have been listening, thank you so much for giving us your attention. If you enjoy these podcasts, please take a moment, go the iTunes, click on the appropriate number of stars, leave us a comment. That really helps us a lot. Thanks for listening and thanks very much for encouraging our behavior. We'll talk to you next time. Take care.