User Persona Development Guide

As a product designer, it’s always good to have the users in mind for all of your product decisions. User personas are a great way to synthesize the user research and feedback you receive and develop archetypes based on accumulated data.

Research Portion

Quantitative vs. Qualitative

Quantitative: Data metrics that pertain to hard data, specifically numbers or analyses from website user data. Examples of quantitative data types include:

• Number of users
• Website choke points
• Average user time spent on application
• User retention
• Impact of marketing efforts

Qualitative: Data metrics for user behavior. More of a soft approach, qualitative data requires connecting with potential users. Benefits of this approach include:

• Understanding of behavior and attitudes of potential users.
• Developing patterns of behavior across multiple users.
• Environmental, Technical, business contexts can be identified.
• Understanding of current use cases.
• Design decisions can be traced back to research.

When beginning the design process, qualitative data is key to understanding user needs and meeting those requirements. Quantitative data is can be used to make accurate predictions on the marketplace expectations of the application and the analytics on how users interact with the product.

User Impact

When analyzing user behavior, it is helpful to ascertain the types of impact products can have on the user. Donald Norman defines three different cognitive and emotional levels of user reactions to a product.

1. Visceral: The immediate reaction to a product before any interaction occurs. This may result from the visual appearance of a product to the sound it makes when it boots up. It should be noted that making beautiful things may not be the proper visceral reaction to a product, manipulating the visceral reaction should be appropriate to the goals of the user.
2. Behavioral: The most commonly elaborated type of user reaction, this refers to the actual use of the product and is defined by understanding user behaviors and goals. This is the primary type of user reaction and should be the main focus in the design as visceral and reflective reactions are informed by the behavioral, while visceral and reflective may influence the behavioral.
3. Reflective: The lingering reaction the user has after using the product. This helps establish a long­term product relationship but is also the most difficult of the three levels of reactions to design. When a product reaches iconic status (the iPod, Coca­-Cola), the associated memories will be very positive. When a product addresses the user’s goals and exceeds its purpose, it increases the chances for a strong reflective reaction.

Look at the top products in the market you’re developing for and analyze how these types of impact are affecting the user and how you can improve on that interaction.

Interviewing the User

When speaking with users, one must talk to current and potential users. In interviewing, the line of questioning should be:

• How the product fits into their current work flow (the when, why and how).
• What information do users need to do their job.
• Their tasks timeline, what they’re up to and what they will have to do later down the line.
• Needs and goals for their use in the product.
• Expectations for the product as well as insight into how they work.
• Pain points with competitor apps.

Customers and Users can be two distinct groups. In our situation, the customer may not use the application at all, but will ultimately still be the one with the purchasing power who will make the decision to buy. When analyzing a customer, one must take into account:

• Their reason for purchasing the product.
• Their pain points in other solutions.
• Their day ­to­ day with the product.

In Contextual Design, Hugh Beyer and Karen Holtzblatt developed an ethnographic interviewing technique called contextual inquiry. This interview style uses a master­-apprentice approach, in which the interviewer takes the role of the apprentice and the subject the role of the teacher. There are four basic principles when engaging in this style of interviews:

1. Context: The interview should take place in the subject’s place of work, not in a neutral room. The interviewer can observe the work environment and form behavioral conclusions of the subject based on the surroundings and artifacts of the workplace.
2. Partnership: The interview should take on a collaborative nature, one in which information being shared can then be discussed and elaborated on.
3. Interpretation: Interviewers are to analyze the information being given to them in the context of the interview and form conclusions by also incorporating environmental clues and subject behavior.
4. Focus: The interviewer must steer the interview in a subtle fashion in order to get the desired information as it relates to design issues. The interview must not feel like a questionnaire or be allowed to wander aimlessly.

When conducting interviews, it’s important to have a clear path of direction. The interviewer must identify the product goals before conducting the interviews to determine the user goals. The interviews can be conducted by a small team, and don’t need to be longer than an hour. It’s good to identify the types of environment’s the product will be used, and how those environments would change the average use case (as an example, a gallerist will likely have a different product experience when using an inventory management application in an art fair instead of at a gallery).

