Jared Spool: Welcome, everyone, to another episode of SpoolCast. I am so excited today because I am talking with my good friend, Kim Goodwin who, coincidentally, is also going to be at the User Interface 15 Conference. I’m very excited about that, it’s going to be a nice chance to see her. You can see her, she’s going to be teaching a full day workshop called “Designing with Scenarios: Putting Personas to Work”.
Ladies and gentlemen, Ms. Kim Goodwin. Kim, how are you doing today?
Kim Goodwin: I’m doing great, Jared. Thanks. How are you?
Jared: I’m doing fabulous. I’m doing fabulous. So, I was just thinking about you the other day because I was in a conversation. The conversation went something like this, “Oh, yes, we need to do some scenarios because we have to get those use cases done so that we can have our user stories.” I’m thinking, “How did you work all that into one sentence?”
It seems to me that all of those things are things that people are talking about today. Some people are interchanging these terms. There seems to be some confusion on the difference between use cases, user scenarios, usage stories, stories about use, and all these different things. Help me figure these all out. What are we working with here?
Kim: I agree, there’s a lot of confusion. I hear people using the terms interchangeably. To tell you the truth, depending on what client I’m working with, even the term "use case" seems to mean three or four different things, too. So it’s no wonder there’s confusion out there, right?
Jared: Yeah. Use case has become this sort of generic “How was this used?” I’ve seen use cases that get down to the user will move the mouse over this button and press the left button. I’ve seen use cases which is, yeah, they’re going to log in.
Kim: Yeah. Generally, I find that people are sometimes employing use cases as descriptions of future use. Sometimes I’ve seen them employed as descriptions of current use, interestingly enough. So they’re just sort of documenting current reality as opposed to using them as a design tool.
Jared: Yeah, I’ve seen both of those, for sure.
Kim: I see people often incorporating lots of component detail into use cases. Things like “what’s all the stuff in the list box” and what have you. I’ve even seen people take use cases as far as “and it hits this database table XYZ.” So sometimes there are some backend components in the use case as well.
But, in any case, they’re generally described in a very sort of system-oriented fashion. They seem like very analytical tools, lots of requirements, analysts use them. So, there’s some similarity to scenarios, but use cases are a little bit different.
User stories, also, are not quite the same as scenarios in that they’re, strangely enough, not typically stories. The use case is generally to help scope work and help envisioned a better functionality. But, they’re usually chunks in sort of a development-scope centric way. For example, I’ve seen a use case that’s basically “user logs in,” and that’s about the extent of it.
What’s different about scenarios is, a couple of things. One is that they’re starring personas and not actors. So the idea is that these are not just abstract concepts, but they have some human motivations, goals, emotions and they need reassurance, at different times. They feel not confident about things at different times. So they have some human frailties that, I think, help us envision the interaction in a more empathetic manner.
The other key to scenarios is that they are generative; they’re always about future interaction. At their core, they’re storytelling. So they are about a sequence of events, but they’re from the persona’s point of view.
So they’re always about, hey, why is this interaction taking place in the first place? What’s the trigger? Then, what happens from that point until that persona feels like the situation has resolved until that goal or that task is accomplished.
So they’re typically a lot more comprehensive. They contain more, not emotion exactly, but maybe emotion is a fair word. They contain more human motivation. They’re really used first in a generative fashion and later in an evaluative fashion. But at their core, they’re stories, and I think that makes them somewhat different from these other tools.
Jared: It seems to me that scenarios have really sort of grown in necessity and importance in the design process, primarily because what we’re trying to design has all these new aspects to them that we weren’t thinking about when we were just building something in the past.
When I started in this business, everything started from requirements. So you get these requirements, “The user most be able to log in in order to see their account details.” It never really talked about any sort of contextual elements, things like are they logging in because they’re doing their monthly bills in a relaxed setting, or, are they logging in from a mobile phone trying to figure out what their flight number is so they can get their check in information because Their credit card wasn’t working and they’re late for their flight, and they need all the stuff to just work.
Kim: Where do those requirements come from, to begin with? How do know if having them log in is even a good idea? I think there’s this idea that requirements are somehow sprung like Athena from the head of Zeus out of the brains of product managers or something. Or you go out and you ask users, “What do we do?”
Have you seen that Dilbert strip where it goes something like this, Dilbert says, “We’re going to use our new requirements process to ask our users what to build.” Then in the next frame, you see him sitting down with this wide-eyed farmer in a pair of overalls. He says, “Let me get this straight. For our nuclear power plant, you want free energy and you want to not become a mutant. Is that right?”
So asking our users about requirements is better than nothing, but they really can’t give you good answers.
Jared: Otherwise they would have been designers. Right?
Jared:[laughs] So this list of user requirements, I remember seeing user requirement documents that were hundreds of pages long. I don’t know why people thought this was a good idea.
Kim: A lot of them still do it, though.
Jared: Yes. That’s the thing, it’s really crazy. So this idea of scenarios, and particularly if the scenarios come from personas, right, and that’s what differentiates them from use cases or user stories, to me is really, really interesting.
But it also has this implication that there’s a lot more of this upfront work. And upfront work is something that flies in the face of things like agile, at least on the surface. People who talk about agile talk about, “Well, no big design upfront.” Somehow, that gets morph into no thinking about design upfront.
Kim: Right. Yeah. I think that there are people who are really dogmatic about their methodology, be at agile or RUP or even a design methodology, they have a hard time saying, hey, what’s good and useful in this other method? How does it fill a hole in my method?
I think that this approach, actually, using personas and scenarios, I’ve had work equally well with very structured waterfall processes and with agile processes. The key, I think, is what’s great about agile is that it’s iterative. And that people who are really doing agile and not just following some form of agile, the engineers get that design is going to be a work in progress as well, and they’re very open to change if they’re actually allowed to do agile the way it’s meant to be done.
So that’s all very beneficial, I think, when you’re a designer. What’s challenging is this idea that, oh, designers and developers start at the same point, and coding has already started before you go do and use their research even. That’s not very useful.
Whether you call it iteration zero or whether you call it something else, what I think tends to work very well is when you get to what I think of as, an interaction framework: an initial rough set of storyboards that help you figure out how many screens have we got here and roughly, what’s going on, on each of those screens?
Without worrying about widget detail, but what is the product, so that we can then scope the remaining iterations pretty intelligently from that point on. Yet we’re not making big technology decisions that tie our hands before that point.
If everybody can agree that we follow a reasonably sequential research requirements design process up to that point, then agile your heart out. And it works really well, because then the designers can take on increasingly detailed scenarios and work on chunks of design as developers are working on bits of code.
And that way there’s a much better feasibility conversation that can happen, right? Because throwing a big chunk of documentation over the wall doesn’t work for developers. So I think that’s absolutely true.
Jared: I’ve seen people talk about sort of immersive techniques, like role-playing through a scenario. Have you used that in your work? Is that something you see valuable?
Kim: I think that whatever form works for you is great. I think the fundamental here is let’s all start from a shared understanding of our users, and then let’s use our human intelligence and our ability to understand people’s motivations and use that to extrapolate what would be a great experience later on. And so, as long as we’re trying to get inside the heads and hearts of our personas using a story, who cares exactly what technique you’re using? That’s the fundamental of the method.
What I’ll share in the workshop is some finer details of that that I’ve found works better or worse over the years. But I think as long as you remember that key, you tell stories about the future interaction, and everybody in the team sort of sits there and says, “Do we believe this is the best we can do for this person, to surprise and delight them?” And that’s really the essence. So act it out. Draw it out. Whatever works.
Jared: Yeah, it’s interesting. I’ve been doing this experiment with folks, and it’s a neat little experiment. I’ll have a team together and I’ll say, “OK, on a sheet of paper, I want you to tell me, in bullet-point form, the story of Hansel and Gretel. Just list down the major things that happen.”
So they sit down and they do that. They write these up. And then I say, “OK. Now I want you to do the same thing with a particular scenario of using your application.” And they can’t. What’s even more brilliant is that everybody in the room has the exact same story for Hansel and Gretel. When they have anything, they don’t have the same stories for their own stuff. So I think a big piece of scenarios is this having everybody have the same stories.
Kim: Yeah. They’re great for bringing people together. I think, given that behavior of systems and interaction with complicated systems is inherently a timely activity, right—it’s inherently unfolding in a sequence of events—storytelling lends itself very well to that.
Because what I find, often, when people start trying to design something, is they’ll draw a screen up on the white board and they’ll start laying things out, and they’ll kind of try to think about the screen in every state at once, all at once, and the design ends up just messy and complicated.
Whereas if they start to just draw out little thumbnails and think, “OK, what’s the first thing that our user sees? What do they care about when they’re first arriving in our application, or our product or our store or whatever it is? What’s the first thing on their mind? OK. Well, then what’s the next thing that they want to know?” And then, if they start thinking about it that way, everything just gets much clearer.
The other thing I think scenarios are great for is, so many of the interactions people are designing these days, whether they think about it as interaction design or not, are cross-channel. It’s not just about your website. It’s about your phone calls and your mobile app and your store and a whole bunch of other interactions that people are having with your company as an entity, if it’s e-commerce, or maybe it’s your car dealership or whatever.
And so scenarios, because they’re so much more comprehensive than something like user stories, they really let you see that whole thing as an ecosystem and then start to talk with some of your colleagues in the other silos in the company about, “Hey, here’s how something in your silo limits some things that we might want to do in our silo.” [laughs]
Once you get that shared picture, it’s much easier, I think, to cross those organizational lines as well.
Jared: Now, in an agile space, do you see people taking their scenarios and then cutting them up into user stories? What’s the process there?
Kim: Yeah, I think that works fine. Once you’ve got some comprehensive scenarios to work from, they’re very easy to use as scoping tools, whether you’re in an agile environment or not. So you can chop those up into user stories. You can sit down with a very crude storyboard of a scenario with a product manager and say, “Here’s all the stuff we’d like to do in an ideal world.”
And the developers can say, “OK, and that one thing you’re showing over there? That would take us about three months to build.” And the product manager, or whoever has the purse strings, can decide that it is or isn’t worth three months, and yet you haven’t spent a whole lot of time on it.
But what I think is also really beneficial about scenarios is that it’s hard to have those conversations and have people understand the value of a feature, right? When you say, “How much is this feature worth to our users? How important is this feature in release number 3.75 or whatever it is?”
And once you’ve got a scenario, you can see, “Oh, is that how that feature works?” And it just helps people visualize end state a lot better. Even if you don’t have sketches to go with it, just the story alone makes things more real and just easier to grasp, I think.
Jared: This seems to me to be such a powerful tool, that people, when they use it, they get such benefit from it. And yet I see resistance to it in so many different ways: people feeling like it’s too much work, or they can’t possibly do the research behind it in any time-efficient way.
Yet, once they sort of get past that, all of a sudden it’s like the clouds open up and the light from the heavens comes down. It’s like, “Oh my gosh, why didn’t we do this two years ago?”
Kim: Yeah. Yeah. I use scenarios, even on really tight little projects where research just isn’t a priority, right? And maybe we sit down for an afternoon with some key stakeholders and say, "OK, let’s at least build some shared assumptions about who our users are."
And we do some little provisional personas that are not research-driven but at least give us a starting point about who do we think our users are and what do we think their goals are, and then we come up with scenarios from there. Certainly, we’re not as confident in those, but it’s still a really helpful tool, I think, even in those very constrained environments.
So it doesn’t have to be big and elaborate. You don’t have to document them. On the other hand, if you do work in, say, healthcare, where the FDA or somebody is really scrutinizing where did your requirements even come from, scenarios are actually a terrific traceability tool, if you do get rigorous and document them.
But it really doesn’t take a whole lot of effort. How hard is it for a three-year-old to make up a story? Because storytelling is such a natural human tool that we’ve all lived with all our lives, it’s really very easy. And I think, once people start to do it, they wouldn’t think of going back, usually.
Jared: The projects I’ve worked on, the scenarios, there’s this sort of moment of glee when you’ve got this rich set of scenarios that you can work with. It’s like, wow! I was just working with a team, and the response was, “OK. We’ve just set out our agenda for the next year’s worth of work. These scenarios are going to keep us quite busy. This is fabulous.”
Kim: Oh, yeah. They could set the agenda for the next five years, depending on how ambitious you get. You can say, “Hey, let’s start our scenarios assuming no technical or cost constraints.” Or you can say, “Hey, let’s assume these constraints going into our scenarios.”
I think the other interesting conversation I end up having a lot is, people who have personas that then say, “Gosh, we didn’t really find our personas all that useful.” And I say, “Did you use them with scenarios?” And they say, “No.”
And there’s the problem. I think that personas without scenarios are just not that useful, honestly. They may help you with some prioritizing, they may help you with sort of filtering your requirements, but they don’t really help you visualize design all by themselves.
Jared: Yeah, they’re just these sort of characters that exist in space that you say, “Oh yeah, what about Mary?” Yeah, what about Mary? [laughs]
Kim: If you ever watch the DVD extras or whatever on a television show that you like, you might hear about how, at the very beginning of the show, the creators came up with some character briefs. They had probably one or two pages of back-story about what kinds of twisty little things are going on inside the brains of these characters. And so the writers who come up with future episodes look back at this and go, “Oh, childhood trauma. That will make our character behave this way,” or that sort of thing.
And by knowing what makes the characters tick, they can really have character-driven stories that, once you plop that character into situation X, the story almost tells itself. And that’s really what we’re doing with personas is, once you know what makes people tick, if you say, “OK, we have a situation where they have to buy this, or they have to solve this problem,” once we understand what makes them tick, the story kind of unfolds itself.
Jared: That is exactly what happened. We were working on a project-management tool. And the tool had basically been made for project managers, the people who were coming up with the to-do-list items and assigning them and tracking them and all that stuff.
But as we were doing our site visits and we were going out and seeing real customers use it, we bumped into a whole bunch of people who were the people who actually do the work. And they log in to this tool, and maybe they’re working on six different projects at the same time, so they’re trying to track their to-do list across six different projects.
It immediately became obvious to the team that these guys weren’t being taken care of by the design. That if you’re just a guy whose job it is to figure out what the next thing to work on is and to work on it and then tick it off and then work on the next thing, and to track any new stuff that comes in and to be involved in conversations of details on whatever to-do list items you’re on, the tool wasn’t helping you at all. There were no sort of summaries of all your projects, none of that.
As soon as that became clear, the scenarios behind it became clear. And then what we needed to do for the next year became clear. And they were so jazzed by how clear all this suddenly was.
And the thing is, this is a product that they as a group use every day to manage their own work. But because they don’t have people in their group who are just doers, they didn’t see this, and therefore they didn’t have stories around it. But now they do.
Kim: Yep. And that’s why when you’re using scenarios in a design process, the first set of scenarios you want to do are very high-level, and you want to cover the whole range of personas across any different roles that you might have.
You want to sort of rough out what are all the situations we even need to cover, what things do we need to develop scenarios for, and really look at the entire ecosystem before you dig into more detail on any one persona’s particular scenario.
So for a really complex system, you might have eight or 10 or 12 scenarios just for one persona. You might have 50 scenarios for a multi-role complicated enterprise system. For most applications or websites or whatever, you actually have a lot fewer, so it doesn’t take as long as people think it does.
And the fact is that you’re working on the scenarios at the whiteboard, and you can crank through several scenarios in a day, easy.
Jared: One of the things that I really love about the way you approach this is that there isn’t just one type of scenario. You’ve actually come up with different types for different purposes.
Kim: Yeah. I think that the exact nomenclature and whatever doesn’t matter. You stick names on things so that you can discuss them more easily. I think the key point is that there is kind of your 30,000 foot scenario—that I call a context scenario—that is really about, hey, let’s imagine, in a very systems solution-agnostic way, what this interaction would be like.
And so it’s almost like a conversation between the person and the service or device or system or whatever it is. And you’re really focusing on what kind of information is exchanged and what kinds of decisions get made and how does information move from person-to-person?
You’re not really worried about what screen somebody’s on or what buttons they’re pushing or exactly that sort of thing. But you’re just kind of getting a sense of your overall flow. And so these are very generative scenarios.
Scenarios also though, are useful in evaluation and communication. So as you start to get more detailed, once you’ve got your first pass at scenarios, then you do a pass at the requirements from a user’s point of view and say, OK. Here’s what our scenarios tell us we’re going to need in our system.
And I’m not talking about hundreds of pages of documents with item 13.2.5 list box contains these seven things, right? I’m talking about, "hey, we’ve got to enable users to do this, this and that. Sort of three or four PowerPoint slides worth of big stuff we’ve got to get right.
From there we can start to scope our effort a little bit, and say, “OK, these couple requirements are just not going to fit in our time frame. So let’s do our next round of scenarios in a slightly more constrained way, excluding those few things.”
And so we get a little bit less ambitious and a little bit more detailed, and we start to talk about based on which kinds of information and tools might get used together, then we start to group things into screens, right? All this stuff that gets used together in this part of this scenario, well, it would probably be pretty efficient if that all went on the same screen, wouldn’t it? And so we start to do that, roughing things out.
But after that point, then we start to use scenarios in a very evaluative way, as well as generative, right? Somebody draws something up on the whiteboard and we think, OK, yeah, that looks like a pretty good interaction for this scenario. But now let’s throw a couple of other less common scenarios at it and see where it breaks.
So it’s almost a sort of pre-usability testing without real users. So it goes really, really fast. Because you can say, “OK, persona number two is going to get stuck right there. And persona number three is going to get stuck over here. Or this screen doesn’t allow for persona number one to accomplish this task in our other scenario.”
And so you’re really sort of iterating through the design, using multiple scenarios in a detailed way.
Jared: I love this way of working. It’s so exciting to have these tools, to be able to take these stories. And I love the fact that when you do it right, it’s a group activity. It’s something you guys are creating as a group. And at the center of this, you’re talking about what your users are going to be doing with your application. And you’re bouncing ideas off.
Every time I get involved in these, I find them to be really energizing experiences for the team. And it’s a lot better than many of the design meetings where it’s just, “No, we can’t do that. No, we can’t do that.”
In here it’s like, OK, let’s get really creative here. What are the things we can do? What are the elements that make this happen? And how do we make these guys happy? And walking out of these rooms after you’ve done one of these things, for me it’s like being on a cloud. I don’t know if you’ve had that experience?
Kim: Yeah. I think that scenarios are a lot of fun. I think being an interaction designer, the truly satisfying part for me is when we actually start to draw things out in screens and start turning the stories into storyboards. That’s where I feel the best. It’s like, oh, finally, I can get my hands dirty here.
Yeah. I think that the scenarios start to make things real. You still have to have people in a can-do frame of mind, right? Because you want to start your scenarios with what’s ideal from our users’ point of view and then talk feasibility.
I think some people still have a little bit of a hard time envisioning a future system from just a scenario. So I often find that there are a few people in a larger product team, maybe some of the marketing folks or usually somebody outside of development, who doesn’t quite see where we’re going with the scenarios yet.
And so sometimes you do have to get to that, at least the storyboard point, to start pulling everybody along with you. But they’re powerful that way. And when you combine stories and pictures, there’s really not much that’s more powerful as a communication tool, unless you go all the way to a click-able prototype or something, which is expensive to do early in the process.
Jared: This is all really good. Now you’re going to be talking a lot about this in the workshop. Most of the day is about scenarios and building them and working through them and…
Kim: That’s right, that’s right. We’ll start with a little bit on personas at the beginning, just to make sure our folks know what is a good character for forming the basis of our stories.
But that’s not really the focus of the workshop. It’s really about what makes a good scenario. How do we use them at different points in the process for the most value? And we’re going to practice doing some scenarios. It’s going to be a lot of hands-on time.
We’re going to start out with scenarios in this very broad ecosystem approach where we’re looking at how does an interaction work across software and services and a whole ecosystem of a customer’s relationship? And then we’re going to dig deeper into some more concrete scenarios.
And actually, I’ve got an example using an iPad application. I think that’ll be fun, since that’s a vocabulary designers’ really need to learn, if they haven’t already. So that should be good. Good time.
Jared: I’m very excited about this. I can’t wait to take the workshop and learn more about how to do this and how to do this well. And I’m so glad that you’re going to be joining us.
Everyone, if you want to join Kim, it’ll be at the User Interface 15 Conference in Boston, Massachusetts, on November 8th through 10th. You can find out more information about the conference and about Kim’s workshop at uiconf.com.
Kim, thank you so much for spending time with us today. This has been a lot of fun.
Kim: Always fun. Thanks, Jared. I’m looking forward to the conference. And I hope to see a lot of folks there.
Jared: And I want to thank our audience for joining us today, as always. We love it when you’re here. Please leave comments on our blog at uie.com. And once again, thank you very much for encouraging our behavior. Talk to you soon.