Now that you've had a chance to try out building your own personas for the class project, I'm sure you've run into some questions or challenges with putting your own personas together. In this video, we'll go over some frequently asked questions and common difficulties that usually crop up around building your own personas. Please feel free to ask additional questions in the forum, and I'll be sure to update this video. This is a commonly asked question by those reasonable skeptics out there who can't possibly believe the personas are as helpful as everyone claims they are. And unsurprisingly, I really believe in personas ability to create alignment and focus within product teams, but even across whole organizations, and this isn't flying faith. I've seen personas work in action.

A few years back, I was presenting on my company's corporate innovation off site to an audience of 800 plus engineers from around the globe. These folks not only worked on different product lines, but oftentimes only saw the problem scope through the lens of that small piece of functionality or widget that they were working on. Which was necessary because they made the best damn widgets out there. But in order to make my product pitch across geographies, languages, product teams areas of focus, I used one of our company personas, even the firefighter I didn't have to give the background Ethan's pain points or wishlist because we This was Ethan, everyone knew who he was. And even if they hadn't been formally introduced to him, hearing the snapshot of the problems my design was intended to solve, helped get a room of several hundred people aligned to the problem space I was working in.

So yes, they work with a caveat that you need to use them correctly. When your team meets or makes decisions. Your personas can act like silent witnesses to the proceedings. As the user experience professional, you own giving your persona a voice at the table. Yes, you're responsible for representing the users interests on the product team. And the personas are the documentation held back you up.

Bear in mind the pitfalls personas are helping you avoid. target users can more with each conversation your team has, because team members have implicit assumptions about the target audience that hadn't been expressed or validated. boiling the ocean, there's no focus because you're trying to solve too many problems rather than just the important ones. Self referential design, because you end up designing for yourself and how you imagine you would want things designed rather than really looking at the context for the target audience. Solutions searching for problems and or edge cases, when you're planning a feature because somebody might need this some time but not all the time. We can easily get distracted by the coolness of tech or the cleverness of our own solutions.

But those shouldn't compete with features your users absolutely need. These are stumbling blocks that are, the personas are best equipped to help you avoid. Which brings us to another common question or complaint I've heard. Why do you keep updating them? If personas act as a snapshot of your understanding of your target audience, then as your understanding of the target audience changes, which invariably will as you understand your problem space better, your personas will likewise have to follow suit. Similarly, stale personas with outdated information will be easy to ignore, because they aren't providing real value to the conversation.

When your product team starts ignoring the user research, they'll be relying on their assumptions instead, implicitly, making sure the information in your personas is still relevant is the key to avoiding that. Returning to my example of Ethan the firefighter again for a moment. during my tenure, we noticed that a shift was happening in the responsibilities of our Ethan's within our target population. organizations were changing the way they were distributing work across roles. Some organizations still had Ethan like firefighters putting out all the fires internally. But more and more we were meeting organizations who had hired George's one man shops responsible for everything purchasing operations and firefighting.

George behaves both like Ethan and Ethan's manager. He didn't want any of the same things that Ethan did, who was more specialized than George would ever be. And George needed access to more general features and functionality than Ethan would ever be responsible for. This became a problem because our product teams were losing focus on what the users needs and requirements actually were. Because there seemed to be so many conflicting statements from our user interviews. Our research team then created Separate George persona in order to explain the competing user research data that was coming in, separating out this persona allowed our product management and marketing management teams to determine which persona they're going to target for any marketing push, making everyone's work more effective in the end.

In this way, we targeted features to Ethan that were designed for Ethan. And we were able to market features to George that were intended for George. Another important question that comes up is aren't personas just a way of expressing and codifying derivative stereotypes? I cannot stress enough the importance of having cultural and demographic sensitivity, while acting as a user experience professional. So that very honest answer is yes, they can be depending upon how you construct and use them. There are some of the UX community that don't use stock images, specifically for this reason.

They don't want to codify stereotypes of what different user types appear to be. It sort of goes with Saying that you, as a user, researcher, or designer, constructing a persona have a lot of responsibility for the message. It is communicating to your internal stakeholders, the ones who will actually be consuming this information not to pick on pixels. But here the results for banker, a lot of stock photos of pretty similar looking people. The results for family aren't super diverse either, but this is the point. You have a say in how you represent your target population.

Personally, I think having a photo of a real human being is superior to using no photo or say, having a cartoon stand in as the user psychologically our brains are wired to respond more to actual human faces, and it's easier to form a bond and a relationship in a shorter period of time, but an actual human face on a persona. So as an alternative to crap stock photos, I found it helpful to take actual photos of my users in the wild. Not only can it help you and your product team Connect With the real user research that was done, you can get much more of the actual context of where and how your users are using your product. But probably the best way to ensure that your personas don't codify stereotypes, so make sure that the population you use for your research was sufficiently diverse. Reviewing the research that was done for the high mon app, I think we can safely say that this wasn't nearly extensive enough nor diverse enough to be conclusive.

