Kim Goodwin – Developing Effective Scenarios

Podcast: Play in new window | Download (Duration: 34:53 — 18.5MB)

Subscribe: iTunes | Android | RSS

[ Transcript Available ]

Combining storytelling with research data can help you craft realistic scenarios to guide your design process. Getting to know the specific needs of your users allows you to address any potential problems they may have. As a consultant, Kim Goodwin uses her experience and expertise in working with teams to develop effective scenarios. In this podcast, Kim discusses the role that scenarios play in the design process with Jared Spool.

Kim will be part of the User Interface 16 Conference November 7-9 in Boston, MA. She will present a full-day workshop on using scenarios, helping to focus and prioritize. Find out more details about the conference at UIConf.com.

Here’s an excerpt from the podcast.

“…The thing is, a story has a character, somebody with skills, and goals, and feelings, and other real human characteristics. User stories employ roles which are real abstractions of users. A story has a plot, it has a beginning and an end. It has something that starts off the action and some logical conclusion that’s a satisfying ending to the story.

Whereas, user stories are just like… Use cases or scenarios, they’re sequential thinking, which is good. That’s a helpful way to approach interaction because it always happens over time. But they’re often fragments of complete stories…”

Tune in to the podcast to hear Kim cover these points:

• How do you help people start to use personas and scenarios?
• Is it good to use abstract scenarios in conjunction with more specific ones?
• Where do the scenarios come from?
• How important of a skill is storytelling when developing scenarios?
• Have you experimented with breaking teams in to smaller groups in the scenario creation process?
• What are some techniques you’ve used with teams to collect data?
• How do scenarios compare to user stories?

Do you design with scenarios? Share your thoughts in our comments section.

Recorded: July, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello, everyone. Welcome to another episode of the SpoolCast. I am very happy today because I have a chance to talk to my good old friend, Kim Goodwin, who has presented at more of our events, I think, than anybody else on the planet. And she wrote a fabulous book called “Designing for the Digital Age.” She’s going to be presenting at our upcoming User Interface conference, User Interface 16. Kim, can you believe it’s the 16th year?

Kim Goodwin: I know, that’s crazy. I’ve lost count of how many of these things I’ve done.

Jared: I know, I know. It’s really insane. So at User Interface 16, you’re going to be talking about really pulling the value out of using scenarios. Once you have your personas and your scenarios, how do you really get the value out of them? I’m really excited about this workshop because I think scenarios are the sort of untapped treasure that we as designers don’t really use enough.

I try and use them all the time, and I still don’t think I use them enough, because they really do have an effect on every aspect of the design, from the first moment you start to talk about what the hell you’re going to build, all the way through the deployment process. Do you find that to be true, that there’s use everywhere?

Kim: Pretty much. I mean, certainly, if you have a hammer, everything looks like a nail. But I think that scenarios are my go-to design tool. I think if I had to give up every other tool in my kit, I could still get an awful lot done with scenarios.

Jared: Yeah. Now, you and I were talking, and you referenced this great quote of Plato’s, which was, “Those who tell the stories rule society,” which is just brilliant. And of course, the society that many of us live in is our work society. I think that the personas that we create and the scenarios that we use to describe those persona situations are really a great way to get control of a product that possibly has gone astray in other ways. How do you help people start to use personas to bring their design conversations around to what they need to build really great stuff?

Kim: I think there are two ways, fundamentally, that personas and the scenarios they star in really help to drive that conversation. One is that scenarios help you develop and articulate your vision. I think that Plato says, “The people who tell the stories rule society” because… Think about all the great leaders that you’ve heard of in our time. Right?

Martin Luther King didn’t stand up there and say, “Hey, you guys aren’t including us, and civil rights are not what they should be.” He said, instead, “I have a dream.” And he painted a vision, and I think that’s what made him an inspiring leader.

And so, we want to do the same thing in design. We want to inspire people and say, not, “Here’s how all the usability is bad, and you should include design more, whine, whine, whine,” but instead, say, “Look, guys, here’s where we want to go. Wouldn’t that be great if we could build that and really get everyone behind it?”

