Episode #212 Kim Goodwin - Using Scenarios to Design Intuitive Experiences
Scenarios can represent the ideal picture of a user’s experience with a product or service because you can see how and when they’ll interact. However, a scenario is often missing the details of what's going on at this moment in time and that can be a sticking point. This is where the value of the journey map emerges.
Kim Goodwin has years of experience teaching teams how to create and work with personas and scenarios. She has found that journey maps often provide a good starting point for a scenario. Journey maps help outline what users are going through, tools they’re using, and experiences they have today. This perspective breaks down the siloed environment.
Using scenarios and journey maps builds consensus within the team early in the design process. Designers and engineers can have actual discussions rather than sifting through lengthy requirements documents. Through conducting field studies with actual users, you will more accurately determine what should actually be a requirement.
Jared Spool: Hello there. Glad you're joining us today. I have with me the fabulous Kim Goodwin, who we've talked to about, I think, exactly 145 times before, but she always has fabulous things to say. Kim is doing a workshop at the User Interface 18 Conference, which is going to be in Boston on October 21 through 23. She's giving a full-day workshop called "Using Scenarios to Design Intuitive Experiences." She's given this workshop for us before. It's always amongst the best-rated workshops of the event, and we're very happy she's coming back.
She's joining us from beautiful California today. Hello, Kim.
Kim Goodwin: Hi, Jared. How are you?
Jared: I am doing fabulous. It's great to have you here. I thought we could talk about some stuff that, when we were planning your workshop for this year, there were things that you brought up. It was really fascinating to me. One of them, you just made this offhand comment that people are going to learn how just asking a project manager for requirements is an ineffective way to figure out what to build in the release.
And yet, so many people do it this way. The first thing you do is your stakeholder meetings and you gather your requirements. You put them into a requirements document, which some people have actually given the official initials of PRD, for Product Requirements Document. It's this whole ritual that every project starts with. If you don't have your PRD, no wonder you're going to fail. But tell me, is the PRD the pamphlet of doom?
Kim: [laughs] Sometimes it's the pamphlet of doom. Sometimes it's the phone book of doom, because they're huge.
Jared: [laughs] That's true. Yeah! I've seen some of these things. They make a solid thump when you hit the table with them.
Kim: It's true. I hear a lot of designers saying, "Oh gosh, the requirements are hard to work with." Or, "They're not very good." Or, "We're still waiting for requirements." To which my response is, "Why the heck are you waiting for someone to hand you requirements, instead of driving them yourself?" That's not to say that UX owns the requirements. I don't think that we do. It's not to say that we have exclusive insight into all of them.
Because certainly on any project there are requirements that are not really about the users. Things like regulations we have to comply with or things we have to do to be viable in the marketplace, especially for selling to businesses, and not to consumers or direct to users.
But I think the assumption that we can know all the requirements before we start to actually imagine what the user experience is like is a little crazy to me. I see a lot of requirements that say, "The list box has to contain these 17 things." Really? Is there a list box? What screen is this even on? I don't know that yet. How do you know that?
Jared: Yeah, but isn't some of this to counter the problem that we had before we did these excessive PRD phone books, which was that you'd be three quarters of the way through the project and discover some major requirement that nobody had ever told you? Now you have to go back and redesign. But you can't go back and redesign because development has already started coding some of it. Part of it was to get rid of that churn.
Kim: Sure. But that churn happens anyway. I've never seen one of these things done up front, in great detail, that wasn't half thrown out by the time you actually even did the first design sketches. That's a very waterfall-y way to do things. There are some benefits to waterfall.
Jared: You get water.
Kim: There's that.
Kim: But I think there's a certain parallel process that takes place. While you have people looking at the business-y side of the requirements and the technical issues we have to handle, that can happen in parallel with our early user research and early sketches and scenarios. We can say, "From a user's point of view, here's what this thing has to deliver to be really awesome. Here's what this experience needs to be to really delight and engage users and to accomplish the work they need to do."
That should inform what the ultimate requirements are. In a healthy process, the UX team is essentially proposing requirements. We're saying, "Here's what we think it would take to be delightful and desirable as a solution." The engineers are saying, "Here's what we think it would take to make that." The product manager is saying, "How much of that design goodness can I actually make money building.
We're always, ideally, going to propose a bit more than really gets built. That's normal and healthy. I don't think we're the ones making the trade-offs. But using our tools and our particular insights, we can drive that process to be a lot faster and actually a lot more concrete. Because a requirement expressed in a sketch is a whole lot more clear to the engineering team than, "Item 13.2.12 must do blah, blah, blah."
Jared: These sketches, do you have a sense as to how we catalogue and keep them? Do we assemble them into the phone book? What tricks have you used for dealing with large numbers of sketches that are, in essence, the replacement for these lengthy requirement docs?
Kim: I really think it depends on the team and the environment. A lot of people will tell you, "This is the way you should do deliverables." I have to disagree with that. I think that may be the way you do deliverables in that company. But if you have a small, very nimble team of super-skilled developers who will sit next to you, you can be very informal with this stuff. If you have a huge, globally distributed team of not-so-skilled developers and a giant legacy product, you need to get a lot more formal about that management.
To my mind, the way that we manage that is mostly about, "How is this engineering team used to working?" That's fine. You feed it into the processes that are effective for them. But you don't necessarily let that legacy process drive how we ideate.
Jared: That makes a lot of sense. Because some of these organizations, everything has to go through this workflow process of getting signed off, people reviewing all that stuff. If you can get everybody in one room and they can sign off at the same time and say, "Yeah, this is great. This is exactly what we want." That's a very different thing than if I have to send this document over to legal to review and then we have to send it over to compliance and then we have to send it over to the product managers.
Then marketing has their say. Of course, the CEOs going to come in and tell you that it should work the way the thing his wife likes.
Kim: Yeah, absolutely. You just said something that I think is very key, Jared, which is getting everybody in the room at the same time. Whether that's a virtual room or a real one. If you have early sketches, the minute you feel like you've got a concept that's hanging together, you want to get all those important constituents in the room at the same time. Just for a sketch review. I had one with the team just the other day.
The marketing team has to launch the thing and the engineers have to figure out how to build it. The product manager has to figure out, does it fit in the budget? We just pulled all those constituents together in the same room and said, "Here's what we're thinking. Here's where we're headed." A couple of people contributed good ideas that improved the design. A couple of people had questions about, "How are we going to do this?"
I think we came to everybody headed in the right direction. Now, from there, everybody knows exactly what they need to do to get this thing out the door.
Jared: Cool. I've got another question for you that came up when we were talking. Everybody is talking about these journey map things. When I imagine journey maps, most of the time the ones I see are this timeline that shows the experience of a particular user. Sometimes we aggregate users across them. But the idea is that they show a continuous journey of the person finding out about your service and then coming to your service and trying it the first time.
Or maybe it's the journey of what it's like to create a new account. Maybe it's the journey of producing some end-of-year report. Or whatever the activity is. It's usually on a scale that measures some sort of delight to frustration, so that you can quickly visualize these things. They started popping up a couple years ago and now everybody's talking about that. Are you seeing that?
Kim: Absolutely. I've been using journey maps a ton, myself. I think they have a lot of different uses. They're great teaching tools. They're great team collaboration tools. They're great synthesis tools from your research. We can talk about any of those aspects if you want to. But I think they have at least three of four great uses.
Jared: I'm curious how they play into the work you've been doing with scenarios.
Kim: What's helpful about journey maps in scenarios are a couple things. If you think about the journey map as the expression of what's happening today, it's a document of some sort, a diagram, a sketch, a table, whatever you want to do, that says, "Here's what people are going through today. Here's how they feel about what they're going through. Here's what's driving them crazy about what they're going through. Here are all the tools they're using, the people they're talking to, the decisions they're making along the way."
It really helps you understand, "Oh, what people are going through is much more complex than this one web page that I think is my job to design today." It helps to break down that siloed perspective, which is one of the things that scenarios are also great for. People do not experience features. People do not experience the thing that your team builds as separate from their encounter with the rest of the organization.
They see it all as one piece. They expect to feel known across that whole journey. They expect to have information passed from one part of that journey to the other. They want it to be seamless.
Journey maps help you see where that isn't happening today. I found, as I've been teaching people to build scenarios over the years, that it used to be people would get kind of stuck at the invention stage of the scenario. If the scenario is the story of what the future of this experience will be, they'd kind of scratch their heads and say, "I don't know. What do I do?"
Whereas a journey map gives you a starting point. Because if you say, "All right. I'm going to clean up this part, and I'm going to improve these stages. What would a better version of that look like?" It's a perfect starting point for envisioning the future.
Jared: Where do you typically get the stuff that you put on your journey map? Is this just guess work among the team, or are you going out and meeting with real users and documenting what's really happening?
Kim: Well, you could start with guess work, but it's certainly not as effective as going out into the field and talking with real users. I think that ethnography is my favorite tool, by far, for this stuff. You can't really get the kind of depth and detail with a survey or a focus group.
But if you actually go out and watch somebody experience this and talk to them as they're experiencing it, or if it's a long, involved journey, you sort of have to do that retrospectively. Asking people for stories about their experience gets you pretty good specificity, and a story is also fairly accurate, as opposed to generalizations. You get a little bit less self-reporting error that way.
Then you aggregate, basically, journeys across people. Now, if you have multiple personas, you might need to do multiple journey maps, because often those journeys are a little bit different.
Jared: How are they different?
Kim: Well, it depends on the personas, right? Sometimes two personas will have a very similar journey, but will have different attitudes or experience levels that they bring to the journey. In other cases, the journey is quite different, because maybe they approach the problem with a different mental model.
In the case of a business application, they're working a different environment with different processes. If you have the case of people performing a task, they just have a different habit, or a different sequence they do things in.
Jared: Right. If I'm uploading photos from my vacation, one persona might upload a photo and share it, and then pick out another one from their collection, upload it, and photo. Whereas somebody else might batch upload every photo, and then go through and tweak them once their uploaded. You can talk about the journeys of each of those.
Kim: Right. You could do a journey map after every single user interview. That's very tedious and time consuming. I don't actually do that. However, I do find that for people who are new to doing ethnographies, a journey map, after their first few user interviews, is a great teaching tool.
Because if they try to fill out a journey map and realize, "Oh, I only got half that information," they will do a much better interview the next time. I use them as interview teaching tools, as well.
Jared: That's interesting. It's basically a way to validate that you collected all the right stuff.
Jared: That's a really neat use of it. Is a journey map a document you keep referring to over and over and over again? Or is it mostly one of these documents that, you do it, and you look at it for a bit and you go, "Aha! OK. That's what I've learned from it," and then you tend to put it away, and you don't go back to that particular document again?
Kim: Yeah. I would say it's a step along the way, not really a living document. Because the journey map is documenting the present. We don't really need to dwell on the present for very long. We just need to look at the present long enough to figure out what's wrong with it. What can we fix? What could we be much more delightful about?
Once you have essentially replaced the journey map of today with the wonderful, beautiful scenario of the future, you don't really need the journey map so much any more.
Jared: Cool. Have you found that there's a way to map the future versus the current, so that you can see the delta? Have you ever done that?
Kim: Sometimes I find it useful to, essentially, use the journey map as a starting point for a scenario. If you have a few rows in your journey map, one that that articulates what people do, another that shows how they feel about it. You could add another row another row at the bottom that's basically, "And how are we going to un-stuck this?" [laughs]
Then people just start filling that in and brainstorming around it. I think that that's a useful tool for people who aren't really used to working with scenarios, but I don't usually spend time doing the delta so much. If the team has worked with you along the way, they know the delta.
I guess the point of doing that more formally would be, if you're doing work for the team, which is generally not as successful, anyway. That's why I don't really do it.
Jared: Right. Say a little more about this working for the team thing.
Kim: Well, Jared, I've spent a lot of years as a consultant. Early in my consulting career, I thought, "All right. Well, if the clients just leave us alone to do our thing, that's so much easier, and everyone's happier." [laughs] I think a lot of people start their careers that way.
I'm certainly not the only one to have observed that the closer the team is to you, and the more involved they are, the more they believe it. The more they're able to extend your thinking, because it's their thinking. Right? They own the solution, and they help make the solution better.
Journey mapping is a thing that you can do with a team. If you have a bunch of people who've all gone out and done interviews, if you've interviewed similar enough people, you can do some aggregate journey mapping together. Then you can all see, "Oh, that's where the experience needs fixing," and, "Oh, this stage is pretty good." It becomes obvious to everybody at once what you need to do.
Jared: I think that's a really key point. We are often drawn...I have found, you go out on research, and you're drawn to all the things that were really sucky. You go, "Oh, my God. I can't believe they do it that way. I can't believe we've made it so painful for them." But what we then don't do is, we don't make a good record of all the things that we actually did well.
That the application is working smoothly, and it's pleasant and delightful in cases. We risk getting into trouble, because we've not recorded that, so we might actually change it and break something that works really well today. It would feel to me like journey maps are a way to sort of capture, "Hey, this is working. Don't break it!"
Kim: Absolutely. I think the other important thing about what you just said, Jared, is that if we, as UX teams only focus on the stuff that's screwed up, and never acknowledge the things that are working well, boy, do we become the negative Nancy on the team? Nobody wants to hang out with us, right?
Jared: I have never used the phrase, "negative Nancy."
Jared: [chuckles] Yeah. I think that's exactly right. You're the ones who break everything. We should be taking those parts of the journey, and finding the responsible party, and putting them on a little pedestal, and worshiping them a little bit for doing so awesome.
Kim: Yeah. Absolutely.
Jared: That brings me to this question that I have, because you also mentioned that scenarios help you go down the road to build innovative solutions. I'm curious, where do the scenarios come in? If we're trying to do something innovative, where do scenarios play into that?
Kim: I would say there are two answers to that, depending on how new the thing you're trying to do is. I think innovation can happen on a small level. You might be looking at a journey that's otherwise not a big revolution from where you were, but there might be one part of it where you think, "Wow. I could do this so categorically better." That, in itself, is an innovation.
You can build on that journey map to envision bits and pieces of an innovative future. If that journey today is something that happens in a very analog or disconnected way, then what you do with the scenario is you say, "OK. Let's assume that the constraints of today don't apply."
The fact that these systems, or these companies, or whatever, don't talk to each other, what would happen in the future if that actually weren't true? Scenarios are essentially using storytelling, which is a tool we're all very accustomed to using to create, to unlock our imaginations and say, "What if?"
That's really where scenarios start. We started our conversation, Jared, about with requirements and these great big PRDs. I don't know about you, but I can't imagine anything more creativity-killing that a requirements document. They're very analytical. The thought of writing out 20 or 200 pages of, "System shall do this. System may do this." Whatever.
That is so not creative. That's very reductionist. It's very analytical. That's actually the opposite of generative, which is what we need to be in the early phases of a product. What could we do?
Jared: That generative phase is something that I think a lot of teams that I've seen don't spend enough time doing, in my experience. Someone comes up with a solution, everybody just rallies around these solutions, and they just start refining it. They don't go down the road to ask the question, "Well, what other ways could we do it?"
They may come back to that solution as the best one. It may be, in fact, the ideal way to do it. Though I would think that, by just exploring other ways, you see the problem from different angles. There's probably some hybrid that you end up with.
Kim: Sometimes, "Hey! We came up with a pretty good idea. Let's just refine it." Sometimes that's fine, because you have some tight deadline, or it's a thing that's not really worth investing that much time in, and that's OK. But if you're really trying to reinvent the business, or you're trying to make something that's categorically better than what you've had before, you definitely need to build in some of that exploration time to say, "What are multiple ways we could do this?"
This is where scenarios alone are not your solution. You need to combine scenarios with, say, brainstorming. A scenario helps you figure out what's the general flow of what needs to happen. What questions do we need to answer for users along the way? What work are we going to take out of the system for users?
What they don't necessarily tell you is what that looks like. How exactly that happens. A scenario is solution-agnostic, in a way. Right? It doesn't specify the mechanism by which you accomplish things. A scenario, in a sense, defines the design problem very clearly, and then you want to sketch a few different approaches to, how could we accomplish this thing that's happening, in a scenario?
For example, in a scenario, I might say that your photos that you just took, using your photo example from earlier, you just took a bunch of vacation photos, and ta-dah! They're on your computer now. That could happen in any number of ways, some of which are easier. Some of which are more expensive to build. Some of which may be very competitive with what other people offer.
That's where you say, "All right. How could we do that?" Well, we could have you plug a cable into the camera. We could plug your card into the card reader that's built into the computer. We could do that wirelessly and build that into the camera. There's a few different ways we could do that.
That's where we engage in dialog with our engineering and product management peers to say, "We can envision a lot of ways to do this. Which one should we do, based on those trade-offs of desirability, viability, feasibility?"
Jared: Makes perfect sense to me. Wow! This stuff is always so interesting. I love talking to you about this.
Kim: It's always fun to talk about this stuff with you.
Jared: Yeah. Everybody, if you thought this was awesome, then you really need to sign up for Kim's full day workshop at UI18. It's going to be on Monday, October 21st. It's called, "Using Scenarios To Design Intuitive Experiences."
She's going to go into all of this in great detail. Everybody who took it last year just thought this was a rocking session, and people have been telling me that they've been applying it ever since. This is really something that you want to go to.
Kim, thank you so much for sharing your brilliance with us just yet one more time.
Kim: Thanks, Jared. Thanks for chatting with me and brightening my morning.
Jared: I want to thank our audience for taking the time and listening. I hope you go off and create awesome designs. We hope to see you at User Interface 18, or at one of our other events. If you have a moment, and you want to leave a review for this podcast on the iTunes, that would be awesome. We love to see those, and we read them, and it's really quite great.
We'll talk to you later. Thank you very much for encouraging our behavior. Talk to you soon. Take care.