Adam Churchill: Welcome, everyone, to another episode of the SpoolCast. Just a couple of weeks ago, Kim Goodwin joined us for a virtual seminar, "Designing with Scenarios: Putting Your Personas to Work."

Scenarios are the engine that we use to drive our design. A scenario tells us why our users need our design, what the users need the design to do, and how they need our design to do it. A great set of scenarios captures the essence of the design we're creating. Because scenarios are stories, they come to life for the team. They exploit a human desire to tell and to hear stories. Armed with well-thought-through scenarios, your team will be ready to produce innovative designs that will put a ding in the universe.

Kim's offered to come back and tackle some of the questions we didn't get to address in the seminar. Now, folks who didn't get to listen to the seminar, you can get at it at UIE's User Experience Training Library, which has over 60 recorded seminars on all aspects of user experience design from experts just like Kim Goodwin. Hey, Kim, welcome back!
Kim Goodwin: Hey, thanks, Adam.
Adam: Kim, for those who weren't listening in that day, can you give us an overview of your seminar?
Kim: Sure, I can give you the two minute version. I wanted to do a seminar on scenarios because, actually they're my favorite design tool in the whole world. They're super cheap. They're easy to do. And they're very compelling.

I think one of the things that's unique about interaction design is the element of time, right? Users engage with systems, or processes, or products. Over a period of time, things happen in sequence. And so, we can't just look statically at a screen on the whiteboard. We have to think through a sequence of events, and there are a number of tools out there for doing that, right? We have scenarios, we have use cases, we have Agile user stories. And so, obviously there's an acknowledgement that we need to think in sequence.

The reason that I like scenarios among those tools is, you know, for what you just said, is that they are fundamentally, at their heart, they're stories. And as human beings, we find this a very natural communication medium. The other great thing about storytelling is that it's a really natural creation tool. We've all been creating stories since we were little kids, and so it gets us out of this analytical, self-centered mindset.

But the other thing is that scenarios can coexist with these other tools, right? You don't have to tell your development team, "Oh, you want user stories? No, sorry, we're using scenarios." You don't have to fight that battle. You can use scenarios and then turn them into user stories if you want. Or if you have business analysts inside your team, you can turn things into use cases. But you can start with a natural storytelling tool.

And so, they make great silo busters as well, because a scenario really starts with where a user thinks that story begins, and then where the user thinks it ends. And that often will cross a whole bunch of different silos, or tools, or whatever it is that your company's offering to the world. So, if you think about them as stories, that'll tell you that in order to create a great scenario, you really need to think about those four big story elements: characters, conflict, plot, and resolution.

By characters, I'm talking about personas, not just roles, right? A use case or a user story typically uses sort of a dry role that says, "Hey, here's a job description, a type of thing that people do." And personas, on the other hand, have goals. They have human failings. They're a bit more realistic.

They have emotional needs and things that they want to accomplish by the end of the workday, and that helps us to design the interaction in a more empathetic way. And ideally, those personas are based on research, although you can certainly do some shortcut personas based on a shared understanding.

Once we've got agreement on who our characters are, we can then use them to drive the storytelling. And so, that's where we begin to identify what are the conflicts that we have to resolve? In other words, what are the situations that our personas will be in that our product has to make delightful, or just make happen at all? And then we can figure out what those situations are.

And from there, we begin what's really the design process, which is articulating the plot of that story and saying, "Hey, what should happen in an ideal world with our brand-new product or our revamped product that we're putting in somebody's hands? How should that work?" And we start to imagine a better future, and that imagination can be pretty compelling. It's a good way to bring people along with us. And the resolution of that story is always going to be where the persona thinks the story ends.

So let me just give you an example. Let's say that we're looking at the air travel experience. A typical project brief, if you will, would be, "Hey, let's improve the website."

However, if we say, "Let's imagine our personas," chances are we have half a dozen or so, "imagine that one of them is a fairly frequent traveler who travels both for business and personal needs." Well, that character is going to have certain goals, like minimizing hassle, and making sure there's room for the carry-on luggage, and making sure they have leg room, and things like that. And of course, getting there safely and on time with all of their luggage intact.

But if we think about the situations that persona will be in, then we're going to imagine, "OK, there's a fairly simple, fairly routine flight. Everything goes fine, how can we make that go smoothly? How can we make it go smoothly when there's a less common kind of routing that she has to take? You know, stop in three cities along the way, and come back via a different route?"

And then, a third situation we might think of is, "Oh, something went wrong, right? The weather has shut down Chicago O'Hare, which we know happens all too often. So what happens? How does that situation get resolved as painlessly as possible?" So we think about all these conflicts to resolve, and then we start to tell the story of each one, and then we imagine how can we make that situation as painless as possible? That leads us to a set of requirements, essentially.

