Hello. In this lecture we're going to talk about a method for the research phase called user personas. Personas are one of the more common tools that people use during this cycle. We will try to understand how they're developed, how they're used appropriately, and how they're applied during UX research. Again, a very common method that comes up often in this cycle are lots of variations to the approach. I'm going to talk a little bit about my initial experience and then we'll get into some alternative definitions from Cooper, from Buley, from Menlo Innovations on how persona's are put together and how they're used. But first we'll dig into what a persona actually is. The purpose of a persona is to create a representation of your user for your design team or for your design cycle to reference as you're moving through the rest of the development. Personas usually include a set of key information. There's often a picture of this fictional person that this persona represents. They usually have a name. They might have a job, responsibilities that are documented. There's usually some demographics around the age, the education, the capability of a user. The persona will talk to the most important goals and tasks that they have concerning your design for a device or a system. But also maybe just in general and maybe some information about their environment, their social activities. Again, to round out the picture of the person that you're describing in this persona definition. Typically this gets put into some template. There are many persona templates out there. Normally, a persona is not an actual person. It's really a fictional person that represents some segment of the user population that you're designing for. Even though the persona, depending on how it's presented, may look like an actual person. It may get to a point that people think of that persona as an actual person. Initially when I first looked at persona is I thought this was a throwaway exercise. I didn't really see all the benefit from it. As I started to use personas in development projects, it's started to be more clearer as to what the benefit was. Really what it gives you is some empathic emotional connection to your user. It also starts to plant the seed in your mind of what would that user do with my device? What would they expect? It can be shared with your entire team to the point where the designs team will even bring it up in design discussions. What would Melissa do with this device if we handed it to her. I think there's also an under appreciation of the work that's required to do a really good job on a persona. It's easy to fill out a template. It's easy to make up some of the information. In fact, we'll talk about something called a proto-persona, which really just creates the persona based on information that you already have. But to do this thoroughly, there is some research required and we'll talk about what the benefit of that might be. The persona approaches, we're going to go through, the Cooper approach and the Menlo approaches are fairly thorough. Although they're very different, they result in detailed definitions that can be used to drive the project forward. The Buley's approach proto-personas is more subtle, more empathic, and is created really at a point where you may not know all the answers about this person that you're creating a persona about. Let's talk about Cooper because really in Alan Cooper's about phase and in his book, The Inmates are Running the Asylum. Cooper gets a lot of credit for really creating the ideal for the need for personas. Cooper defines a persona as a user model of representation of how a user would behave and think what it is they want to accomplish and why. Cooper says that for personas to be effective, they have to be created with rigor, with finesse. You really want to make sure that the persona represents an archetype of a cross-section of the users that are going to be using your device or your system. Most importantly, Cooper feels a variety of users might be needed for a design. For a given system, you might end up creating a number of different personas that represent different needs that are being met by your design. The key here really is to choose who those individuals are and make sure that you prioritize them when you're making your design decisions. Cooper outlines roles for personas. They communicate to the project team who the users are. They really start to drive how a product should behave. They can be used to develop consensus around design features and perhaps be used as a way to measure a design's effectiveness as you try to align what the device does against what a persona expects. Personas, according to Cooper, should be based on thorough research. If you think about those research activities that we discussed, like contextual interviews or focus groups, the information that you develop from those types of exercises should feed into the persona development. Cooper would say that the personas should not be created until you have that information. In fact, Cooper learns about something called a provisional persona, which he feels could lead to concentrating on the wrong design targets or missing key behaviors. It can also impact eventual buy-in for design, because changes to the persona might impact how people accept your design decisions. This is a little bit at odds with Buley's approach of a proto-persona that's created before you have all of your information. But as we'll see, even Buley talks about trying to form up that proto-persona with the information that you gather as it develops. Interestingly, Cooper also picks up on some common issues that come up during persona development. One is the elastic user, which is a persona that is vague or drifts in terms of its definition or the expectations that are set from those definitions. Self-referential design again, is always a danger trying to make a persona and then finding out that it looks a lot like what the design team expects versus what the users expect. Then finally, the issues of creating personas around edge cases that may not be the priority for a given design. All those things should be considered as you're putting a persona together. In the Buley method, the proto-persona is developed pretty early in the design cycle. It is way to put together a hypothesis for what your user will expect and who your users are before and during the process of gathering that information. Proto-personas eventually develop into full fledged personas as information is gathered. But having this early view can develop an empathic connection between the design team and this concept of who it is that you're designing for. Again, you have to decide when it's appropriate to start putting this information together and what impact it might have on your design cycle. The proto-personas, as Buley presents them, again, treat this as a hypothesis. You're going to iterate over bringing information in and fleshing out this definition over time. In the process of proto-personas that Buley points out, she likes to have a team of people create multiple views of who they think the users are and use whatever data is available to create these personas. But again, over time, these things will strengthen and provide more guidelines for your eventual more detailed design. The Menlo approach to personas and persona mapping is interesting. It's a different approach and its goal is to drive to understanding the roles and responsibility of users. The persona structure that Menlo uses includes a lot of the things we see in most personas, a photograph, name and age, the organization or a place that the person comes from. But specifically, on the capture of the personas, they look for attributes about the person that might apply to the project and specific goals that the persona have, two of which have to be focused on the project, one that might be more general. In the process of creating these personas, initially, we're looking to create 10-20 different personas. This is a much broader creation cycle than you might see in other persona approaches. But what's interesting is what happens next. Those 10-20 personas are actually provided to the customer, not the design team. The customer decides amongst those personas, which ones represent the primary user, the secondary users, and tertiary users. There will be one primary user, two secondary, and three tertiary. Those six personas then become the heart of the design target for what it is that's being created. It leads to a very clear identification of what the key elements are that you're focusing in on in the design and still gives you that persona empathic connection to what these people want out of what it is you're creating. It's a very interesting approach. In summary, again, you'll need to decide how a persona impacts your design cycle. Certainly, it'll keep those concerns visible, it can help build consensus, and it helps to maintain that empathic, what would Melissa do at this point, connection to your design. Think about how you would use them. You'll have an opportunity to create one as part of an exercise for the class. Next up, we're going to talk about use cases and UML, one of the other important user research methods. Thanks.