So I think that’s one part of the story. The other is that, when people start to talk about doing this or that with the product or this or that feature, you can challenge other people on the team to use scenarios so that everybody’s using a shared reference point and speaking the same language. And it gives everybody a shared framework for making good decisions.

Jared: There’s a lot in common with both the points, this idea of a shared reference point and this idea of a vision. Right? Because what I’ve been helping teams with is giving them this idea that one way to construct your vision is really to just understand what the stories are for today’s experiences. What is it like to be a user today? And then, if you got rid of all the nasty, ugly, frustrating bits, what would that experience turn into? How would it change?

And so, there you’ve got, basically, one scenario, one in the dark, dismal, frustrating world of today’s experience, and one in the golden, blue-sky, flower-and-field version of the future where everything just goes smoothly and perfectly.

And so, at one level you have an abstract scenario that would cover both things fairly accurately. And then, you can use those scenarios to dive deep and say, “OK, what changes when it’s frustrating and people have to compensate for that frustration? And what is different when we’ve gotten rid of that frustration, and now they’re getting delighted by everything, and how does that change what they do?”

That distinction, being able to shift from that higher-level, abstract notion down to more specifics, depending on whether you’re in today’s world or a future world, is that something you find yourself doing?

Kim: Actually, not at all.

Jared: Oh, OK.

[laughter]

Kim: I find that part of what works about scenarios is that they’re not abstract.

Jared: OK.

Kim: They’re fairly concrete. They give people handles to grab onto. And I think there’s a lot of value in what you’re talking about, with painting a picture of today, right, and helping everybody understand where processes are broken and that sort of thing.

I tend to do that with research findings and personas and say, “OK, everybody, can we get agreement on the state of the world today? Here’s what we saw in research. Here’s what the goals and pain points and characteristics of our personas are. Do we agree that this is an accurate depiction of reality?”

Because, if I can get agreement on the current state of the world, that gives me a more solid foundation for building the future. Right? Because the last thing I want to have happen when I’m describing a future scenario or showing design is for people to start arguing about what the data is.

So we try to get commitment at that initial level without using scenarios, per se, but say, “Look, here are the pain points we saw in the process. Here are some of the really fabulous quotes that we got out of the research where people are banging their heads against walls. Maybe here are some snippets of video or some photographs that demonstrate those points,” but really using the data to make that visceral, and then in the scenarios, which are focused on the future, saying, “OK, now let’s imagine the better world.”

Jared: Right. I guess I’m curious, where do the scenarios then get pulled out? Because what I was thinking was that, as you were creating the personas, you were sort of documenting the scenarios of today. But it doesn’t sound like that’s what you’re doing.

Kim: Not in great detail. I mean, I think that you could spend a lot of time documenting that. I find that, when it comes to really getting the most value out of your research and design time, I find that’s not the most productive use of time, documenting everything that’s wrong. Because that doesn’t necessarily help us make a lot of progress.

Unless it’s something where you’re really focused on a detailed redesign and you have the FDA looking at everything for approval and so forth, that level of documentation doesn’t serve most teams well, I don’t find. Maybe there’s a white-board sketch of the current process and a highlight of some of the points where it’s broken in general, something like that.

Where you pull the scenarios from is out of your understanding of the users. Right? And it’s not a scientific process. Instead, you’re relying on your human intelligence and your understanding of the goals and the characteristics of those people and saying, “OK, in a magic world, what would this be like?”

And this is an uncomfortable step for some people who want design to be a science. But think about it. When you’re planning a party for a friend or buying a gift for someone, you’re imagining what would be awesome for somebody that you really care about and know very well. You can do that with a fair degree of reliability. Right? And that’s exactly what we’re trying to do for our users is to say, “We know what makes them tick. We know what’s going to make them very happy. So let’s imagine what that might be like.”

Now, that doesn’t mean that we’re not still going to do usability testing and things like that to make sure that we’re right, because we’re not perfect, but we’re going to trust our gut as a foundation to generate. Scenarios are fundamentally generative tools.

