Personas are fictional users whose goals and characteristics represent the needs of a larger group of users. Each persona that you create will represent a group of users with similar characteristics that you’ve learned about through your research. Personas are key to the design process because they reflect the lifestyles of users and give your team an idea of how to meet users’ needs or challenges (introduction to personas). This means they represent a larger group of users that have shared opinions, behaviors, and personality traits. Understanding that multiple users fit into the same general category helps you begin to define what types of people you’re designing for.
- Can help us identify patterns of behavior in users.
- We build them based on research.
- We need to figure out what user group our persona represents.
A user group is a set of people who have similar interests, goals, or concerns.
Build Persona
Personas are created by conducting user research and identifying common pain points, which are UX issues that frustrate and block the user from getting what they need from a product.
- Photo and a short biographical sketch: Include things like age, occupation, hometown, marital status, education and any other demographic data points that might give us a better sense of who our user group is.
- A bit about user professional goals and day-to-day duties along with frustrations.
- One persona isn’t enough to tell all the sides of a design story. you need a set of personas. All user groups should be vividly represented.
- As you create personas, look for the most common themes in your data and group the users who personify those themes together.
- Creating 3 to 8 personas is enough to represent the majority of a product’s user base.
- Think of personas as an overview of all of your research and interviews. While it’s important for personas to accurately represent users, it’s impossible to meet every one of their specific needs.
- Personas are also context-specific, meaning they should be focused on the behaviors and goals of users interacting with the product effectively.
- Get your team’s opinion on the product’s users before you build personas. Then, after you build personas, review those suggestions from your team and compare them to the personas you created. Point out how the data validated or contradicted their suggestions. Everyone on your team needs to understand the personas in order to truly connect with your users.
- Personas shouldn’t be exact reflections of the users that were interviewed. Instead, the personas you create should reflect a combination of attributes from a group of users with similar needs.
- For each persona you build, you should give them characteristics that would fall within the general descriptions presented for their customer type.
- Replace the picture and biographical data in the template with a picture and bio that better represents the persona you’ve created.
(persona templates like these persona templates and examples on Medium and these persona templates and examples on Xtensio)
Benefits of Persona
- Personas build empathy and put a face to the user. They help humanize our users. They give stakeholders a clearer idea of who their users really are and makes the user experience more meaningful.
- Personas tell stories. This is why personas are key to turning an average stakeholder presentation into a storytelling experience.
- Personas stress-test designs. Personas make sure we designers create something that benefits a wide range of users.
- You can use the information in personas to create designs that speak directly to users. This ensures users have the best experience when using your product!
In the world of UX design, the user always comes first. But to put user needs first, we have to know who we’re talking about.
You need to evaluate, research, and develop personas to represent key user groups.
Imagine that you’ve already completed your secondary research and conducted interviews with a variety of users. After transcribing the interviews, you sort the responses into two user groups. The groups are determined by identifying shared needs among interview participants. These groups represent two types of users that your design can help.
Build Personas checklist
Remember that your persona is a fictional representation inspired by a group of interviews and not an exact reflection of any single interview or individual. As you’re distilling information from multiple sources into one persona, you can create specific details about your persona, so long as those details make sense based on the research you’ve done.
- Demographic information: Did the demographic information match the persona’s characteristics given in the activity directions? Provide a breakdown of the persona’s demographics. You can make these up based on the type of users in your group of interviews.
- Quote: Were you able to imagine a quote that is relevant to the persona and the background you’ve built for them? Include a quote that summarizes your persona’s personality, along with a paragraph describing their life.
- Goals/frustrations: Were you able to align the goals and frustrations with the persona and the activity scenario? The goals and frustrations sections of the template should highlight the trending goals and frustrations across all of your interviews.
- Brief story/scenario: Were you able to give more information about the persona, tying in their goals and frustrations, as well as their quote?
- Image: Did you include a picture or avatar representing the personas for your activity? Include an image or avatar so you have a visual representation. This image or avatar can be an illustration or a stock photo that captures specific attributes representing the group of users you based your persona on. Be careful to avoid stereotyping your persona with the image you choose.
The goal is to create a realistic persona to empathize with as you think about the type of design solutions your users might need.
A great persona includes relevant information about your target user’s life, such as age, education, location, family situation, occupation, goals, and frustrations. You should also consider ability, gender, and race in your personas, too. Make sure the information you gather isn’t used in your persona to reinforce stereotypes. These identifiers give you a well-rounded idea of who your users are. They also help get you thinking about why these people need your product.
Once you’ve decided on your groups, sort your transcripts into each group depending on which group they match with the best. In the next steps, you’ll turn each group into a persona that is a composite of all the interview participants who fit into that group.
A user story (scenarios or user cases) is a fictional one-sentence story told from a persona’s point of view to inspire and inform design decisions. It introduces the user, lays out an obstacle, and states their ultimate goal. The user story expands on the persona and deepens your understanding of a user group. User stories have a hero with an ultimate goal and a conflict that keeps them from conquering that goal.
- Prioritize design goals. If you have a lot of user needs to consider, user stories, determine which ones are the most critical to resolve.
- Unite the team around a clear goal.
- Inspire empathetic design decisions by making our approach user-centered, also known as user-centric.
- Personalize pitches to stakeholders. You aren’t just presenting your design update ideas. You’re demonstrating how the updates will help specific types of people.
User story formula: As a type of user (who), I want to action (what) so that benefit (why).
A complete user story keeps the problem user-centered, actionable, and clear.
- Type of user describes who we are designing for.
- Action is what the user hopes will happen.
- Benefit is why the user wants the action to happen.
To understand your users, build a user story around their experiences with your product. User stories serve as a “checklist” to make sure you’re addressing and solving the key problems your users might face when engaging with your product.
The best practice for user stories is to keep them short, impactful, and to the point, with a clear action and benefit.
Different users have different needs, so be sure to practice empathy and keep their unique needs in mind when writing user stories.
Personas and user stories represent the needs of the users you’re designing for. The more detailed and accurate your personas and user stories are, the better you will be at designing products that meet their needs.
- A user story is short, specific and goal-oriented. It is a one-sentence statement that tends to have the following structure: “As a , I want so that ”.
- “As a…. ” The role refers to the one who makes the action and who benefits.
- “I want… ” It is the action executed. This should be something that your user can do or experience that helps them achieve the result they’d like.
- “So That… ” It is the added value that the user gets from the action.
- User stories are collaborative design tools. All project stakeholders are expected to participate in the definition and sorting of user stories.
- User stories focus the project on the perspective of those who will use it.
Your aim as a user experience designer is to promote a concrete, realistic and shared vision of the end user. (users are not like us)
The format of a user story forces you to think about others and keep them and their needs in focus, to work a little bit on your empathy and place yourself in the users’ shoes.
As a user experience designer, you are the “voice” of the user during project development. Try to surround yourself with as much of their reality as possible and translate this “user voice” into the user stories so that everyone in the project has them in mind.
Use cases are a bridge between the client and, sometimes, the user and the development team.
We focus on goals that “real” users will be able to work towards for a specific purpose. We focus the end goals on concrete and tangible things that the project will let the user do.
User stories originated as part of the Agile and SCRUM development methodologies. As user experience designers, we need to embrace them and use this simple method for our own “benefits”; that is, for the user’s benefit!
User stories give us designers everything we need to create a realistic, concrete and shared view of the user:
- User stories are based on user goals; thus, they keep products user focused.
- User stories are accessible and manageable; thus, they facilitate collaboration among stakeholders and team members.
- User stories help create a “project mental model” from the beginning and onwards.
User stories help:
- Prioritize design goals
- Unite the team around a clear goal
- Inspire empathetic design decisions by making the approach user centered
- Personalize pitches to stakeholders by demonstrating how the updates will help specific types of people
The user story formula keeps the problem user-centered, actionable and clear. To figure out what this user hopes will happen, consider their pain points
- Who the “type” of user is
- The “action” that the user hopes will happen
- The “benefit” the user would receive if the action happens
When building a new or improved product, the designer’s goal is to keep all users on the happy path.
The happy path describes a user story with a happy ending. For this user, everything goes as they expect, and they reach their goal without issue. Unfortunately, for other users things don’t go quite as smoothly.
An edge case is what happens when things go wrong that are beyond the user’s control.
Spotting and resolving edge cases:
- Create personas and user stories. If UX designers make sure their personas and user stories account for a wide variety of users and problems, they can keep even the most vulnerable users on the happy path.
- Thoroughly review the project before launch. Giving the project a final good review from the user’s perspective.
- Use wireframes. Wireframes help visualize the project, which makes it easier to identify potential user pain points and fix them before launch for folks who are not visually impaired.