There's good reason to suspect that this product team is in an echo chamber of similarly like minded users have more likely themselves and their close friends and family. And while in theory that isn't necessarily wrong, it does. It doesn't make from mindful or well thought out design. It just creates more navel gazing products in the world. There are so many challenges that this world faces the technology could truly support but it will require us all of us to be thinking outside of the box. And the best way to do this is to challenge our own Options about what we think the problems faced involves solid user research and the framework of well constructed personas can help.

Speaking of user research, this is one of my favorite questions, some variation of why do we need personas in the first place? Can we just have engineering talk directly to users to get feedback? What's with this middleman persona? I am an emphatic Yes. On this point. Yes, your whole product team designers, Product Management and engineering really any key stakeholders should hear directly from users.

It's the most direct and impactful way to build empathy, empathy for user pain points, and to help fire everyone up to go out and build an amazing product. Listening to user describe how to use a product in my experience always encourages product teams to want to go and make a product better without fail. listening in on user interviews can be a great tonic for teams. Don't just take my word for it. Harvard Business Review just did an article this suggesting the same thing. Making your customers visible to your employees builds excitement and engagement because people connect what they're doing on a day to day basis to real impact for customers.

That said, the art of listening can be very challenging when getting any type of feedback directly from customers, especially when it's critical. As a user experience professional in the room, you own translating the user's words into action. This means not jumping to conclusions or assuming you understand what someone means. It means practically speaking, that you take the time to really let the user share their experience in their own words, and then reflect back what you understood to validate that you receive their message correctly. I'll go in more in depth on user interview techniques in another course on user research, but suffice it to say my general attitude is that all feedback is great. If you've tried art and loved it.

Amazing. If you tried our app and you hated it, thank you. Thank you. Thank you for sharing how can we can make this experience better? I always learned something more about the users mental model from all user conversations. How do they understand the problem?

And what didn't we take into account? Yes, your team should sit in on any user research they can. Try to ensure that you or your user researcher, or train and active listening to the user are driving the conversation. And also keep in mind that it can be impractical to schedule everyone to sit in on all these user research studies. While it is better for your teams to hear from users firsthand the limitations of schedules being what they are, your your research documentation, ie your personas are intended to be a good stand in. And last, but certainly not least, what do you do if you don't have enough user research, which is absolutely a reality of the product lifecycle.

Sometimes there just isn't enough time to do extensive user research you need to do, but never fear. Personas can still serve in these instances. Look, assumptions are a necessary part of the decision making process and a world of imperfect information. The trick is to be clear about what assumptions you're making so that when there is time to do more extensive user research, you can validate whether those assumptions actually hold. Let's go back to sharing one for a moment. The two personas we're using for the Hi mom app another way another way to format these personas is to explicitly call out assumptions Our team has made for the purposes of moving forward with the design of the product.

Here I've highlighted those invalidated assumptions and red italics. This makes it clear to me and the rest of the team that we may be operating on shaky ground when we take these assumptions as facts, but they also highlight what issues should be the focus of our next user research sessions will want to validate are most critical assumptions as quickly as possible. assumptions are a necessary part of moving with speed, but they don't have to derail you if you are more explicit about where they are in your design process. In future courses and planning to discuss a methodology I found very helpful for clearly articulating assumptions to avoid mistakes, and to keep team members focused and aligned. Use the personas you're developing in this course to serve that function for your teams. So to wrap up, we've discussed some of the common questions asked about how to use personas in the wild.

They can be a wonderful tool and really aid the process of improving empathy for your users. But just as with any tool, you have to remember to use them properly. This means bearing their limitations in mind, which include keeping them updated as living documentation they need to evolve as your understanding of the user and problem space evolves. by updating them you also ensure that your product teams don't inadvertently bake their own assumptions into their understanding of the problem they're solving for implicit or unspoken assumptions can really derail products. You, as the user advocate have a responsibility to avoid codifying stereotypes and biases into your personas, by making sure that you're drawing from as diverse a population as possible with your user research. Right, recognizing that real life feedback is better and is more impactful as an approach for building empathy across your product teams.

But the poor personas act as a pretty good standing when you can't get the real stuff. When you don't have time or budget to get good quality research from users use the persona document as a way to label and call out assumptions your team is making to move forward. And be sure to validate those assumptions with future research. Updating your persona as your understanding of the problem space evolves. If you see that you see you like how you like how I brought it back full circle, we're like going back to updating and keeping our living documents of personas as They go. So with all this real world experience in mind, how are your class projects coming?

Does this give you a better sense of how you might actually apply the two personas you're creating to the problem space of the health and wellness app redesign? What stumbling blocks are you facing with this class project? Be sure to add any questions you have to the forum. Whoo, you're almost done with this course. In the last video, we'll be reviewing everything we've spoken about so far. stringing the whole narrative together.