Jared: Right. And if you’ve gone out and done your research… When I go out with teams, and we go out and we actually see their customers and we’re in their homes or their offices, and we’re looking at them actually do the things they do every day, it’s pretty easy to see what gets them all excited and giddy and what is dragging them down. When you have that full context to put everything in, it becomes really easy to pull out the scenarios, I’ve found.

Kim: Yeah. When you know your users really well, scenarios are… Certainly, there are a few technique tricks to master. But once you’ve got those down, scenarios are the most natural tool in the world. Because it’s just storytelling, fundamentally. It’s storytelling based on your understanding of the data, but it’s something we’ve all been doing our whole lives, right?

We’ve all been telling stories since we were, what, two, maybe younger than that even? Almost as soon as kids learn to talk, they start to tell stories. And so, we’re not bogged down in drawing UML diagrams and these other things that are kind of alien to how we think and communicate. Instead, we’re using a tool that’s very deeply familiar to us.

Jared: Yeah. I was with a friend who has a two-and-a-half-year-old, and she was telling us this story. It was so rich in detail about everything that went on in the story and all the different pieces of it. We were laughing hysterically because of the details that were coming out. She had imagined this whole world and had no trouble producing that. It’s amazing that we sort of beat that out of ourselves, huh?

Kim: And I think that your use of the word “imagination” is one of the keys because… In our day-to-day work, how often do we get to just imagine what’s great, right?

And because storytelling is a tool that we use early in our lives… This is my personal theory, anyway, not proven scientifically. But I think what we’re doing is… OK, this is going to sound all touchy-feely, but we’re drawing on our childhood selves, in a way. We’re drawing on a time when we were more free to imagine, because we’re using this tool that we probably don’t use that much once we become adults.

Jared: It’s interesting. We’ve been talking a lot lately amongst ourselves about sketching and how we all sketch when we’re little, and then many of us get told that we’re not very good at it so we stop doing it.

Storytelling is sort of the same way. And I’m wondering how much of this idea of creating great experiences really is something that we’re more in-tuned with when we’re younger, because we’re all about play, we’re all about imagining a space that we’re not in that’s a better space for everybody, and then the harsh realities of the world sort of talk us out of that.

Kim: Yeah. Certainly, we’re still applying our adult skills. Right? I mean, we’re applying our knowledge as designers when we tell our scenarios. We’re drawing on design principles and synthesizing that as we go to imagine these things.

So it’s not pure imagination. There’s absolutely craft in there. There’s knowledge and expertise in there. It’s a frame of mind that is intentionally a little bit naive and optimistic to begin with.

This is one of the things that makes people a little crazy when they first try to use scenarios. Because, if you’re in an organization where people are accustomed to jumping to the constraints and the details very quickly, your first pass at scenarios is going to be very high level and optimistic. Let’s ignore the constraints for a little while to imagine what would be awesome to do.

We know that we’re going to throw some of it away. That has to be OK because, unless you’re free to imagine what’s desirable, you’re just going to focus on what’s possible and you’re never going to get to that really amazing solution that you actually could do more easily than you think.

Jared: I think that there is definitely something to this, because a lot of teams really get stuck trying to live inside their constraints. And of course, the really hard, wicked, gnarly problems are ones that are so rich with constraints that all they can do is, with any possible solution, list the 20 reasons why that solution couldn’t possibly work. They get really stuck in that world of what they can’t do and why they’ve tried it before, and why it hasn’t worked.

So now, how is it that you use scenarios to get beyond that space? What do you do with teams when they’re stuck there?

Kim: I think that who’s involved in scenarios is… It’s partly a temperament thing. Most of the time, when I’ve done scenarios, it’s been specifically with other designers who are willing to take on that optimistic mindset because it’s natural to them, or with members of a product team who… Maybe struggle with it a little bit, but they’re willing to try that on.

Occasionally, with people who aren’t used to it, you have to pull them up short in a discussion and say, “Look. We’re thinking optimistically here. Let’s write that down on the whiteboard as a concern we’ll deal with later. Let’s focus on what we love to do.”

