Podcast: The UX Power Tools Behind Compelling Software Part 1

Transcription

1 [Year] Podcast: The UX Power Tools Behind Compelling Task-based Personas Prepared for: Macadamian Technologies No. of pages: 7 Audio recording Identification: UnSalted_ep2 00:10:31 Transcript prepared by : Capital Transcription Services Host: Guests: Graham Machacek, Manager of Marketing Communications, Macadamian Technologies Anneliis Tosine, User Experience Researcher, Macadamian Technologies Sara Fortier, User Experience Designer, Macadamian Technologies 5/14/2013

2 ++Audio++ 00:00:01 [Intro music] Welcome to Macadamian s audio Podcast- unsalted. Strategic insights on software development and user experience design. We are bringing you snack-sized discussions your brain can munch on. Join the conversation at macadamian.com. Hi listeners! I am your host Graham Machacek, Manager of Marketing Communications at Macadamian. Welcome to our mini-series focussing on the power tools behind compelling software. These are the things we provide our clients as we move through the user experience research and design process when we create software products. In this installment, we decided to focus on task-based personas. I am joined today by two of my colleagues at Macadamian. First, user experience researcher extraordinaire, Anneliis Tosine. How are you today? Anneliis Tosine: I am doing very well Graham; good to be here. And also, Sara Fortier, user experience designer. Sara, how are you? I am good thank-you. You are based in California and we are recording this in the winter, so I will try not to be jealous. [Chuckling] 1

3 Sara is joining us via Skype. Let us just get right into this topic. Anneliis, first, it would be great if you could tell listeners why it is important that business requirements and user requirements be aligned before we start any project. So, why do we not just start there and then we will go Sure, I think that is a great spot to start. At Macadamian, we often recommend to our clients that we start any project with identifying these two types of requirements. We are talking about business and user requirements and we do this to help manage risk of these projects. We first start off with our clients in collaboration with them and start identifying and pulling together their business requirements. These are business and customer goals, stakeholder value chain and success metrics. Then, we use a variety of research methods to hone in and identify their user requirements. These are the real needs of their end-users and it is based on their use and behaviour. We identify what the user needs in order to complete a specific goal and this is the foundation of user-centred design. What we are outlining and identifying in user requirements are user groups, task identification, context of use and usability goals. We identify all of these business and user requirements so that we can form the design and this is how it helps to mitigate the risk. For example, when businesses have an understanding of their customers goals, they are able to bridge that gap between their own business requirements and their user requirements to determine what the customer values and essentially what they are willing to pay for. 2

4 Anneliis, what are personas and usage scenarios? Maybe you can tell us where they fall into the process of designing a software product. Anneliis Tosine: Sure. From these user requirements and from that phase in collaboration with our client, the real great and more valuable deliverable that comes out of that are these task-based personas which is our focus for today. These personas function as stand-ins for real users to guide decisions about design and functionality. This document can capture a number of personas which are typical users of the product. It outlines their goals, provides insights into how they would want to use the product to achieve those goals. This information has to be tallied in some kind of fashion so that designers and developers can consume throughout the course of the development process. A persona can do this very well; it can help give direction to the team and really personalized the end users. We distill all of this information into personas and this is what we provide back to the product team. Okay, how do you know if you have captured everything correctly and recorded the real essence of your user groups? Anneliis Tosine: That is a great question and we get that a lot. We can use a number of different activities to do this to validate the personas such as ethergraphic research. This approach, an Ethernet graphic approach, helps us better understand the people and the organizations we design for not only to get them products that address their needs, but also it starts to reveal their shared attitudes or goals, 3

