The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #181 Kim Goodwin - Designing Intuitive Experiences with Scenarios

September 7, 2012  ·  37 minutes

Listen Now

Download the MP3

Scenarios are a powerful tool in the design process. They focus on the user experience in its entirety, giving the reason a user is engaging with your product or service. Scenarios allow you to think about the gaps between the experiences. They are great for crossing organizational silos.

Show Notes

Scenarios are a powerful tool in the design process. They focus on the user experience in its entirety, giving the reason a user is engaging with your product or service. Scenarios allow you to think about the gaps between the experiences. They are great for crossing organizational silos.

Kim Goodwin has an immense amount of knowledge and experience when it comes to working with scenarios. She believes that they are the perfect tool as we move into the world of cross-channel experiences. Scenarios provide for a shared understanding within an organization, helping us imagine the ideal experience for a user.

Kim says the key to a great scenario is to start "solution agnostic". When you begin at a high level, considering the whole experience, it allows you to think in more optimistic ways. As you move along through the design process, you can continue to apply scenarios. As they become more concrete and detailed, a more specific solution emerges.

Kim and Jared Spool go in depth about using scenarios in this podcast. You can also check out Kim’s daylong workshop from User Interface 17, now in our All You Can Learn Library.

Full Transcript

Jared Spool: Welcome everyone. We've got another fabulous episode of SpoolCast today, and we have my very bestest, bestest friend, Kim Goodwin, who is joining us from beautiful California. Kim, how are you doing?
Kim Goodwin: I'm doing great, Jared. How are you?
Jared: I'm doing fabulous. I bet you didn't know this, Kim, but you're actually giving a full day workshop at our upcoming User Interface 17 conference.
Kim: Uh oh. I better do something about that.
Jared: Yes, yes. Here's the hint. It's called "Using Scenarios to Design Intuitive Experiences." Today, I thought we could talk about scenarios.
Kim: Sounds good.
Jared: What I thought about, so you and I early on when we were planning the conference we got together and talked about what you wanted to talk about. You used this phrase that really jumped out at me. The phrase was, "staying focused on the big picture."

When I think of scenarios, I'm thinking of the details, getting in there and really defining little details. This idea of the big picture and in particular, one of the things I've been talking about lately with folks is the difference between designing for activities and designing for experience is that you're designing for the gaps between the activities.

It occurs to me after you said that, that scenarios are perfect for that, aren't they?
Kim: Yeah, they really are. There's a lot of talk these days about cross-channel experiences that people are finally starting to focus on. Scenarios are really well suited to that because early in your design process scenarios are about the whole experience.

They start from the reason that somebody is contacting your company or sitting down with your product and goes all the way through to the point where they feel their need is resolved. That could cross different platforms. That could cross different parts of your company.

They might talk to a customer service rep. They might be looking at your website. They might be installing your product. So that scenario at first ideally crosses all those organizational silos and helps you identify those gaps between the experiences or, as you say, between the activities where user experiences tend to fall short.
Jared: Yeah. The thing is that what I'm seeing when I'm working with teams, and you can tell me if you're seeing something different is, oftentimes, those gaps between the activities, what makes them feel disjointed is that things aren't brought from one space to another.

We've all had the experience when we were talking on some customer support line and we get transferred to somebody else. Now we have to repeat all the basic information, who we are, what our account number is, everything we just gave to the person.

It's funny, I was doing a mortgage refinance and I was calling a bank. I went through the IVR and it made me put in my...and it was a bank I already had my mortgage with. It made me put in my mortgage number and all this stuff, select number 17 if I want to refinance. So I do that.

Then it transferred me to this call center and this dude's entire job was to basically have me read my bank statement to him because he didn't have access to my account number. All that stuff I just entered, he didn't have.

