In this video, we'll discuss some of the basic principles of what personas are used for. We'll be touching upon some of those five W's of personas. Who do personas represent what goes into a good persona? When in the design process Do you use personas, we'll talk more about the mechanics of building your persona and some of the pitfalls of personas and upcoming videos. To start, I want you to imagine that you and a group of your friends just launched a new startup to build an app that helps users write pre canned update messages to their families. Rather than having to take the time to reach out regularly or even think of original composition.
Artificial Intelligence would come through a user's social media feed to pull relevant and PG rated content to be edited into a weekly digest for parental units and other family members. Thank you to the incredible Jessica James for this app idea. Ah, you're pumped because you have this great idea with this slick tech and you think everyone is going to want to use it. You cannot wait for this to go viral. And as the team's designer, you're responsible for the workflow through the app and the look and feel of the design aesthetic. But the team can't seem to come to any decisions about your design direction.
Two of the founders are really at odds. And while both of their positions make sense, it isn't clear what the right way to go is. There's a lot of pressure from your VC to deliver quickly. And the random feedback you've been getting around the office is inconclusive. How do you defend your design decisions? How do you offer feedback when the founder is fixated on a specific color design element, or feature because he thinks it makes sense.
How do you prevent scope creep when solutions start chasing after problems rather than vice versa? Hopefully You've done a lot of user research and market analysis before launching. But you need something to synthesize that information into bite sized and manageable pieces for your time constraint team. We need to find a way to represent the users voice when they can't be in the room as you're making decisions. personas are here to help you out. personas are personifications of user data, they present composites of user models as specific human beings.
Maybe your app supports the needs of different and distinct user groups with separate needs, goals or pain points. A great example of that would be a type of administrative software that might have two types of users an employee versus say a manager who might be using the same piece of software but fundamentally have different tasks they're trying to accomplish. The purpose of personas is to help your team focus on the essentials of what they're building and why they're building it because they're composite or summary of user research. They are great for communicating your users needs and goals throughout your organization by being succinct, clear, and importantly as personifications, they can help build greater empathy, and can be a silent partner in creating consensus throughout the organization, helping everyone be more focused. But how exactly do they do that? Let's go back to our kick ass new app.
Hi mom, and pull out one of our target personas. Meet Sherry daily everyone. She's a young ish up and coming ambitious professional who loves what she does, but it's finding it difficult to balance her heavy work schedule, with keeping in touch with her family and friends. She's fed up with social media which purports to be the best way to keep in touch because it's so impersonal. Plus, her grandparents haven't quite embraced the digital age, meaning they only got email accounts a few months ago. Sound like anyone you know?
She does her best. And we think that how Hi mom can really help her out. But to better understand where our app might fit into her day to day, we need to know a little bit more about her life. Sherry starts her day early, getting up at 5:30am to get some exercise in before work, since she has regular stand up meetings with her engineering team have breakfast every day. This is her only real neat time before the workday starts. She lives and breathes her marketing job.
She's good at it, and she enjoys all the traveling all the people she gets to meet and generally getting stuff done. But we have so much of her work life is spent online and on social media, she can find it challenging to make time to stay connected to her family back on the east coast. She wants to stay in touch but between being sick of her feeds after a day in the office to dealing with the time difference. She wishes she could find ways to stay more connected and may feel cheesy to write out a fictitious day but there are details embedded in this story that give us a sense for when and how Sherry might use our app. She sounds like she's on the go a lot between meetings and all of our business travel. Maybe we can assume.
But hopefully we have research to back this up that she would prefer a mobile app experience over desktop. She also sounds pretty busy and has a lot of context switching in her day. She's a prime candidate for information overload. Again, we can assume the pre canned or auto responses that require less of her input to compose might also be a feature she'd be interested in. I can hear you maybe pointing out that, well, wouldn't everyone who uses this app want that same feature? And again, this is the point of personas to help disentangle that by looking at each personas, individual responsibilities, what tasks are they trying to accomplish?
What needs to get done? In Sherry's case, we've listed out responsibilities both for her work and personal life. Why Because she's explicitly told us that these tasks can feel like they're in conflict with one another, to better design for her, we want to take her whole context into consideration. Sherry was responsible for doing a lot of communicating just not with a family. That is, she has to represent the corporate values of organization. And it's pretty sharp when it comes to preparing messages for customer base.
But it looks like she struggles to keep her less tech literate family in the loop. It seems that the onus is on her to do the reaching out. Plus, she wants to share but in a way that doesn't trigger a lecture. She's trying to be careful about not upsetting her parents. sounds legit. So if this is what she feels responsible for, what's your wish list?
What does she wants to be able to do? What is she trying to achieve? That takes us to her goals, or I like to think of this as a wish list. These are different than responsibilities, which are more like tasks and may sound like I'm splitting hairs. Remember, we're trying to synthesize vast quantities of user data with these personas. Goals then act more like her desires list, they give us clues as to how we can make her life better.
In Sherry's case, we can see their goals are about improving the quality of her connections. Interestingly, it isn't specified whether this is just with our family or with our clients as well. Notice some of the language that was used to describe Sherry's goals. It sounds like she could use some help with all of the distractions he's inundated with in her work and personal life. She needs help remembering what she's done in a week, she wants to find more time to focus on the relationships she cares about. She wants to clear the noise out of her mind.
With each section of the persona we've gone through, we're getting more of a sense of who Sherry is. And now we come to my favorite part of any persona document. And frankly, the one I'm liable to look at first, the users pain points. None of this should fail. Coming out of left field, the users pain points are going to be related to the conversations we've had in our user interviews about how we can solve their problems. But again, look at the nuance of the language.
The pain points are really intended to highlight the users blockers. And while there are some things we won't be able to solve for, like adding more time in the day for Sherry, there are other pain points that we might be able to do something about, like helping Connect her to less tech literate family members via channel she's more likely to want to use like text or chat. And keep in mind, knowing about pain points that we can't solve for can also help the team out because they show us clear edges on the bounding box of our app scope. Maybe we focus more on the modes of communication of media consumption, and leave the information overload to our meditation apps. All together. This gives us the persona of sherry, a user composite that can stand in so to speak in our production and design meetings and help our team stay And focus on who we're building for, you know, or now, she may just be a representative of a group of users you're targeting.
But now that you've spent time getting to understand her story she can take on a life of her own. She becomes the benchmark against which you and your team judge the quality of your solutions is our app, something Sherry would be excited to use. This video hopefully gives you a better sense of what type of information goes into a good persona, and why that information can be useful to keep your team aligned. I mean user researcher by background and inclination, so I'm going to buy as we say that user research artifacts like personas belong at every stage of your design process. but hear me out. There can be a lot of value in letting your requirements documentation evolve as your product evolves.
Adapts as your own understanding of the problem space or the users need changes which invariably will because you can know everything about the problem until you try to solve adapting and evolving as your product develops is the whole philosophy behind agile development methodologies. product management techniques and user experience design have tried to learn to adapt to changing technical realities, but in my experience have struggled to stay flexible and nimble. Living personas can be a way for the product side of the team to stay in sync with the development side. Very technically, personas will be made during the user research phase, after extensive or in some cases, not so extensive user research. We'll go over in more detail how you would convert your user research into a composite persona. But for now, let's just say that it's very important that your persona be drawn from as much real user data as possible.
I can't stress this enough. Without having actual facts to back up your composites, you're likely going to embed tribal knowledge or engineering folklore at best or worse blind assumptions into your understanding of the users or your problem space. Left unvalidated your assumptions can send you wildly off course, I hope you can understand why I have a research bias by now. Assumptions our product teams worst enemy, they lurk in the back of the team members mind and inform the decision making implicitly. personas are just one of the tools at a designer's disposal to help draw out assumptions the team is holding about the target user group and expose them to the cleansing power of the light of day. Think of them as that assumption busters.
But in order to serve their functions at any stage of the design process, they themselves need to be based on cold hard facts. I've given you a taste of what personas are and how you might use them. In our next video, I'll present how you would go about building your own