I think the key is just that everybody knows the rules at the beginning of the discussion so that you’ve got a small set of people. I think it’s really hard to do scenarios with six or eight people in the room. I think it’s much easier with two or three people in the room because you just don’t have quite as much… You don’t have as much politics and compromise and things like that.

I think that generating is much easier in a small group. Evaluating makes a lot of sense in a bigger group. But I think that, if you can get together and say, “Look. These two or three people have knowledge of the data, they’ve got direct experience with the users,” let’s imagine what’s possible.

Jared: When you have six to eight people, have you ever experimented with breaking them into smaller groups for this scenario creation process and then coming together to share what they’ve got?

Kim: I haven’t really done that because I think that… Competition may work. It may not.

Jared: You could give them separate things to do scenarios on.

Kim: Yeah. I think you can. What I find challenging is it’s hard to actually have six or eight people all of whom have direct experience with the data. And so, then you get people coming up with scenarios based on what they think, rather than what the data really is. It’s a lot harder to get that sort of a group focused not on their own assumptions.

Jared: So it is a key element that you’ve really got to have some real solid data behind the scenarios you’re producing.

Kim: Ideally. Have I done scenarios in cases where we all have shared assumptions and not real data? Sure. They’re perfectly useful tools, even when you don’t have data. But they work a whole lot better when you’ve got some data to back them up.

Jared: What are some techniques that you’ve used with teams to get data?

Kim: To get data?

Jared: Yeah, to get the data for scenarios. Are there certain types of things that are better at pulling data that you’re going to use for scenarios than other things?

Kim: My go-to technique for this kind of stuff is interviews, observation, using techniques that are borrowed from ethnography. I won’t say that it is ethnography because it’s not, strictly speaking.

Going out into user’s context where they’re using competitive products or services, or where they’re using somewhat related tools, if you’re inventing something brand new. Observing what they do, asking them why they do it that way. Seeing what drives them crazy. Those kinds of things… I think that direct, in context, observation is irreplaceable for this kind of design.

Jared: I’ve found the same thing, too. The more direct exposure that the people who are involved in doing the design and creating the scenarios have, the easier a lot of that work comes. Because, like you said, you’re not having a lot of conversation about what you imagine. That makes perfect sense to me.

I’ve been working, lately, with a bunch of teams that seem to be in this mode where they’re focusing on the march of the endless feature list.

Kim: Oh, yes.

Jared: And they don’t seem to have any real direction in their design. They’ve just got this list of things that they’re doing, primarily because their competitors are doing it, or some big customer says they’ll buy 1,000 versions of the thing if they implement this one feature.

Everything that they do tends to add a piece of complexity on top of the complexity that they’ve already added the last 20,000 times they’ve done this. This sort of giant hairball of design emerges.

Is that a situation you’ve found yourself in? And if so, how do you work with the team to get out of that mode?

Kim: Oh, absolutely. I think almost every designer encounters that if they work in more than one place.

I think that the bolting things on feature by feature is a really common approach, I think partly because it’s a way to scope development. Developers think, “Well, this is a capability that’s going to take this kind of effort to code versus that kind of effort to code.” And in that respect, it makes sense.

On the other hand, users don’t really experience feature lists. They experience workflows. They experience start to finish processes. And so, if you really focus on feature lists, I think you get the Winchester Mystery House of products. Right?

There’s a place in San Jose where she was listening to voices and she just starting bolting on stairways that go nowhere and doors that open three stories up into nothingness, windows into closets and things like that.

Jared: I just worked with a product manager that was listening to voices. I think that’s exactly how they were designing.

Kim: It’s true. The thing is that those voices are probably executives or customers. Right?

Jared: I could only hope.

Kim: Yeah, that’s true.

And so, I think where personas and the data behind them come in handy, and where scenarios come in handy, is giving people a focal tool. Instead of looking at the feature list, you can say, “Look. Let’s imagine this better experience. Let’s start idealistic. Let’s take Persona A through these three major things that they’re going to do with our product or our service. Let’s take Persona B through these two things that they’re likely to do with our product or service.”