Then he tells me, well, he's the pre-screener. His job is to pass me off to the mortgage specialist so could I please hold. Then he passed me off to the mortgage specialist and I was on hold for a second. Then the mortgage specialist gets on the phone and says, "Hello, Mr. Spool." I said, "Hello." He says, "Can we start by getting your account number?" I'm like, "I just gave the dude my account number."

He says, "Yeah, he has all that information but it takes so long to get it from him, I figure I might as well just get it from you." I'm like, "You're nuts."

The thing is, the systems are not designed for this. The individual activities are not designed for this. How would we make scenarios help us with this?
Kim: It always astonishes me. Some of these things that don't get passed from one system to another. You think about how much these companies spend on this IT implementations. Oh, boy.

How scenarios helps with that, if you have a shared understanding of who your users are, whether that's personas or some other model that you like to use, if you think about a real human being and their experience, what a scenario helps you do is take that step back and say, "Here's somebody who got a mortgage statement that's wrong. They want to fix it. What happens in an ideal world after that?"

Then you just describe how they do that with as little friction as possible, and you imagine what that would be like. You might realize, "Oh, my team owns this part. Some other team owns that other part. I guess we better talk to them about how we can make this happen."

The thing that scenarios help you do is look beyond just your part of the problem. That's difficult because you might not have the mandate to solve the rest of the problem, but it at least tells you who you should start talking within the organization and starts to erode some of those barriers that org charts put up.

It's not that anyone intends to create these bad experiences. It's that siloed, sort of naval-gazing that we tend to do based on org charts that causes a lot of the problems.
Jared: What you're using the scenarios is to cross these organizational boundaries and say, "Look, all of these things have to start coming together for us to pull this off."

What's always amazing to me is that IT is at the center of a lot of this. They're the ones who do all the work for all the different pieces, yet that integration somehow seems to miss the mark there.
Kim: Yeah. And I think that, well if you're an IT person, you have a really hard job. Nobody appreciates the work that you do in-house, and a lot of the times they have different incentives. They're focused on, "Let me make this operation efficient" or "Let me just connect this system to the other somehow." As long as they talk, that's good enough.

They're working off of requirements. A requirement just says that somehow these systems have to share information. It doesn't specify that it actually has to be usable by the person on the other end.

The guy who kept asking you for your account number, that system probably met its requirement because it passed that information. It just took it five minutes for it to get there.
Jared: It's intriguing to me this idea of specifying out all the requirements. I saw a blog post the other day from a product manager in one of the product manager discussion groups where he actually said, "I'm not really working on requirements documents anymore. I'm focusing on scenarios and working those out."
Kim: Hallelujah.
Jared: Yeah. I think we're going to see a lot more analysts and product managers and folks moving in that direction because they're just not satisfied with this fact that when you get into the mindset of specifying every requirement, if it's not in the list of requirements it's not there, that doesn't make sure that all those little details are taken care of.
Kim: Well, the other thing is you can satisfy a requirement in any number of ways. That doesn't build shared understanding about what the solution is and how the solution feels to use.
Jared: I like that idea, the shared understanding of how the solution feels to use. When we're talking about experiences for those companies that really want to do great user experiences, that's really what it comes down to. Doesn't it?
Kim: Yeah, it does. If you think about how you want to interact with any company or any product, it's probably a lot like you would interact with another human, right? Part of creating a great scenario is about imagining, "What would a really intelligent, helpful, thoughtful person do in this situation?"

If you imagine your company or your product behaving that way, that's really the key to creating an effective scenario.
Jared: That's interesting. Just yesterday, I was working on a scenario for an article that I had written that had a customer service rep in the middle of it. As I was writing the scenario it occurred to me that it could have just as easily had an automated system in the place of that customer service rep and the customer's experience would have been exactly the same if the system was designed as well.

Because there wasn't anything the rep was actually doing that needed a human touch other than being really smart and really clever and really useful. A good clever, smart system could have done the same thing.

