Now, we're going to take a look at user experience analysis and planning methods, the individual tools that we'll use when we're developing the plan and preparing for the kickoff of a given user experience effort. I'd like you to understand how you would select these methods. It's also important that you know what the tools are and that you're able to apply each one of them. You'll have an opportunity for a couple of them as we go into the project that goes along with this module. So these are some of those selected methods from a lot of different user experience sources that we're going to take a look at for the analyze and plan phase. We'll look at some project-definition tools like the project plan, the overview, the brief. We'll talk about stakeholder interviews and we'll talk about some communication methods like elevator pitches, artifacts from the future, the Pecha Kucha, the Kano model for discovering what's important in a project, and then what we use to kickoff meeting for. We won't talk about work breakdown structures in this lecture. We'll talk about it in a follow on lecture because there's a lot to go over for that one. When you're picking your methods, really, you want to think about what's appropriate to the time and the resources and the goal you have for what it is you're trying to do. Whether it's communicate, learn more, plan the project or get authorization. You'll have to decide what fits your project and then create a plan that matches that using some of the various methods that we're going to go through here in a minute. The first method we'll look at is a traditional project plan. This can take anywhere from a few hours to multiple days to put together depending on how detailed the effort is. You certainly use it for planning but it can also be used to communicate what you're doing and to get authorization. Whether it's a UX centric effort or whether it's an overall engineering effort, putting a plan together that looks at scope, objectives, schedule, how you're going to deal with change, how you're going to measure success, that's really the goal of this method. It could feed into project management flow like Scrum or Kanban, but basically, you're just detailing out what it is you're going to do, and how you're going to do it. The next method is a project overview. It's not quite as thorough a document as a project plan might be, but again, it can vary as to how much detail you put in here. The example that I have shown here is from a template on usability.gov. Again, you're just trying to outline what your activities are and be able to plan what they are and then communicate them to a team or to stakeholders. In this one, we're going to focus on background, the purpose of a project, what we're going to be doing, and what we expect to get. A project brief is another way to create a summary of a project plan. It's even simpler than an overview. Usually, a brief would only take a few hours to put together. It's intended to be a poster-size graphic that has selected topic sections like the requirements, project vision, the design elements, etc. Your goal for this one is to be able to post it publicly and allow for people to talk about it and understand what your project is and why you're doing it. One of the most important methods that you have is interviews. A lot of times these are called stakeholder interviews or individual interviews. Buley calls this a Listening Tour in her book, and she identifies it as the most important method in the phase. That's probably true because really what you're trying to do is, move through the stakeholders and the users and the people that are involved in the project and understand what the priorities are, what support you have, and learn about what the project is going to entail and what issues you might have. When you do these interviews, ideally, you want to preselect who you're going to talk to, although, that may change depending on what you learn. You're also going to spend a little bit of time to create a question list and then go through and conduct the interviews. You want the interviewer to be brief, maybe no more than an hour, maybe closer to half an hour, if you can. You want to respect people's time. It can be done remotely. You can do this by phone or by web conference. It's important that you take good notes, that you take some time to review what you heard, and that you go back and thank the people that you interviewed and then you share the results with them. This really is one of the most powerful tools you have to understand what you're getting yourself into in the project. A Kano model is an interesting approach, and what you're trying to do here, is understand more about some of the features that are being specified for the project. What the Kano model does is, it divides features into delighters, satisfiers, basic needs, and things that people might be indifferent to. You ask two questions about a given attribute for a product. What would the satisfaction be if it has it? What would the satisfaction be if it doesn't have it? There is a set of answers that you're going to use for this. The Kano model ends up looking like this, where you can separate out delighters from satisfiers from basic needs. It really is a great analysis tool to help you understand what needs to be in your project and what doesn't need to be in your project. An elevator pitch is a very simple communication tool. You can put one together probably in just a few minutes. The elevator pitch exercises to create a very succinct differentiating statement that you would use, that talks about your project and what you expect to do. You can use it for UX projects, of course, you can use it for anything that you need to convey quickly and cleanly. The first time I heard about elevator pitches, the president of a company I was working for was visiting. We were warned that if we ran into him, he might ask us what we did and that we should be prepared to talk to that. So when you're creating an elevator pitch, you want to identify your goal for what you want to get across, figure out how you're going to communicate it, make sure it's unique. Then at the end of it, if you can, engage with the questions so that you can start a conversation. There's lots of references available for this. I pulled one from a web page called Mind Tools. Here's an example. "My company develops wireless devices for security applications. Our primary focus is on ease of installation. Unlike wired systems, our products can go anywhere, and usually in half the time a wired install would take. How does your business deal with security device installation?" The key here again is just don't end with a yes or no question. Leave something that's open-ended to encourage discussion. Similar to an elevator pitch, there's the PechaKucha presentation. This one can take a little longer to prepare, but it only takes six minutes and 40 seconds to present, because it's a timed PowerPoint presentation of 20 slides at 20 seconds per slide. There's an organization that holds PechaKucha Nights. It's actually a trademarked activity. But you can use a PechaKucha approach to create a brief, compelling statement that you would use to present a project quickly if time was limited, but you wanted to get people interested and come back to you to ask questions. I think it's a very interesting way to do communications in a very short amount of time so that you don't tie people up. Another communication approach that's popular is the Artifact from the Future. This is often used especially with devices to try and find some way to give some idea of what it is you're driving towards. The artifact in question that you design, which could take hours or more depending on how complicated you make it. It could be anything. It could be the box that your device comes in. It could be ads or videos. It could be a fake product review, or it could be a mockup of whatever the thing is that you're making. Your goal here is to give people a chance to think about what this product is and how it should eventually achieve its goals, and how people might think about it. It will open up chances to discuss the project, and that's really what you're hoping for here. The most common way to get to the end of the analysis and plan phases is a kickoff meeting. These meetings can take anywhere from an hour to a whole day, not to mention the preparation for the meeting. You really want to communicate what your project is about, and you might use the same meeting to get authorization. You might also use it to update the planning that you're doing for the project. For a UX based project, you really want to focus on what the work is, who's the audience, what tasks there are, what issues are there to solve, what's the business case that supports this effort? Then go through your project plan, however you did it, to talk about the scope and the vision and goals for the project. This really opens you up to moving into the next phases of research and design. But it's important to get through this gate and make sure that everybody's on board with what it is that you're going to be doing. So looking at these methods, hopefully you can see some that you might use if you were in a project or starting a user experience effort, depending on the resources that you have and the situation you're in. Think about which ones seem useful to you and which ones you want to dig into more. Again, there's one more method that we're going to look at in some detail, work breakdown structures, which I think is a really useful approach to looking at what the deliverables are for a project, and defining it well enough to control. So that's up next. Thank you.