“Now, let’s compare that to what we think our feature list should be. Hey, look! Our stories uncovered two or three things we haven’t anticipated in our feature list that look pretty important. And look, these other things in our feature list… Hmm. Gosh, those didn’t show up in the scenarios at all. What does that tell us?”

So I think that they’re a great tool for product managers to help prioritize requirements. Product managers right now don’t have a lot of great tools for this. They can go out and try to play innovation games with their customers and give people $30 to spend on features and have them prioritize in the abstract.

I think all of that is much less useful than saying, “Look. Here’s the story of the experience we want to build. Here are the pieces that are integral to that story. Here are the pieces that could be left out and you’d still have a coherent story, and we’ll save those for later on.”

And so, it just gives everybody that decision making framework.

Jared: Now, a lot of what you’ve described sounds very familiar to what Indi Young does with her mental model stuff. She’s got these, basically, two aspects of the design and experience. On the top, she lists all the things people are trying to do. And on the bottom, she lists all the functionality within the product that does that.

You can quickly, using her technique once the chart is built… You can quickly see where you’ve got a lot of things people want to do and not much functionality to support it, and vice versa. Is this fundamentally the same thing, or is this a different spin? Or, is this completely different and I’ve just got it wrong?

Kim: I’d say they’re related. I think one is a very storytelling approach. I think that I tend to follow up the initial scenarios with something closer to what Indi is doing, which is, “Let’s break down the story into the stuff people are trying to do and what that means for our requirements.”

Because once you can agree on a story, you say, “OK. If this is the story we want to accomplish, here’s what we have to be able to do. We need to know this. We need to be able to pull this data from there. We need to be able to connect these two systems that aren’t talking right now. We need to completely overhaul how we do customer intake,” whatever.

And so it’s kind of like, “Here’s the story. Here are the implications of the story. Now which of these can we really take on in the near term?”

The story kind of sells the idea first. It says, “Can’t we all agree this is a great goal? Now let’s get pragmatic about how much of that we can take on and when.” And so, it’s similar.

Jared: And how much you’re already doing, and how far off are you for the things you’re not doing.

Kim: Sure.

Jared: Yeah, that makes a lot of sense.

Now, a lot of things about this story stuff is that folks eventually at some point have to translate this, particularly if they’re doing some sort of agile like process. I’ve come to learn that no one actually does agile, they just do things that they claim isn’t quite agile.

Whenever I talk to someone, I say, “So, are you guys doing any sort of agile development?”

They say, “Well, it’s sort of like agile.” Sometimes they’ll even say, “We don’t do agile the way you’re supposed to.” As far as I know, nobody does it the way you’re supposed to.

Somewhere in there there’s these user stories, often on cards, they’re part of the backlog. They’re this thing that, at some point, sort of drives the development effort and the design effort.

But those stories are not these scenarios, right? You have to get from your scenarios to those user stories in some way. Do I have that right?

Kim: Right. I think the great irony of the term “user stories” is that they’re really not stories.

Jared: And they’re not really about users.

Kim: Right. The thing is, a story has a character, somebody with skills, and goals, and feelings, and other real human characteristics. User stories employ roles which are real abstractions of users. A story has a plot, it has a beginning and an end. It has something that starts off the action and some logical conclusion that’s a satisfying ending to the story.

Whereas, user stories are just like… Use cases or scenarios, they’re sequential thinking, which is good. That’s a helpful way to approach interaction because it always happens over time. But they’re often fragments of complete stories.

So it’s very common to see a user story, something like, “User logs in.” That’s not a story. That user story might tell you, “User enters name, user enters password.” Well, who is that user and why are they logging in, and what is it they’re trying to get to after they log in? So that complete story needs to put that action in context.

Now, that’s not to say that you can’t use user stories. I think that scenarios are completely compatible with waterfall, agile, or whatever custom mix of development approaches you use. Because you can turn scenarios into chunked up user stories very easily. But by doing the scenario first, you get the overall context and the overall flow.