And then, once we get agreement on those, we can start to sketch what that experience looks like, again, based on the storytelling. Because the story tells us how to group functionality -- what functionality ought to exist, frankly -- and starts to give us a sense for the flow through those screens and even the screen layout, because the sequence in which people use things usually is going to be the sequence in which we want to present them.

And then, finally, we use the scenarios to say, "Guess what, stakeholders, here's our design idea. Let us walk you through it in a storytelling fashion and show you why it's going to be a great solution for these personas that we've already agreed on." So, that was a lot, but that's it in a nutshell.
Adam: Well, that's great. Let's get to some of these questions that we're asked. We had a very engaged audience that day, and there were some good questions that came in. Chris asks, "Is it a true statement that scenarios can only be used if you have data-driven personas?" And then she followed it up with a somewhat related question, which is, "Have you seen scenarios used effectively, even if the research can't be funded?"
Kim: That's a great question. I think that you certainly can do this without data. It's always a great idea to have data if you can, 'cause it has a few benefits, right? One is, you're more confident that you're getting to a good answer. And it makes it a lot easier to make design decisions because instead of wondering, "hmm. How would people like this react?" You kind of know. If you know them very well.

Think of it like, you know, planning an event, or buying a gift for one of your loved ones, versus, say, buying a gift for your brand-new in-laws, whom you don't know very well.

The first one is a whole lot easier than the second one, and data really helps you have that confidence that you're doing the right thing. And the second point is that data helps you persuade stakeholders, because then it's not you, the designer -- who is probably pretty low on the totem pole, so to speak -- saying this is how it should be. It's you, the designer, channeling the users and saying, "Look, based on our data, here's how people think and act, and so here's why this is a great solution."

So, data if you can. Now, that said, I definitely do scenarios without data. I was doing a project just a couple of weeks ago, actually, working with some subject matter experts on an idea for a medical thing, just a little startup company. And so, four of us sat in a room, and we didn't have data. And the point was to get to some design ideas fairly quickly, so that they could explore feasibility of this idea.

And so, it didn't make a lot of sense for us to go get data, and we said, "OK, let's build some shared assumptions about the kinds of users we're talking about." We came up with what I call provisional personas, which are sort of just sketchy representations of what we think the usage patterns and goals are. And then we use those to create scenarios just as we normally would.

So, scenarios are a tool you can pull out of your pocket regardless of whether you have data. They're equally effective as generation tools. You're just going to be making decisions and communicating with a bit less confidence when you don't have data. But the tool still works great.
Adam: What's a good approach, Kim, to get buy-in from non-UX stakeholders, and prove the value of this process of building the personas, and then creating the scenarios?
Kim: Yeah. You know I think we all wish that we had a magic wand we could wave to have stakeholders suddenly go, "Aha! Yes! We must invest millions of dollars into this." You know, it's not going to happen. I think Jared's recent article about, you know, you can't persuade stakeholders of some of this stuff, is spot on.

And the thing is, it's very difficult to persuade people ahead of time. I think you can certainly try to get some buy-in by, say, sharing case studies -- which are hard to come by -- by telling some stories. But honestly, I think the most effective way to develop buy-in is just to do it.

Now, that sounds kind of impossible if you're worried about having budget for it, and so on. But the fact is, you don't have to start with, you know, plastering posters around the company and saying, "This is our official new design process." Just start using scenarios in a design meeting, right? That's your choice, nobody's looking over your shoulder telling you how you have to design at the whiteboard.

And then, start slipping them into conversation and showing them in your presentations. And as people start to see, "Oh, you know, that presentation was great, that was really persuasive." Or, "Wow, that's an awesome design, how did you get there?" Then you can say, "Ah, well, I used this tool that I think we should be doing more of, and you know what, it would be easier if we went out and did some more research."

Same thing with research, you know? Tag along on a site visit or something with a product manager, if you're in the enterprise. Or, you know, watch a friend use your website, just so you get some data besides your own head. That kind of stuff is basically free. And so, start with what you can do cheaply and easily, and then just rely on that to demonstrate the value of what you're doing, and tout that success and use it to develop allies and get them talking about how it's working, too.
Adam: So, one of the questions that Jan asked was, "To what extent should scenarios come from your clients?" And I guess I would also add, "Well, what about your stakeholders and kind of other internal customers? How do they play in the process?"
Kim: Mm Hmm. Good question. Well first let me make a distinction between the scenario, which is the story of how that future interaction would ideally unfold, and the situation that kicks off the scenario, right? So, one of the things that you want to do certainly in a project is get agreement on, "what are the situations that we need to address?" In other words, "what are the starting points of all the scenarios we're going to walk through?"