It's neat to me that this scenario really wouldn't need any changing. The actual things that the customer needed and the actual things that the rep ended up doing to satisfy what the customer needed, the system would have done. You could have taken out the name of the rep and put in the name of Siri or any automated agent.
Kim: Sure. I think you're getting at an important point there, Jared, which is when you first start using scenarios early in your design process you want to be solution agnostic. If you're too specific about the technology or the solution that accomplishes the story you're telling it can lock you into a kind of a narrow mindset and you might miss opportunities to automate something you wouldn't think to automate or to use a different tool than you might immediate jump to thinking of.
Jared: But doesn't that create a problem in that you might end up designing something that can't be done on that technology? Isn't there a benefit to thinking about the technology platform?
Kim: Oh, sure, and that's why I say early in your design process. I think the key is... see, scenarios can be applied throughout the design process, as I'm sure you know. I think that the key is to start out very high level and to think about the whole experience in a very optimistic, solution or technology agnostic way.

Then as your design process proceeds and you need to get more and more concrete and eventually all the way down to pixels, your scenarios evolve. They get more detailed. They get more pragmatic. They get more solution specific.

So a scenario isn't just a onetime tool. It's a thing that carries through your whole design process. So, if you start solution agnostic, then, it lets you see the possibilities. Then what you do is say, "Look, there are three or four ways we could accomplish this. Let's talk about some of those trade-offs."

That's where we, as user experience professionals, are going to advocate the one we think is most desirable and the engineers are going to advocate, probably, for the ones that they think are going to be most feasible, scalable, and robust.

The product manager or an executive or whoever makes the call is going to be thinking, "Which of these is most viable? What's going to get me the most bang for my buck, accomplish the business goals best?" and it's going to balance that desirability and feasibility trade-off.

So you do that early in the process. But then when we get down to details, sure, we know we're building on Android version whatever using CSS, using media queries, whatever we're doing.
Jared: One of the things that I've noticed over the years is that you have to dovetail this into a development process. People have things in their development process. Some organizations use UML and they end up with use cases. Some folks are in the Agile space now and they're building user stories.

What's happening there is there seem to be confusion as to when you use a scenario and when you use these other things. Do you have any rules that you've come up with that are really helpful in terms of figuring out when a user story is the right thing? Do you derive user stories from the scenarios? How does it all work?
Kim: Well, I think the first point to make is that a lot of people think all three of these are the same thing and they use the terms interchangeably. I think there are subtle differences.

A scenario is not really a formalized thing. It doesn't have to be written in a specific structure. You don't typically do scenarios for absolutely every single situation. They're not documented in UML. They're about generating solutions for the most part.

They're not incompatible with use cases or user stories, so the beautiful thing about scenarios is you can start coming up with scenarios as you're sketching at the whiteboard. Then as you feel like, "OK, we're converging on what feels like a pretty good solution," then you can start using those more formal tools to accomplish some of those other goals.

Use cases are worth doing when you've got a big complicated Legacy system. You want to make sure that you're teasing out every way that one system connects to another and every field that might change in your database and you're doing a lot of complicated, incremental design.

The thoroughness of use cases is superior to scenarios in that respect. But use cases are so analytical in a lot of ways that they're hard to do early generative design with. User stories, in an Agile process, a user story helps people scope the effort for a sprint.

Scenarios, you don't want to start out thinking about, "Will this fit in my sprint or not?" You want to think about what's the right experience and then let's chunk that into user stories across our sprint.

The tools are absolutely compatible. I think the key is scenarios first and then use that and translate into the other tools to accomplish those other goals.
Jared: Using scenarios first, it feels to me it lets all that sort of creative juice really sort of emerge. That can get teams really excited about this because you're doing a "Hey, wouldn't it be cool if..." In essence, they're storytelling. It's telling the stories of what it's like to be a user.
Kim: Yeah. If you examine a successful design process, any process, whatever you like, it's going to constantly switch back and forth between generative and analytical approaches.