You can also turn them into really detailed use cases documented in 90 pages of UML if you want to. If you’re working on legacy systems and there’s tons of complexity and you want to make sure that you capture every detail, sure, great, do that, but use the scenarios first as a generative tool, as a discussion tool, as a persuasion tool. Get agreement on where you’re going and then break it down into these other ways of chunking that information.

Jared: So if you’re working with an agile team… People talk about this sprint zero activity, the stuff you do before everyone goes heads down and starts coding up their first iteration. So having those scenarios come out of that sprint zero and having those discussions with the team coming out of the sprint zero, that could be really valuable.

Kim: Well, not only the scenarios, but also an initial set of storyboards that illustrate the scenarios. In my experience, by the end of sprint zero, you at least want to be there if not starting to get into the detailed design for sprint one so that you’re a sprint ahead. Trying to do detailed design on something while it’s being coded, that’s still a real challenge.

I think the agile goal of bringing design and development closer together in time is great. Because, if you’re designing something that no developer is going to touch for another three months… Yeah, that doesn’t work so well. But it’s great if you can design it a week or two before it starts getting coded so that design isn’t playing catch up.

But yeah, definitely, at the end of sprint zero, having some storyboards that you can say, “Look, here’s what this ultimately is going to look like, here’s how all the pieces fit together so that everybody understands when they’re designing this piece or that piece how it fits into the whole, how it affects the other pieces,” that makes that whole process a lot less chaotic.

Jared: I’m wondering about this because in an agile world the reason that we want to get design and development closer together is because once we get that first iteration done we’re going to learn stuff and things are going to change.

Once our target users get a chance to play with what we’ve built for a prototype in that first iteration, we’re going learn all sorts of interesting stuff that we couldn’t possibly have predicted before we started that iteration. And that’s why we don’t do those big, heavy design documents where we lay out every radio button for everything in its final form.

But do the scenarios change over that period, or do they tend to stay the same? Have you found, in your experience, that you can have radically different scenarios emerge out of those first few iterations or do the scenarios basically stay the same and become sort of the grounding for what we’re learning about what the users need in there? Am I making any sense whatsoever?

Kim: Let me respond to something you said in the lead up to that question which is, we’re going to learn all kinds of things we couldn’t possibly predict. Really? I don’t know about that. I think that, if you don’t do any research… Oh, yeah, you’re going to learn all kinds of things you couldn’t possibly predict. If you do good research up front, you’re going to learn a few things you couldn’t predict.

Jared: OK, OK, I buy that, yeah.

Kim: Right? So if you’re diving straight into design and development without doing research first… Yeah, iteration is going to be really educational. If you do some research first and design thoughtfully… And I’m not talking about six months developing a detailed spec. But you get to a coherent set of storyboards that everybody can look at and say, “Yeah, we see where that’s going. That looks great,” perhaps we even do a little scenario walk through with some users and get a sense that, “Oh, yeah, that looks like it’ll work,” then you can start to get into spec level design later on if you want to.

But what you learn in those iterations really ought to be polishing and not undermining your fundamental assumptions, because you’ve already figured those out.

Jared: So it would be fair to say then that, if you don’t do good research up front, your first iterations are going to be your research, and they’re a very expensive way to do research.

Kim: Very expensive way to do research, yes.

Jared: So that’s a good argument for getting that good research done up front because you’re not trying to research through code.

Kim: Right. Code is a very expensive medium to throw away compared to a couple pieces of paper.

Jared: Exactly.

Kim: Right? I mean, yeah, great engineers can code really fast. I really love the agile ethic that we learn through coding and it accepts that we also learn through designing which is something that waterfall doesn’t quite culturally accept. Waterfall assumes that you can get the design exactly right before you code anything, and that’s not true. Design is an iterative process, it’s a learning process.

Scenarios will evolve over time. And the way that they’ll evolve is usually not to fundamentally change direction unless you’ve done them very badly and didn’t do your research well.