So a minute ago I mentioned air travel, right? One of the situations we know we have to handle is the airport is shut down or the flight is canceled due to weather. What happens? Another situation that unfortunately we have to handle is lost or damaged luggage. What happens? Another situation we have to handle is, "Oh, people suddenly have to cancel flights or change flights." What happens?

So we definitely want to involve stakeholders or clients or, you know, whatever you want to call them, folks who are not UX designers developing the solutions, we absolutely have to involve people in figuring out what are those situations, because we want to make sure that they think we're doing the right thing, and that we are doing the right thing. And so that's definitely the starting point.

In my experience, whether we involve stakeholders in actually generating the scenarios really depends a lot on the stakeholders themselves, and also how many of them there are. I would hate to try to develop scenarios and imagine that future solution with 10 people in the room. It would be really difficult, I think, to get super-creative and make progress at any kind of speed.

And so most of the time I work with a small team of designers to develop those scenarios or, you know, if it's a startup client or something, a couple of subject matter experts. And then we craft those, but then we very quickly share them with a broader set of stakeholders. I think creation is much more effective in a very small group of two or three people, but you absolutely want a big group for review.

So your stakeholders should help you figure out what situations to address, maybe help you create them, definitely review them.
Adam: Darlene asks, "Different personas have different behaviors and goals, but might be using a similar solution. How do you use personas to help inform a solution that will work for a broader range of personas?"
Kim: Mm Hmm. I think it's essential that you have more than one persona on a project. So it's actually the normal case that you have to balance the needs of multiple personas. The challenge if you only start with one persona and you don't think about anybody else is that your product could get very narrow. And it could not be very flexible for real world use because, in reality, almost any situation you're going to find that people have different ways of thinking about a process or different priorities. And so you want to uncover what some of those patterns could be and then use them to sort of assess the edges of the scenario.

So let's go back to air travel. Let's just stick with a consistent example here. If we just focus on somebody who's a frequent flyer, who really knows their way around, whose goal is all about, you know, efficiency and getting the bulkhead seat and whatever, then we're going to have a solution that doesn't provide enough support for, say, the personal traveler who's on vacation with two small kids who hasn't done this in five years, and doesn't know that you're supposed to put all of your liquids in three-ounce bottles, or whatever. And so we want to make sure that we're covering both of those.

So the way that we use personas and scenarios, then, is we figure out what those key patterns are and agree on them so that we know who we have to address, and then we develop scenarios for each of the personas. So if you have three personas, you're going to have at least three scenarios, chances are you'll have more than that.

Most of the time, you want to choose a primary persona, either for a whole experience or for some part of that experience, and start with them. Imagine what are the common things they'll do most of the time, and then pick an example of each of those and use those for scenarios. And then you'll look at your other personas, your secondary personas, and figure out, well, what other situations are they going to encounter that our main... our primary persona won't encounter?

Or what are situations they're going to encounter, but they're going to approach very differently? So for example, a snapshot photographer and a pretty serious, you know, semi-pro or pro photographer, well, they're going to approach the process of sorting and processing their digital photos very differently.

And so we want to make sure that we're dealing with that situation, creating that scenario for both of those personas, so that as we start to sketch, we'll sketch for one, and then we'll look at how the other does it and we'll adapt the sketch, make sure it still works for the first one. So we're constantly bouncing back and forth between personas and scenarios as we sketch to make sure that we've kind of defined the boundaries of the solution.
Adam: Kim, what's the best way to communicate your scenarios with the development team and get their buy-in or acceptance for what you've created?
Kim: I hesitate to say "best way" because there's no one best way. I think it's whatever works for you.

What I have found effective is less about the specific method of communication and more about the philosophy that you apply to the whole project, actually. Because if you just walk into a room with people who've never encountered your work before and say, "Ta-da! Here are your personas and scenarios," they're going to be rejected, right? The body's immune system is going to get to work on those things right away.

But if, instead, you acclimate people to that process and involve them in it, you start out with people saying, "Hey, we need to do some research here. What kinds of people should we talk to? We have some ideas. What are your ideas?" And you get agreement on the research sample, so that when you come back and you say, "Here's what we learned in research," you don't have people arguing with, "Well, did you talk to the right people?"

And then when you share those findings and you get people nodding their heads and saying, "OK, yeah, that makes sense, those sound like our customers and our users," then you can say, "All right, well, here are the behavior patterns we've distilled in our personas," and then you get people's agreement on those, and then you say, "OK, now, given the personas, these are the situations we think they're going to encounter. Here are the scenarios," and so forth.