Let's go crazy and think about what we could do. Then let's narrow it down and make sure it really works and accomplishes everything it needs to. Then get back into generative mode.

So, scenarios are great because they tap into a skill we all have. We have all made up stories since we were probably three years old, and we're used to that as an imaginative tool. I don't know about you, UML has never sparked my imagination.
Kim: A requirements document doesn't make me think, "Oh, let's imagine a better future." But storytelling is so easy for anybody to engage in.
Jared: I think UML has only sparked my imagination in that sort of "Office Space, take the fax machine out into the middle of the field" way.
Kim: [laughs] Yeah.
Jared: [laughs] It's something I'd like to beat to a pulp. One of the things that I see, you mentioned this, people get user stories and scenarios confused and they start to use the terms interchangeably.

That feels like a trap that folks run into. What are some of the other traps that I could imagine people run into when they think they're trying to do scenarios but they don't quite get there?
Kim: One of the things I see people do a lot with scenarios is they document the current misery instead of imagining a better future. They're really just saying, "Well, here's how it works and what can we tweak?"

They sort of use the present day as their starting point with a scenario instead of saying, "Look, imagine for a minute, and maybe it's a big leap of imagination in some cases, imagine for a minute that we ruled the world, that we don't have constraints. What would happen here?"

Then at some point reality has to kick in because we all always have some constraint, sometimes very severe ones. So how close to that can we get? So that we're starting off with optimism. That's one trap I see people falling into a lot.

Another is that, I see people getting way to solution specific too early and they constrain their thinking. You know? So someone will talk about photo management software and they immediately say in the scenario, "Oh, she puts her photos in albums."

All of a sudden that suggests all kinds of things about that solution. It suggests essentially that you have a hierarchical file structure. Is that really the right solution? Maybe it is, and maybe it's not, but you've just made a big design decision in your story.

In other words, you, ideally, want to be a little bit more vague in your solutions at first. Now, that shouldn't be a constraint. You don't want that to edit your creativity. It's very easy to say albums and then go, "Oh, wait. I made a design decision" and back off that. It's not a big deal.

The other trap I see people fall into is spending a lot of time documenting every single scenario to the nth degree and then, versioning it seven times as they go through the design process.

You can do that. I think there is maybe some value in it if you have a huge distributed team that all has to all be kept up with things. But the point of scenarios isn't to create a document. They're really a thinking and communication tool.

So I very seldom document the scenarios until fairly late in the process when I'm showing design and using them to explain the solution. I hardly ever document them along the way because it's just a waste of time on intermediate deliverables that don't serve anybody.
Jared: It's interesting that you mention the documentation thing. I have a project I've been working on. You can tell me if we're doing it screwy or not. And in this project, we'll be in a meeting talking about some piece of the functionality and someone will say, "You know what we haven't thought about? We haven't thought about this whole other thing."

Someone in the room will say, "We need to go off and create some scenarios to drive that because we don't have any scenarios for that." We're using the scenarios in this project as our way of tracking, "Have we given everything the thought it needs to have?"

We have this list of scenarios we still need to create and this pile that we are using. That seems to be working for us. Have you seen other folks doing similar things? Is that how you do it?
Kim: Yeah, I mean I think that scenarios are a great way to figure out what's the scope of the thing that I have to build. How much stuff do I have to design? There is always more than one scenario for any product. If it's a pretty simple product, maybe there's just two or three.

I noticed in your article yesterday you talked about the happy path first and then failure paths after that. I approach it the same way. You think about what's a normal case in which everything goes approximately right unless the normal path is always that things go wrong which occasionally it is.

But for a simple products it's just two or three things. If you have a complicated product, maybe there are dozen or more scenarios that you have to design for at first and then you worry about little bitty offshoots of those.