When looking for interview subjects, it’d be best to begin with a persona hypothesis. A persona hypothesis is a sort of educated guess to the identity of the common user of the application. A step beyond that, interviewers can form an ad hoc persona, which is a full user persona that’s not based on verified information. With these personas, interviewers can identify potential user subgroups and pursue subjects within those categories. The interviews should be conducted with four to six subjects for each persona category. With these hypotheses, one should define:

• Job Categories
• Needs
• Behaviors
• Environments

When beginning the interview there should be three participants:

1. Moderator: Asks the questions and takes light notes.
2. Facilitator: Takes detailed notes and looks for flaws in the questioning.
3. Subject: The potential user.

When conducting the interview, one must be sure to avoid using a set of questions. It runs the risk of alienating the interview subject and prevents interviewers from following the valuable information. Any questions asked must focus on:

• The user’s goals
• Insights into their work process.
• Decision-­making
• Pain points
• Preferences
• Time spent on applications.
• Work­flow
• Long­term aspirations
• Motivators/Demotivators

Be sure to avoid leading questions as well as direct suggestions to improve the app from a designer or developer standpoint. The interview subject isn’t supposed to provide solutions to the product, they’re supposed to identify problems. When an interview subject does offer some sort of design or development related solution, be sure to ask how that would solve their problems so as to identify their issues.

Once the interviews are complete, work with the team to parse through the assembled information so as to identify trends in user behavior. After plotting all this available information, one can then create a detailed user persona.

Crafting the Persona

Name and Title: The name and portrait is used to build empathy within the team. The job title should inform what type of capacity they have on the application.

Bio: This is just a bit of flavor text to build empathy for the user, and may be synthesized from actual experiences of the users or be pure fiction. A short paragraph would suffice.

Age: Although age may define whether or not someone is a computer native,it should not be presumptive of the user’s competency with technology. That sort of information should be defined by the collected data, not stereotypes.

Tech Literacy: Adds insight to any potential challenges for users. Different users may succeed and fail at different aspects of the application so it is important to determine if users of specific tech literacy levels have similar pain points.

Needs: This can be identifying pain points specifically stated by the potential users. However, one must remember that all input for user needs isn’t necessarily the right direction for the application. It’s more about identifying issues that they discover in their own work flow and establishing whether or not the application would be improved by resolving it. A user’s needs may not be their goals.

If I had asked people what they wanted, they would have said faster horses.

Henry Ford

Goals: The most important aspect of the user persona. There must be a defined goal to the user’s product use, whether that is to engage more customers or to use a unified system. User’s typically can’t define their own goals, thus defining goals should be built by observing needs and user behaviors, and even by observing their environment.

Donald Norman defined three types of user goals:

1. End Goals: The heart of the user’s interaction. This refers to the focus of a product and should be seen as the foundation of the user’s goals.
2. Experience Goals: The emotional impact of a product. These are simple interactions that excite the user, and can range from appealing design and interactions to a general sort of ‘whimsy’ in its animations and copy. The experience should empower the user and make them feel like they are in control. Obtuse experiences that are overly complicated or unappealing can cause users to hate the product.
3. Life Goals: The user’s personal aspiration. This refers to any of the user’s goals beyond the scope of the application, typically success of some sort. Translating these goals into product design and brand strategy can dramatically increase the user’s engagement with the product.

Behaviors: this can define a range of attributes in the user. Depending on the user’s job title, goal and personality type it’s important to understand what types of cases to design for. An art dealer may not spend much time on the computer on a given day and may be prone to frustration by complicated interfaces, whereas a younger sales rep may spend much more time on the computer.

Developing user personas is a great first step to making product decisions that enrich the users and can be great for developing user empathy in the product and engineering teams.

Subscribe to The UX Blog