5 their practices that influence decisions and adoption of the product and ongoing use of a particular product. Okay. Sara, I am Just going to check in with you know. I just want to know what risks in your view are associated with products that do not incorporate taskbased personas. Let us get into the meat of it here! Sure. I mean, this is something that we run into a lot with clients given that selling research services can be a bit more challenging, but task-based personas really help provide context for the business and user requirements. When you get into an actual situation where you are developing software you are designing for the user and sort of asking yourself what the user would want in a situation. Personas really help to focus the design task and development task to look and see what their motivations are and what that actual person would be doing what would John Smith do in this situation? Later in the product development process, the personas also aid in communication and help to prioritize the trade-offs and other considerations you come across when you are making product design decisions. The bottom line is that they are useful throughout the entire user experience design process. We should probably share some case studies of what has gone wrong when task-based personas are not use. Do you have any more specific kinds of examples? I mean, as I have mentioned, we run into this with our clients sometimes where we do not always have the opportunity to do Ethernet graphic research to come 4

6 up with our task-based personas and it really effects the success of the product because you have to make certain assumptions as you are designing for a user that you actually do not know enough about. I am guessing sometimes some clients might think it is not necessary because they have been working with the user group for so long is that the idea or maybe they have done other research? Yes, exactly. Clients will basically give you their assumptions that they think their customers or users want and we have to help guide them and fill them in on who their users actually are. Sometimes they will not line up with their expectations. Graham Machecek: Yes, but sometimes probably that is a good thing; you probably get some insights out of that that lead to new discoveries and a better product. Yes, absolutely. Anneliis, can you share some examples of how task-based personas have helped focus some decisions some real decision and hard decisions that people have to make? Anneliis Tosine: Of course. Like Sara has mentioned, these personas help make decisions with those end-users in mind. We are really bridging that gap of knowledge that maybe missing and we are bridging the gap between development and U X in order to show us why something, let us say it is a feature or content, is important in the product. By using a persona to answer questions like what 5

7 information is necessary at what point in a work flow or does the user have frequent interruptions during their experience or why are they using the product, so by answering some of these questions teams can actually be in the user s shoes and better understand what a real user needs and wants. In essence, personas are observations and descriptions of why a person does what he/she may do. What they start to help to do is take focus away from requirements and deliverables for a designer so they can really focus on the user s goals. Essentially, if you do not know who you are designing for, you cannot actually design anything. Yes, good point. Sara, what is the one thing CEOs of software companies need to know about personas let us start with that audience. As I was kind of mentioning before, the idea that CEOs and companies they all have expectations about who their users are and who their customers are and it is really important for them to understand that we are not actually looking for opinions or who they think their users are. We are really concentrating on motivations and looking for the needs and what is driving the user why are they trying to accomplish a certain task and how do they need to get there. In the end, the project team really needs to know that in order to figure out what the new features are going to be and if you want to expand into new markets or come up with new offerings, you can only really do that through the user research and through coming up with these personas. 6

8 Yes, okay. Same question, but let us talk about product managers. What are the things that product managers need to know about personas? Well, I think it is similar, but just more tactical maybe. Personas sort of allow you to understand, identify and communicate to the whole team what the needs are and it does it in a really efficient and effective way. The product manager should be using these with their developers, designers and pushing it also to their clients just so everyone can align themselves on what those motivations and needs are and having that tangible artifact helps them do that. Graham Machecek: And on other audience we should definitely mention is software engineers what about for software engineers? What considerations should they be thinking about in terms of personas? For engineers in particular, we have found that it can be really useful to give them that why because when they get into the nitty-gritty when they are working on a particular user story they do not always know why they are actually doing it. Sometimes a lot of compromises are made because it is quicker to develop and easier for them, but when they actually understand from a user s perspective why it is important to develop it in a certain way, the engineers are a lot more motivated to do it that way too. Graham Mackecek: Alright. Thanks everyone for tuning into our mini-series on the power tools behind compelling software and it has been really interesting listening to all of the information on task-based personas and we hope you will tune into our other additions that are coming shortly. Thanks so much and have a great week! 7

9 [Closing music] You have been listening to Macadamian s audio Podcast unsalted. Get more tasty insights on our blog. Visit macadamian.com. +++End of audio+++ 00:10:31 8