In this lecture will introduce the user experience analysis and planning phase, the first of four phases in the process that we're using for our user experience design efforts. I'm hoping as we go through this, you'll understand why this first phase is so important. We'll look at some of the variation in how people approach this phase, the content in the different approaches for starting projects. We'll look at what elements are key for user experience projects in particular. And we'll talk a little bit about multidisciplinary teams on user experience projects. So just a couple of definitions, when we talk about analysis we're really talking about trying to dig into the nature of a design in order to figure out what it is we have to do to bring that to fruition and to be successful in a delivery. So we want to do a very thorough study of what the elements are going to be for this project. To structure that, we'll make a plan which is the method that we're going to use, the program of action, if you will, to guide us through the project. So one thing you have to realize though, is even though we spent a lot of time on this phase and we try to put a good foundation in place, everything will change, no project goes very far without starting to see changes. But as it says in the quote here, change should be a friend and we should really plan for those changes and think about how the proje will react to them as we get into the first days of a given effort. So to think about this, we're going to look at the why, we'll look at starting projects. We'll use some of the information from the project management institute on aterfall and agile type projects. We'll talk specifically around user experience projects and a little bit about, again, multidisciplinary teams. So why do we do this first? When you start to think about user experience, you probably think more about the design elements, sketching, prototyping, or maybe testing with users. That's all good, and it's the fun part, no doubt. But if you're going to get a project to be successful, you really have to lay that initial foundation and plan first. And that's what we're going to be talking about here. In this part of the UX phase we'll be setting the scope for the project. What is it that we're going to be developing? What is its function? What's its purpose? Who are we making it for? And how can changes that come along the way be responded to appropriately? We're also going to look at setting objectives that we can measure to make sure that both the project and the users are being satisfied by what we're doing. And specifically, we'll try make sure what the usability goals are, so we know what we're going to assess to make sure that things are good enough. The other part of this phase is to make sure that we're aligned with everybody that's working on it, and everyone that has to approve it. The work has to be authorized. The project has to be kicked off, then even though there might be changes along the way, you still want everybody to agree from the beginning about what you're doing and why you're doing it. So one of the places that talks a lot about how to kick off a project, how to prepare for it, is the guidelines in the project management institute's book of knowledge. The PMBOK 6th edition is interesting because it includes both the traditional waterfall style projects, projects that run from stage to stage that meet sequential milestones. Essentially, they're defined almost completely at the beginning. And then we work the project from phase to phase as we go. The PMBOK now includes agile projects which are run in a much different fashion, where periodically the engineering team might change the deliverables, change the priorities in partnership with the product owner to respond to what's learned, and to be able to respond to changes in what's perceived to be a successful project delivery. So we'll look at both of these approaches. So for waterfall type projects that move from the stage to stage and stage gate to stage gate, the PMI recommends starting those with something called a project charter that formalizes authorizing and kicking off the project. The charter has things in it like the purpose, the objectives, the risks, the milestones, etc. The next step is a more complete and complex project management plan that really goes through all the details around the project, the scope, the requirements, the schedule, the costs, the risk, how you're going to handle change, how you're going to measure performance. It's very a thorough approach. And again, these are tools that you would use for a more formal project where you're trying to identify what the effort is at the very beginning. These projects are often controlled with work breakdown structures, Gantt charts, budgets, and other reporting mechanisms. On the other side is agile development, which is more common in software projects, app development, etc. There's still this concept of a charter to kick things off where you're describing what the vision and purpose, how you know when the project is done, how are you going to handle the workflow. When you're in an agile project, usually things are done in an iterative cycle of retrospectives, backlog reviews, standups, demonstrations. And you'll use some established process like Kanban or Scrum or Extreme Programming to manage the project rhythm. But in both cases, understanding the basics, the why, the who, the when, the how, right at the beginning is certainly a key to success. When you're starting a user experience project, you want to make sure that you know what success is going to mean, not only for the person that you're doing the work for, the device you're making, for instance, but if you're running a company that provides a service, how is success measured for you or your company? If you're dealing with an organization of people, you need to understand their culture. How they make decisions, who really makes the decisions? Who are the main stakeholders? If you're working with a team, whether it's a team that you're contracting with or whether it's a team that you work with every day, it's good to understand the strengths and capabilities and the expectations of the individual teams' members so that you can make sure that they are successful and satisfied with what happens. And then because we're creating a thing in this project, we want to make sure that we understand the key brand elements. How does it look? What's the image of the product? What resources do we have to apply to our designs? And how do those decisions get made? In most of these projects you'll be working with a multidisciplinary team. They'll be somebody managing the project. Somebody working on usability aspects, people working on different parts of engineering. Maybe graphics designers, maybe marketing people, QA testers, etc. Most projects also have stakeholders, usually in a management position, peers, people working on similar projects, team members on the project. And maybe customers, you might be involved with, because they might be users. Regardless, you need to understand where your users and user surrogates are going to come from as you run the project. because remember, it really shouldn't be the people on your team, it should be somebody that better represents the views of a typical user. Collaborating and informing across all these roles is really difficult for an experienced project manager, for someone running a UX design or an improvement project, it's still a challenge and it's still important. And so there are project management techniques for stakeholder management, for reviewing roles and responsibilities, and for communications planning. For instance, the PMI has a tool called a role and responsibility chart matrix that helps you understand who's responsible for what, what information they need and how you'll be reporting to them. So before we get into the individual methods that will use to do the analysis and planning for UX project. We just want to remember that this upfront planning is important because it increases your chance of success. The PMI, the project management Institute, is a great source for best practices. But you'll also find that most user experience books and processes, talk about different ways to handle this stage. And like formal and discount processes, the level project oversight in the methods that are used will differ varying on the situations and the person that's providing the guidance. Much of the effort here is keeping people engaged in form and part of the process, and that's always part of the key to a successful user experience project. Next up, we'll go through these individual methods that support this phase, and you can go from there. Thanks a lot.
