# User Personas

## Learning Goals

After this lesson you will:

- Become familiar with User Personas
- Learn how to develop User Personas from your data

## Introduction


Personas are not real people, they are fictional characters **assembled** from the behaviors and motivations of the many actual users we encounter in our research.

- Describe demographics, behaviors, and attitudes
- Helpful in brainstorming, communicating, building empathy
- Should reflect user needs that will translate into product decisions

:::info
:family: Personas provide us with a precise way of thinking and communicating about how groups of users behave, how they think, what they want to accomplish, and why.
:::

## The Power of Personas


:::danger
The biggest fallacy in the realm of design is thinking that your product will be for **EVERYONE**.
:::

Logic might tell you to make your product's functionality as broad as possible to accommodate the most people. But if you do this you will end up with a product that pleases **NOBODY**.


> -- source: About Face

The reality is that the best way to successfully accommodate a variety of users is to design for specific types of individuals with specific needs.


> Personas provide a powerful tool for communicating descriptions of different types of users and their needs and then deciding which users are the most important to target in the design of form and behavior.
> -- About Face

## What are User Personas useful for?


The most important reason to create personas is to **set a common understanding of the final user**. -- For the design team, the client, the developers, and any other important stakeholders involved in the project.

### Personas help designers

- Determine what a product should do and how it should behave
- Build consensus and commitment to the design direction
- Communicate research findings to stakeholders to build understanding of the users
- Keep the design centered on users at every step of the process
- Help personalize the product for clients and employees
- When personas have been well-crafted, stakeholders and engineers begin to think about them as if they are real human beings and become much more interested in creating a product that will give this person a satisfying experience.

### Personas avoid

- **Designing for generic users**
- Real users have specific requirements based on their goals, abilities, and contexts.

- **Self-referential design**
- This happens when designers or developers project their own goals, motivations, skills, and mental models onto a product’s design.


- **Focusing on edge cases**

- Situations that might happen but that usually won’t for most people.
- Personas provide a reference point and a reality check and help prioritize features. "Will our Persona use this feature often? ever?"

## Elements of a User Persona

>It's not enough to come up a couple of user profiles based on stereotypes and generalizations, nor is it particularly useful to attach a stock photograph to a job title and call it a “Persona.”

For Personas to be effective tools for design, considerable thought must be applied to identifying the significant and meaningful patterns in user behavior and determining how these behaviors translate into archetypes that accurately represent the users.

**As a UX Deliverable, Personas are a one-page view of your user.**




As you can see, there are many different ways to put together a user Persona, and much debate about what information should be included.

:::warning

:white_check_mark: As a general rule of thumb, you should:

- Only include information that is relevant to informing design decisions.
- Don't make up information just to fill up a section (always refer to your research).
- Supporting fictitious details play only a minor part in Persona creation. It is used just enough to make the Persona come to life in the minds of the designers and product team.

- Don't create a Persona from just ONE user, Personas should represent a group of similar users.
:::

As every design project will have different goals and constraints, it is at the team's discretion what information to include to help guide design decisions. Nonetheless, we have identified several categories that will guide you through the process of defining your Personas:

A User Persona's information may include:


### 1) Demographics

These are quantifiable characteristics of a given population. Demographics are the base over which we will desc

- Name, Age range, Gender, Marital/relationship status, Income level, highest education, occupation, location
- Persona demographics should be a composite reflection of what researchers have observed in the interview population, modulated by broader market research.

### 2) Picture

After demographics, pictures are a fantastic tool to describe a Persona.

- Should look like a real person, not like a cheesy marketing ad
- The person should be looking at the camera
- Don’t use photos of celebrities
- The person in the photo should look like your archetype

:::info
:memo: This is a good Persona stock photo resource: https://www.flickr.com/photos/jasontravis/sets/72157603258446753/
:::

### 3) Archetype

Now that you have demographics and a picture, archetypes help inform stakeholders what the Persona is all about at a glance. For example: " Andrew: the busy commuter, Angela: the concerned daughter, Robert: the multitasking manager". Remember to:

- User categorization / descriptive adjectives
- Personality type
- Shouldn't need explanation. It should help capture the **essence** of that Persona and have no ambiguity


### 4) Quote

A quote would also give stakeholders information about the User Persona. A good quote clearly represents a repeated though. A bad quote is something made up not supported by real data:

- Gets at the user’s personality **in the context of the problem statement**
- Most efficient if it is an actual quote pulled directly from your research or reworded from a combination of different user quotes