I think of scenarios in a few different phases. Early on, you have what I call context scenarios, things that are high-level, cross-channel, cross-platform, optimistic, what would this whole experience be like? And then, as you gradually walk through scenarios and you get them more detailed and a little more pragmatic as you get more specific, eventually, you do things at the whiteboard that I think of as just little validation scenarios, things that never really get documented.

It's more like, what if this happens, what if that happens, and you adapt the sketch to make sure that you're accommodating those things. And then, you document the design accordingly, but you don't have to document every single variation on the workflow so that you end up with thousands of pages of flow charts and so on, because I don't find that developers actually use those.
Jared: But it seems to me that if we wanted to keep track of some key things, having this list of scenarios that we keep coming back to, that's a useful thing.
Kim: Absolutely, and so one of the things that I tend to do during design is, fairly early in the process agree with the key stakeholders on, what are the big scenarios we have to handle here? That helps us figure out what we have to solve for, how long the detailed part of that design process is going to take, what we need to illustrate to make sure everyone has confidence in the design and it does what it needs to, and then we go from there. So, I tend to lay those scenarios out on a calendar in a lot of ways.

So, you say, all right, we're going to solve for this scenario today, we're going to solve for that scenario tomorrow...Now, that's not only way to chunk work. Sometimes you want to tackle it from a more structural lens, and scenarios aren't the only lens. Looking at things from an abstract structural point of view is a helpful lens, looking at them from a taxonomy point of view is a helpful lens. But scenarios tend to be the driving force in the way I run my projects.
Jared: Yeah, I really like this using scenarios. For the projects we've been involved with, it's the thing...Whenever I feel like we're running into a stumbling block my first thought is, "Damn, we're not using a scenario to help us figure out how we get through it." We're mired in technology details or business rule details, or some set of constraints that feels like some sort of weird-ass wicked problem to us, when in fact the problem is that we haven't really asked, what's the thing we're solving for? What is it?

It's funny. I was giving a talk earlier this week and this dude comes up to me after the talk and he says, "We have a question we've been dealing with at our place, and maybe you can help shed some light on it." He says, "Is it still the case that you should have a link at the top of your page that says "home," or are users smart enough now that they can get back to the home page by just clicking on the logo?"

I thought about it for a second and I said, "What's the scenario that is driving someone being on a random page in your site and suddenly needing to go to the home page?" He looked at me and he said, "We haven't talked about that, I actually have no idea."

And so, here they were having this huge debate about this detail, this thing, and they were having this opinion war of things of, our users are smart enough, our users aren't smart enough. It was tied to their organization, and no one was stepping back and saying, "Who cares?" [laughs]
Kim: Yeah. Well, hopefully, you know your users well enough that you do know whether they're smart enough. But I agree, they may be solving the wrong problem. I use scenarios that way a lot. Someone will say, "Well, it should have this button on it, or why doesn't it do this, or why doesn't it work that way?"

And then, I always bring them back to two things. Which user are we talking about, and can you tell me what scenario would actually call for that to be there on the screen? Most of the time, people can't come up with one. Occasionally, someone will say, "Well, it's this important scenario that we just haven't accounted for."

And then I think, "Oh, yes, that's very important." And, we adapt the design accordingly.
Jared: This is a question that I'm really interested in. How much do you use your gut feel about how confident you are about the scenario you're creating to drive a request for going off and doing more research. I can imagine there are times where it's like, you feel like you really know what's in your user's head, so you just create the scenario and it just feels right.

There are other times where you get halfway through the scenario and you're like, I'm just making stuff up here. I need to go figure out if this is really what people do. Do you run into that in all the work you do, or is that just me?
Kim: Well, I will say that if we've had the opportunity to do a good set of ethnography upfront, I generally don't run into that. If we've made some compromises in the research along the way, or if for some reason, we miss something in our initial research planning, then yeah, certainly I've had that happen.

The thing that tends to happen to me more is, as we get a little deeper into design and we're working on detailed stuff, if it's a complex domain like IT or finance or medical care or something like that, there will be things that you just can't dig out of user research that easily about, well, how is a prescription structured. What are all the different types of data that could be there, and so forth.

