It can be hard to build relationships with users when you think first about the message you want to convey or the transaction you want to enable, because a great relationship isn't about the story you want to tell--it's about the story your users want to experience. Kim Goodwin will show you how storytelling can help your team resist an analytical, me-first mindset by getting inside users' heads.
Lately: working on org change\nPreviously: ran Cooper, 12 years there\nIn-house creative director\nA few significant Web sites, but mostly interaction & visd for products & services\n
Which is why when Kristina asked me to speak, my first reaction was “Really?” But of course we’re all here to create a great UX in the end, so the more we can share tools and ideas across discipline,s the better.\n
Certainly we have some shared challenges.\n\nWe need to generate ideas based on how users think and behave...\n
...we have to get everybody moving in the same direction...\n
... we have to get organizations to deliver what their users need, rather than forcing users to assimilate what the organization wants to feed them...\n
And perhaps the hardest thing we have to do is break down the organizational silos, so the content and the experience are a seamless whole, instead of exposing the world to what Tamara Adlin would call your corporate underpants.\n
So today I’d like to share with you the tool that I find most helpful in accomplishing all of these things, and that’s storytelling. I think this is a tool designers & content strategists can use to find common ground.\n
Interactions with Web sites & products follow an arc, so stories help us think through: what do users know when they start, what information do they consume first, what do they do or learn later in their natural process.\n
The beauty of stories is that they are natural generation tools. We’ve all spent our whole lives telling stories, and as kids, we used stories as a way to fire up or imaginations. This makes stories a great generation tool.\n
Finally, stories make excellent communication and persuasion tools, whether that’s a story about the data that led us to a particular solution or the story of someone using our imaginary future tools and content. \n
In design, a story about future use is called a scenario. A scenario is a plausible story about a persona using the future tools in a specific situation.\n
If you’re familiar with use cases or agile user stories, scenarios aren’t quite the same thing. Unlike those other tools, scenarios have all the elements of real stories.\n
Unlike use cases or agile user stories, scenarios don’t use task-based roles. Just because two people are performing the same tasks, that doesn’t mean they think or behave the same way. Like real stories, scenarios are driven by characters who have certain skills, goals, needs, feelings, and ways of looking at the world. \n
In interaction design, we call our characters personas. These are derived from behavior patterns identified in field research. If we were designing a car Web site, for example, we’d find that some buyers focus on features and value, some on performance, and some on other things, like “Hey, it’s cute! If it comes in red, I’ll totally buy it.” There are almost always at least two patterns, sometimes more, which is good because an overly narrow focus can lead to an inflexible solution. \n
Personas are described as if they were real people. They get names, photos, and descriptions that include how they approach their tasks, what skills they have, what drives them crazy, and what their ultimate goals are. For example...\n
Each persona has a few key goals that drive behavior. These focus on what they *really* want to accomplish and how they want to feel.\n
The second story element is conflict. Without some problem to solve, there’s no story. \n
Robert Fabricant from frog pointed me to a lovely example of this: If I tell you “The cat sat on the mat,” that’s not interesting. If I tell you “The cat sat on the dog’s mat,” suddenly there’s a story there. So once we understand our characters in the form of personas, we outline the problems they need to solve. Each of these situations becomes its own scenario describing future use. \n
Robert Fabricant from frog pointed me to a lovely example of this: If I tell you “The cat sat on the mat,” that’s not interesting. If I tell you “The cat sat on the dog’s mat,” suddenly there’s a story there. So once we understand our characters in the form of personas, we outline the problems they need to solve. Each of these situations becomes its own scenario describing future use. \n
So imagine we’re creating an airline experience and one of our personas is someone who travels often and has some specific needs. For example, a pro photographer sometimes foots her own air travel bill and can sometimes expense it to a client, and she’s concerned about having carryon space for her gear. \n
So imagine we’re creating an airline experience and one of our personas is someone who travels often and has some specific needs. For example, a pro photographer sometimes foots her own air travel bill and can sometimes expense it to a client, and she’s concerned about having carryon space for her gear. \n
These are the conflicts we have to resolve.\n\n
Our third story element is plot. This is where we start inventing solutions, telling the story of what that ideal future interaction would be like. \n
Some people get a bit concerned that at this point we’re just making stuff up. We are...and yet we’re not. All the best stories in the world WORK because on some level, we recognize them as true. Understanding what makes people tick helps us extrapolate what they’ll love (because people can’t tell us what to design...or write). It’s kind of like buying a gift or planning an event for a friend--if you know them well, you just KNOW how to delight them.\n
So let’s see how this all comes together. Let’s imagine now that we’re designing a kitchen product--a dedicated device that serves as both cookbook and shopping list manager. Let’s say one of our personas is Trish...\n
\n
So one of the scenarios Trish will encounter is the need to feed her family NOW. So we imagine at a high level what that interaction might be like...\n
\n
\n
\n
\n
\n
Notice that the scenario isn’t yet providing specific solutions. We’re considering what KIND of information is exchanged, but not getting into detail about the content or the input and output mechanisms. \n
This is because our goal at this point is not to have all the answers, but to get consensus that yes, this is approximately how the interaction should go. This helps us avoid a lot of thrash and design by committee.\n
You might also notice that we’re initially looking at the world through rose colored glasses, not worrying too much about constraints. This helps us push for better solutions.\n
To encourage that optimistic mindset, we generally start out by imagining what a magic black box or a really helpful human assistant would do. In content terms, I suppose you might think of who your Web site is: an irreverent friend, an easygoing teacher, a respectful waiter...what would this person know about the user already? What would they learn from previous actions? What information would they provide, in what sequence and tone?\n
It helps to generate with a partner. This accomplishes a couple of things--one is that two minds are more creative than one. Studies actually prove this out (Amabile et al). The other is that a partner (who joined you for research) can help keep you true to your data, so you’re continually refocusing on the real user needs and not on what’s convenient for the organization. \n
Our final story element, of course, is resolution. The persona’s problem is solved and he or she is happy. Here’s another thing that makes scenarios work so well: the scope of your problem-solving is determined by what USERS see as a complete interaction.\n
\n
This is a great silo-buster because users seldom think of their interactions cut into little pieces based on how your company or client is organized. By telling the story from start to finish, you make this very clear...which, among other things, makes clear the need for cross-silo governance. \n
For example...\n\nSo it even becomes clear that user interaction is cross-channel, often not just limited to a Web site...so your strategy had better be cross-channel, too.\n
So...if scenarios are starting to sound interesting but you’re worried about how they fit with a process that already employs user stories or use cases, it’s not a problem. The tools can play nicely together--just do scenarios first.\n
\n
As we progress from pretty rough ideas through final design, we keep using scenarios. They start off optimistic and high-level like the one you just saw, but gradually get more detailed and pragmatic. They’re not necessarily documented; sometimes we just talk through a “what-if” story as we’re sketching at the whiteboard.\n
As we progress from pretty rough ideas through final design, we keep using scenarios. They start off optimistic and high-level like the one you just saw, but gradually get more detailed and pragmatic. They’re not necessarily documented; sometimes we just talk through a “what-if” story as we’re sketching at the whiteboard.\n
As we progress from pretty rough ideas through final design, we keep using scenarios. They start off optimistic and high-level like the one you just saw, but gradually get more detailed and pragmatic. They’re not necessarily documented; sometimes we just talk through a “what-if” story as we’re sketching at the whiteboard.\n
As we progress from pretty rough ideas through final design, we keep using scenarios. They start off optimistic and high-level like the one you just saw, but gradually get more detailed and pragmatic. They’re not necessarily documented; sometimes we just talk through a “what-if” story as we’re sketching at the whiteboard.\n
As we progress from pretty rough ideas through final design, we keep using scenarios. They start off optimistic and high-level like the one you just saw, but gradually get more detailed and pragmatic. They’re not necessarily documented; sometimes we just talk through a “what-if” story as we’re sketching at the whiteboard.\n
As we progress from pretty rough ideas through final design, we keep using scenarios. They start off optimistic and high-level like the one you just saw, but gradually get more detailed and pragmatic. They’re not necessarily documented; sometimes we just talk through a “what-if” story as we’re sketching at the whiteboard.\n
As we progress from pretty rough ideas through final design, we keep using scenarios. They start off optimistic and high-level like the one you just saw, but gradually get more detailed and pragmatic. They’re not necessarily documented; sometimes we just talk through a “what-if” story as we’re sketching at the whiteboard.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
So...if scenarios are starting to sound interesting but you’re worried about how they fit with a process that already employs user stories or use cases, it’s not a problem. The tools can play nicely together--just do scenarios first.\n