Lessons

Lesson Info

Scenarios & Frameworks

You've done your research. You've turned the research into a set of people who represent your research that you can then use to focus discussions around. Now the next step is imagining-- Like what's the story of how people are using this product? Scenario was just a description of how a persona accomplishes a goal. And it's a written story where you're just imagining yourself in the shoes of your persona trying to accomplish something. And the key here is that you are imagining the ideal user interaction. Like the magic wand, perfect way of accomplishing something. You're imagining that out of the shoes of this person, focusing on their goals. You focus on their goals, on how they think and behave, rather than restricting yourself by technology too soon. Why is this effective? Well, because storytelling is the oldest form of knowledge transfer. This is how knowledge has been passed on throughout generations. You'll even notice that throughout this presentation, the parts of the segment...

s where I told stories, it probably sunk in better than the ones where I'm just broadcasting theoretical information. So it's always good if you tell stories. It just engages your mind. It engages your imagination. Makes you think about more than some kind of feature set. It's also social. Again, when you're early on in the process you want to get everyone involved. You want to make them feel as if they're contributing. Engaging them in that storytelling process is an easy way to get people involved in the process early. And it's fast. It lets you focus on the high level design solution rather than, "Ooh, do we use a blur here? "Is this shadow just right? "How long should this animation be?" Just focusing on the high level goals. So some examples are Jenny wants to sell her car. Standing in front of her car, she opens eBay Motors app. She takes a picture of the VIN and her registration, and the program automatically fills in the information about the car. She takes a few more pictures of the exterior and interior of the car, and then posts the ad online. This whole process takes less than 10 minutes. So you notice there's a format here. You have a persona, Jenny, that you created in the previous process. You have a problem, a goal that they're trying to accomplish, a problem that they're trying to solve. And then there's a journey of how they got to a solution. And then there is sort of the resolution and payoff of this journey. Another example. James can't find his iPhone. He opens the Find iPhone app on his Mac. He sees in the app that the phone is very close by. He then uses his Mac app to make the phone play a sound that makes it more easy to pinpoint it. James then follows the sound and finds his phone. So it's that same structure. Problem, journey to a solution, payoff. It's the classic storytelling arc. These are very basic examples. Scenarios don't need to be that short. And typically they're actually not that short, they're a lot longer. But it's all about understanding the problem. The journey to a solution without overly focusing on technical details. Or step by step processes. Like you'll notice, there isn't-- There aren't detailed step by step screens that you're following to get to a solution here. That's another part of the process. There's just this general high level story of how cool it would be if this thing existed that could solve this problem. These stories are quite similar. So this process of coming up with high level stories is not unique to interaction design. It's actually quite similar to the storyboarding process in movies. This is a Pixar storyboard for Toy Story. And you'll notice that it sort of outlines the general gist of the story flow. But doing these sketches is a lot less time and labor intensive than the super high quality renderings of the final movie. You can sketch this out in a couple of hours, but it will take months to do a final version. And at this point you're still super broad and you're just focusing on the general plot. And in fact, designers that are capable of drawing-- I'm not one of them-- but they will create storyboards for themselves. And storyboards that sort of explain the process of how this app that they're making solves the problem. And this is really just a matter of taste. When I create scenarios, I write them out. But I know a lot of people that love storyboards. The point here is just no matter whether you draw it or whether you write it out, you just want to focus on the general story of what you're trying to accomplish here. What's the problem, what's the journey to solving it, and what's the payoff. Something to remember is that... So again, coming up with super high fidelity stuff takes a long time. And you want to avoid putting in work that you don't end up using in the end. The best designers, they all stay in the lowest possible level of detail for as long as possible. What most non designers associate with design, which is that final, polished thing? That's a very small part of the whole that the good designers all try to push out for as long as possible. They try to narrow down all of the details before they end up spending all of that time creating that highly polished thing. That's not always possible to do. Like in some cases you do need to build really high fidelity stuff over and over again. For example if you're dealing with executives that have no capacity for abstract thought. But most of the time you can stay in a low fidelity for a long time. So it's just all about facilitating a discussion and communicating needs before committing to this super detailed work. Anyone that's tried to design a user interface in Sketch to the pixel level detail knows how long it takes. And how long it takes to make changes. And how you end up getting hung up on tiny details rather than the overall flow. So you're trying to avoid that early on until you get agreement on the flow. Scenarios are also important because based on those scenarios you create the requirements, and the interaction framework. Requirements are what data are we going to need for this, what functionality are we going to need, what's the context. Interaction framework is which device is this going to be on? Is it going to be on a phone or an iPad? How are we going to group the pieces of content on the page? Requirements. This is really asking this question of what information and capabilities do our personas need in order to accomplish their goals. It's really critical to define this and agree on what that means before you jump into the next question of how the product looks, and how it behaves. Because a lot of designers, junior designers, are tempted to jump right into detailed designs, and just render solutions right away. Because yeah, a lot of times when you hear a problem you automatically have a few thoughts of how you could solve it. Your first instinct is to go for that solution. But if you're proposing a solution without clearly defining a problem first. I mean, what method do you have of evaluating the design afterwards? I guess another one of those cases where if you do that, you'll end up in meetings with stakeholders where it just turns into a debate of, "I like this better. I like that better," and no one can really say why. So then the person, the CEO who cuts the checks ends up being the person who makes the decision of how the design goes. But if you can focus it around the needs and capabilities of people that you're designing for, that you've made more concrete with personas, then you've got something to talk about. Then you've got leverage against the person that cuts the checks. When you're creating requirements, there's two steps that you do before that. First look at the personas again. You try to put yourself into their shoes and identify what their expectations are. And then you look at the context. And then you create the requirements. And some questions to ask here are things like, what data do we need? Do we need addresses? What kind of images do we need? Do we need songs? Do we need dates? What functionality do we need? Do we need to give them the ability to create their own account, to sign in. Again, of course, always wondering about the context. Then looking at whatever the technical restraints are. Because remember, you almost never get a chance to design something from scratch. There's always going to be something there before that you have to consider. So just asking these questions around requirements. Of course the interaction framework, where you're sort of deciding, are we going to use it on a phone? Are we going to use it on a tablet? Or is it going to be a terminal? Or is it going to run on a laptop? And then these questions, these next few questions around what data elements represent the data, what are the key paths. These are definitely important questions. But in my experience, these aren't questions that you always ask yourself consciously. Unless you're working in a big team and you have to have formal processes to communicate ideas. Usually in real life, when I get to a point where I've done some research, and I know the personas, and I've sketched out some scenarios that I imagine how the personas will be using this product, I can figure out the requirements and the interaction framework on the fly while building out wireframes and prototypes. Of the stuff that I just talked about for me-- I mean that works well when you have a big team and you need people to sign off on stuff. But what I've seen work much better in practice for me and a lot of other designers is after you've got the scenarios, just start building prototypes. That also works better for most non designers too, because in my experience, a lot of these other tools... I mean, designers have a lot of tools and techniques to wrap their head around a problem, but in my experience the only thing that non designers understand is a prototype. When you show them that, then they'll be like-- Like if you show them a requirements document they'll be like, "Yeah. I guess that's all accurate." If you show them a prototype they'll go, "Oh yeah. Okay, that's good, "but we also forgot about this, and this, and this," and now you've got a discussion that can move forward quickly. Again, after I've got the scenarios done a lot of times I figure out the frameworks and requirements kind of on the fly while building super low fidelity prototypes that I can iterate on quickly. When I'm designing a solution or a storyboard based on a persona, I usually find it really helpful to have personas based on user interviews. So actually talking to the users, just so I can get a better idea of their emotions and kind of their core emotional needs. So I guess my question is how would you design based on an assumption persona without really having talked to a user? And how do you validate your, I guess storyboard, or maybe solution, if you haven't actually talked to them. Very valid question. Yeah, I mean, assumptions can be very wrong sometimes. The advantage of that process with the assumption personas is the speed. The downside is the lack of accuracy. And there is a very real risk of you ending up designing something that's totally off base because you're just designing off of what you might think someone wants. So that's why it's important to validate those assumptions. But the thing is, again... I mean, you've got some voices in the design industry now that are literally saying user research in this form that I just talked about is totally overrated. Just build out some prototypes and test them. Which is like a super extreme version of lean, agile process. I guess the thing is you sort of figure it out through trial and error. Once you've made your assumptions, you try to find people that fit into that assumption bucket and test with them. And if you're wrong, then you just iterate based on that. But the advantage is that it doesn't take you months, or weeks, to come up with good personas. You can just hop into the nitty gritty of making low fidelity prototypes a little bit faster.