And so, in those kinds of domains, I do tend to turn to subject matter experts and pick their brains for an hour or two, and then go back to the scenario driving the sketching. So, certainly there are cases where just the user research isn't quite enough.
Jared: Right, I could imagine. We have this distinction between folks who are doing self-design, they're designing based on their own usage patterns, and people who are designing for other people for systems that they wouldn't use themselves.

I could imagine in self-design the scenarios might be easier to come from, because you're just looking inwards and saying, well, what is it that I need to do with this? Whereas, when you're doing that activity-focused design or the experience-focused design and you're off creating things that you yourself wouldn't use and that you have to rely on subject matter experts, you have to rely on research, that discomfort of, "Hey, we bumped into something we don't have enough data on right now," probably emerges a little bit more.
Kim: Yeah. That's why I'm a big fan of bringing team members along into the field research so that they get some of that direct exposure.

I generally ask my clients that if someone's going to join me for research that they do about four sessions so that they start to see a little bit of...They see the variation and they also see what people have in common because that, to my mind, is about the minimum for people to start to see some patterns emerge. If they only go to one user interview then that user sort of becomes all users to them. That user might be sort of weird.

And so, that's enough to get them a bit more out of themselves. The scenarios become so much more real and so much easier to work with as a team when everybody's got some shared basis.

If I have gone and done research on personas and they're just reported back artifacts then scenarios still work but they're less effective. They're less powerful when you don't have that shared basis as a team.
Jared: One of the things I've seen, you can tell me if you've seen this, is that if you can get people to go to four sessions and let's say the whole research project, because of the way it breaks up, you probably do eight or 10 or 12 sessions. But any given person on the team has only managed to get to four.

They're more willing to accept what happened in those other sessions that they didn't go to because they saw the variation in those first four and they said, "Oh, OK. Obviously, each one of the first four I saw were different so it doesn't surprise me that the fifth would be different, too, and the sixth one would be different.

And so, you can bring variations in and you don't get that sort of hard and fast, "Well, I've never seen that. It doesn't happen," type argument.
Kim: I agree with that. The other thing is that if you say, "Here's a pattern we saw, something that almost everyone did," they can refer back to the couple of people they saw and say, "Yeah, actually everybody I did see did that, even though I thought it was weird." So they're also more willing to accept the patterns.
Jared: Yeah, that makes perfect sense.

That's interesting. How much do you use scenarios when you have those types of patterns to try and put some rationale behind the patterns? Let's say you do go out and you see something that users do that's pretty weird. It's definitely not something I would do but every single user would do this type effect. Do you try in instilling that shared understanding to create enough context in the scenario to explain why that keeps happening?
Kim: Well, scenarios are not really about documenting what's happening today, so I wouldn't say that I ever use scenarios to explain today.
Jared: That makes sense.
Kim: Personas are about explaining today. So you know, in a persona description, I might say, "And today the persona does this because of that." Certainly, when I see weird things during research, I'm always digging to try and figure out why are they doing that.

For example, on one project I was doing...Back in the days when EMRs were this new thing, so it was a while ago, I saw this nurse who was translating all of these paper records into Excel spreadsheets. She had created some home grown reports. This was a lot of work because she was doing this every couple days.

I said, "It looks like that's a lot of effort. What's that accomplishing for you?" She said, "Well, it's helping me figure out if we're taking good care of people because if we're not, certain things tend to show up." She said, "What's really hard to figure out is sometimes people are getting bed sores or whatever because of some drug that they're on and it's not really our fault. Those are really hard to tease out."

What was evident to me there was transcribing all this garbage was not her goal. Her goal was to take better care of people and to understand where there's an opportunity to improve and where is it just something that's going to happen. That led us to a really great clinical trend spotting and analysis tool that was really well received when we showed it to people.