### 5) Psychographics

Psychographics are used to describe consumers on psychological attributes. These attributes, if exist, should be found in the research:

- Goals
- **Should be actionable!** Think about goals for the product/service and not general goals for their lives
- Goals should be *inferred* from qualitative data (you can't ask directly what a user's goals are)
- There are 3 types of user goals

- Needs, ex: need to buy groceries while taking care of the children
- Frustrations

- Frustrations are the manifestation of the current situation in the form of pain points. They are tactical gaps found between the Motivations and Reality
- Only list problems that we can solve
- Should be specific to the issue you are working on
- ex: worried that their clothes will be damaged by the cleaners

- Motivations
- Understanding why a user performs certain tasks gives designers a great power to improve or even eliminate tasks yet still accomplish the same goals.
- ex: dinner is a very important moment for him and his family
- Interests, ex: the user likes to cook creative and new recipes
- Influences, ex: user's friends like to eat spicy food
- Beliefs, ex: believes "we are what we eat"

### 6) Bio

If the description of the User Persona is not complete with Demographics, Pictures, Archetype, and Psychographics is not enough, you can use elements from their Bio

- Should describe behavior - explain day to day and how this part of their life fits into the whole
- It should relate to their immediate space that we’re interested in
- It answers why does he need your product
- Needs to be **actionable**, specific to the problem you are investigating and should help you understand their needs of our services
- How does his day/life relate to the use of our service
- How is this telling me the story of the customer **as it relates** to the problem at hand

### 7) Behavioral patterns

They help stakeholders understand how users will interact with the solution. It

- How often do they use the product?
- Are they using the product by choice or by requirement?
- When do they use the product?
- Where do they use the product?

### 8) Skills

User Persona´s Skills describe the level of knowledge a user has when getting in touch with the solution.

- Technical expertise

### 9) User environment

User Persona's Environment helps you understand which tools the Persona has around. This is another great tool to understand technically how your solution should be implemented. For example, as [mobile internet users in Latin America will grow by 50 percent by 2020](https://www.gsma.com/newsroom/press-release/mobile-internet-users-in-latin-america-to-grow-by-50-per-cent-by-2020-finds-new-gsma-study/) if our solution is focused on the Latin American market, we should probably design it for mobile first.

- Devices
- Platforms
- Software

### 10) Other details worth including

**BEHAVIORS:**

* How often do they perform these tasks
* What methods do they use to do this
* When do they typically use these services
* How much money do they spend on these services
* These things will reveal OPPORTUNITIES; i.e. Cost-saving vs. Premium services

**TECHNOLOGY:**

* Understanding what devices they use so that you can make product decisions
* What type of devices
* Mobile vs laptop vs desktop
* Platform (Android vs iOS)

**FAVORITE APPS:**

* Helps you understand products they are familiar with their expertise
* Helps you learn which user-flows/business models they are comfortable with

:::success
:dancers: **Lean Personas:** Not every project needs to build complex Personas. You might not use all of their attributes. Remember **A good user Persona is the one based on user research, without regard to how many attributes we can describe**
:::

## Personas Tips + Tricks

- When you talk about your user, talk about your Persona (call them by their name) - this has a psychological effect that you are creating a product for a person, not for a faceless user
- Print and post these where you work so that you always refer back to them
- Use Personas and user types to create questionnaire screeners to recruit for user research/testing
- Personas should be typical and believable, but not stereotypical
- A team can develop more than one Persona. Different Personas represent different correlated behavior patterns.
- **Don’t add things randomly**
- Don’t add info that does not help you with your product. UX deliverables should have direct benefits and **actionable** items
- The information should reflect needs that translate into product decisions
- Ask "what is this information communicating to the team/stakeholders?"

## Summary

- A problem statement is a clear, **concise** description of the issue(s) that need(s) to be addressed by a problem-solving team
- Personas are not real people, they are fictional characters **assembled** from the behaviors and motivations of the many actual users we encounter in our research
- Personas provide a powerful tool for communicating information about different types of users and their needs
- As a UX Deliverable, Personas are a one-page view of your user
- Personas' information may include: demographics, picture, archetype, quite, psychographics, bio, behavioral patterns, skills, user environment

## Additional Resources

- [5 minutes guide to Lean Personas](https://www.uxpin.com/studio/blog/ux-designers-5-minute-guide-lean-personas/)
- [Personas by usability.gov](https://www.usability.gov/how-to-and-tools/methods/personas.html)
- [Human Centered Design - David Kelley](