But what happens with scenarios as they iterate is, they get more detailed. Because your first scenarios… You’re not worried about what list box people are touching in those first scenarios. You’re just trying to get the big stuff right. You’re trying to get a sense of roughly what kind of information are they exchanging with the system. Approximately what are they getting back, and how is that all flowing and what’s the end result?

And so, at that stage, who knows what widget is on the screen. First you’re just trying to figure out what screens do we even have. And so, your scenarios will evolve over time, they’ll get gradually more detailed.

I like to document the handful of early scenarios if there’s time. Later scenarios, well, those are just completely throwaway. You’re sketching at the whiteboard and somebody says, “Well, what if our user wants to do this normal variation on what we’re drawing up here?” And the person with the whiteboard marker says, “Well, I think it would look like this and let’s test that out.”

Well, you just used a scenario. It was a totally throwaway scenario, it was very informal. It’s not something you’re going to waste your time documenting, but it was still a useful tool that you just pulled out and used almost invisibly.

Jared: Right, and if you got good research and you can say, “Well when we went and visited Mary, she was doing this,” that becomes a really powerful story. You can say, “OK, how is she going to do that with this new design, or is it something she still needs to do? Are we going to make it so she doesn’t need to do that anymore?”

Kim: Exactly.

Jared: Which will make her really happy because she hates doing that.

Kim: Right.

Jared: I learned that when I saw Mary.

[laughter]

So it really feels to me like this isn’t really something new, this scenario thing, as much as it is formalizing our activity about things we’re probably already doing in a clumsy, informal way.

I think of it like when you look at professional sports athletes, let’s say a baseball player, they start to deconstruct their stance and how they hold the bat, and how they swing, and at what point in the pitch they make their call and swing.

The coaches for these athletes have very specific language for describing each of these types of things and what the different ways to handle it are. In essence, they’ve formalized… And formalizing has a bad connotation for a lot of people. But they’ve really thought through and said, this is how we handle these types of situations in the way we’re going to do this activity.

It sounds like what you’re doing is saying, “Look, you’re probably already telling stories and you’re probably doing it in a sloppy way. Here is the difference between good stories and bad stories in terms of how effective they are in getting the work done. And here’s how to get your stories more on this direction where they’re working for you and not against you.” Is that a fair description of what we’re doing here with these scenarios?

Kim: I think so. I think it’s actually a fair description of any design technique. I think that something that successful design organizations do over time is they look at their more successful designs and at their more successful projects and compare them to their less successful ones and say, “What did we do differently in these, and where are the patterns in that?” And the stuff that works well, that’s the stuff you want to keep doing.

And so, that’s exactly what I’ll be teaching everybody in the workshop about scenarios is stuff that I’ve seen over time and my teams have seen over time that tends to work pretty well.

Jared: Yeah, you and I were going over the outline for the day and it’s really rich. You’re packing a lot of really fun stuff into this. And it really gets down deep into things like how to deal with different channels of delivery platforms in parts of your organization, how the scenarios go across that, and how much you can use the scenarios to do things like derive the important requirements and figure out what your storyboards should be. It’s really going to be a lot of fun.

Kim: Oh, I hope so.

Jared: I’m really excited about it, I can’t wait to do it. So this has been really an excellent chance for us to talk. I want to thank you for spending this time with us today.

Kim: Oh, thanks for having me.

Jared: And I want to thank all of our listeners. You guys can all hear Kim. She’s done some virtual seminars for us in a variety of things, but other podcasts too, we’ll publish a list of those. But I’ve got to tell you, you don’t want to miss this seminar that she’s going to be doing at the User Interface 16 conference. It’s a full day that dives deep into this area of using scenarios and bringing that out and getting the most out of that.

It’s going to be really a lot of fun and people are going to just walk out of there… You’re just going to go, “Oh, my gosh, this was just so awesome. I can use this right away.” You don’t want to miss that. That’s going to be November 7th through 9th in Boston, Massachusetts. You can find out more information at uiconf.com, that’s uiconf.com. Hope to see you there.

Kim, thank you again.

Kim: Thanks, Jared.

Jared: And thanks to everyone for listening. And as always, thank you for encouraging our behavior. Take care.