That was a case where there was this mysterious behavior but the reason for it really led us to some great scenarios and some great sketches. I think that's more about communicating what you see in the research, showing people the opportunities that then lead you to develop better scenarios.
Jared: I've had the exact same experience. We were doing a project management tool and we were so focused on people adding things to the to do list, managing the current state of the to do list and keeping track of the project that we neglected that there was a whole group of people whose job it was to log in every morning, see everything that's been assigned to them, and then just check them off.

They never added anything to the to do list. They never look at the big picture and said, "Are we doing all the right things?" because they were the dudes doing the work.

Because of the way the tool was constructed, you could have more than one project. In some cases, because it was a cloud based thing, companies would purchase a license in this. Some of these people who worked on this stuff were contractors and they actually had multiple clients that they were working. So not only did they have more than project but they had more than one company that had more than one project.

There was no way for that person to get a list of everything they needed to do today. They would have to log into each company sequentially, log into each project, and look at the individual to do lists that they'd been assigned within that.

As soon as we saw that pattern happening, we met those people one after another in visits. Instantly, it was obvious we had to come up with a, "Hey, I just want to see a list of everything I've been assigned across everything that I use this system for."

It turned out to be, technically, a really complicated thing to do but the UI, the end user experience, has been the most well received feature of their new version. It's just incredible and the people are like, "Yeah, the everything page. That's awesome." That's what they ended up calling it.
Kim: What you just described reminds me of another trap I see people fall into with scenarios a lot. That is that they try to build scenarios with roles. The problem is that a role is basically just a job description. It's human as functional component. A role isn't very human.

A role doesn't really account for the kind of organizational variation you see. It doesn't really account for the fact that people work in somewhat different contexts, different sizes of companies, different cultures, what have you. A role just has no human qualities. It doesn't have anxieties, goals, and emotions. So it's very difficult to tell a compelling human story starring a role.
Jared: That's really interesting. But, yet, user stories are often written. As an administrator, I want to be able to check the status of my chron job.
Kim: Yeah, well that's the irony of user stories being called stories. They're not really stories. They're snippets. A user story, because it's so focused on scope, usually doesn't have much of a plot.

It doesn't really tell you where somebody was before they got there, and it doesn't tell you what's happening next. I see a lot of user stories like, "User logs in." Why? What are they doing after they log in? How many times have they logged in before? Should we know who they are already?

I think that Agile focus, for all the things that there are to love about Agile, and there are many, what I very, very often see with Agile teams is that they are so focused on the piece meal development that they really lose sight of that big picture.

Scenarios in an iteration zero especially can help everybody understand how those pieces are supposed to fit together. But, yeah, roles don't work so well. They don't really help you with the kind of empathy and specificity that you need to develop a good story, story.
Jared: So coming up at the User Interface 17 conference, you're going to help us just get past all of these crazy things. You're going to help us get past just focusing on roles, adding in this empathy, adding in this great functionality and using scenarios to drive out design process. Help us across all the different channels and platforms and things that we're working on.

I'm really excited about this workshop, spending a full day. Last year, everybody reported that it was really the highlight of their conference when they took your workshop. I'm really excited you're back.

For those of you who are listening and really loving all this, you definitely want to try and get to User Interface 17 where Kim will be doing Using Scenarios to Drive Intuitive Eexperiences. You can find out more on the conference site, which you can get to at

When you go there, we didn't have a scenario that forced you to log in, so you know what, you don't have to log in.
Kim: I'll look forward to it, Jared.
Jared: Kim, thanks today. This has been an awesome conversation. I love talking to you about this stuff.
Kim: Likewise. Thanks a bunch.
Jared: I want to thank our audience again for spending the time listening to us. As always, thank you for encouraging our behavior. If you are listening on the iTunes, take a moment. Go and give us a review. We always love to hear what you have to say.

If you're listening off our site, leave a comment for us. We love talking to you there. See you later. Take care.