And so you're building progressive commitment, right? It's just like when you go to the car dealer and the car dealer says, "You want to sit in it? Hey, do you want to test drive it? Well, now that you want to test drive it, should I run some numbers and see what it would cost to get you in the car?" right?

So hopefully we're not so cheesy about it as the used car stereotype, but that's essentially what we're doing, is we're getting people to buy into the process over time rather than just trying to get them to buy into our one deliverable.

That said, when you're sharing that deliverable, I think the techniques that work the best for me are really to think of it as telling a story, right? Focus on being persuasive and not just, you know, showing people some sort of workflow, but telling it as a story, and saying, "OK, remember this persona that we talked about a week or two ago? Well, here's the stuff that we said we needed to solve for her, right? Remember these issues? OK, now, here's the scenario that we're imagining."

So revisit who that main character is, revisit the needs you've already agreed on, and then tell them the story, and then recap and say, "See those needs that we mentioned earlier? Here's how the scenario meets those needs." So, you know, it's really sort of a rhetorical arc that way. But that rhetorical arc starts all the way back at planning and research. It doesn't just start with sharing your scenarios.
Adam: Kim, there was a lot of interest in asking you the comparison or contrast between a scenario and what folks were referring to as a storyboard. Can you help us there?
Kim: A scenario is the sotry, it's the script. It's the words that describe the action. A storyboard, on the other hand, is the graphic depiction of that action. So if you've ever, you know, watched the movie extras on your DVDs or your Blu-Rays or something, you've probably seen sketches stuck on the wall. That's what I mean when I talk about a storyboard.

It's essentially at a thumbnail level, but the key to storyboarding is that it's depiction of sequence over time, right? A storyboard can be a very rough napkin sketch, right? If you're talking about a high-level service design, like getting through the airport, you might have stick figures walking through physical space, if you're doing just a screen-based design, you probably won't storyboard your first pass at the scenario because it's so high-level, you're not really getting into solutions.

But then as you start to get into more detail in design, you're going to keep storyboarding at the whiteboard, drawing multiple instances of a screen and how it changes over time. As you start to express that design and share it with stakeholders, you can have storyboards at that wireframe level, where they're pretty much content and control complete, but you haven't really incorporated any visual design.

And, you know, you can still use that storyboarding approach down at the pixel level where you're showing changes in screen state over time and just, you know, plopping those in a PowerPoint presentation or something and flipping through them, sort of, not even a poor man's animation, but sort of keyframing, like they do in movies.

So storyboarding is essentially a sequence of pictures that tell a story, and the scenario is the text of the story itself.
Adam: So, Kim, Chris asks a question about sort of a life of the scenarios that you create. Do they live beyond the project they're developed for?
Kim: Hmm. Well I'm going to give you the classic UX answer, which is of course, "it depends". You've heard that before I'm sure.

I think that if your initial project is looking fairly far into the future, right, if you say, "Our first pass at this design is going to be where we want to be in three years, four years, five years from now", then after that, you're going to scope down and you're going to focus on the stuff that you can build this year. And so if that's the case, you bet that initial scenario will live on, because it should actually guide several years' worth of development for you.

And that's an approach I often recommend to my clients, because especially if they're starting with a new product, as opposed to, you know, a fairly constrained additional function or redesign, I think it's important to have a roadmap. And it doesn't take a whole lot of additional time to invest in, "Let's imagine the story of the future and maybe do some quick storyboards to sketch out what that might be, because that way, you have a sense for what you're going to be building."

I kind of use the building a house analogy, right? If you know that you can't afford to build the second story on your house now, but you know in five or six years you're going to be, then your architect and the construction crew can make sure that the foundation is strong enough and that the walls on the first story are strong enough to support that additional weight.

So in an ideal world, yes, those early scenarios live on. That said, once you kind of get past that stage, the individual scenarios, those are going to be pretty project-specific, because you're just focusing on a specific version.

The other thing is, very few of the scenarios are really documented in detail. The vast majority of scenarios are not things we're writing down, they're actually things that we're just kind of throwing out at the whiteboard, right? You put a sketch up there, and your design partner says, "Oh, well, what if this happens?"

And then a sort of mini-scenario just sort of unfolds in that conversation. You make some adjustments to the sketch, and you move on, and probably nobody wrote down the detail of that scenario. So it's maybe only six or eight scenarios on a project that you're actually writing down in any super-concrete form.
Adam: All right, Kim. Thanks so much for circling back with us. I know you're very busy, but it's always a treat to hear what you're thinking about.
Kim: My pleasure, thanks.
Adam: To our audience, thanks for joining us, and thanks for your support of the virtual seminar program.