The field of user experience centers on the idea that we must design products around people, rather than teaching people how to use products: user-centered design (UCD), not technology-centered design. In order to do so, we must understand people—their behaviors, attitudes, needs, and goals. Whether the final product is a website, software application, mobile app, or interactive kiosk, a user-centered design can only be achieved if we know who is going to use it and if that knowledge informs our design. An entire arsenal of user-research methods can be employed to achieve a user-centered design. Personas are yet another tool that can be used to encourage decisions based on a real person’s needs, and not on those of a generic and undefined “user.”
Definition of a Persona
A persona is a fictional, yet realistic, description of a typical or target user of the product. A persona is an archetype instead of an actual living human, but personas should be described as if they were real people.
The description should be thorough, including details about the persona’s needs, concerns, and goals, as well as background information such as age, gender, behaviors, and occupation. This focus on a singular individual—or a small set of individuals, if using multiple personas—fosters empathy for the specific users we are designing for, and helps us break away from the attempt to design for everyone. A persona doesn’t need to document every aspect of the imaginary individual’s life, but rather should focus on those characteristics that impact what is being designed. It is likely that a business will have several personas to cover the various aspects of their organization, with one or two of them identified as the main targets for each product or service, feature set, or content area of a website.
Personas work because designers and developers have the same tendency as all other people to be captivated more by concrete instances than by abstractions and generalizations. We need all product-team members to empathize with users and be willing to go the extra step to develop something that will work for the actual users. But if users are described in statistical terms and as broad profiles, that information will simply not lodge itself as deeply in team members’ brains as a distinct persona will.
Personas Are Not User Groups
Defining user groups or market segments is not the same as creating personas. When discussing broad categories of users, ranges must be used in order to summarize attributes of the entire group. These statistics are too impersonal, and are difficult to keep in mind when designing. In contrast, a persona is a singular user derived from these data ranges to highlight specific details and important features of the group. It thus creates a narrative that is much more digestible and memorable, which in turn increases the likelihood of continued use throughout the design phase and beyond.
When to Create Personas
“As early as possible” is the best guideline for when to create personas. Of course, personas must be based on user research in order to be at all accurate and representative of actual users of a product. Personas are made-up people, but they should be made up based on information about real people. (Imaginary-friend personas that you dream up without any basis in the real world may describe the users you hope to get but will not reflect the way people actually are. Design for somebody who doesn’t exist and you’ll have no customers.)
Ideally, the persona-creation process should be a part of the research phase for a product or feature, before the actual design process starts. Field studies, surveys, longitudinal studies, interviews, and other methods of user research should be conducted first to define characteristics of typical users. (Keep in mind that any self-reported data, such as that resulting from focus groups and surveys, is possibly misleading and should be verified through other methods.) Once user research has been completed, personas and scenarios can then be derived from that data.
Guidelines for Creating Personas
Persona creation is best done as a team, not because it is difficult, but because it will garner more support for the use of personas from team members able to contribute to the process. One of the main arguments against using personas as a design tool is that they are not realistic. By including team members in the process and exposing them to the raw data from user research, it will be clear that the traits and behaviors of each fictional user are based on actual aggregated data accumulated from real users.
To initiate the persona-creation process, start with identifying characteristics of users observed from user-research activities. Group these attributes into clusters to begin forming clear characters. If several seem too similar, merge them together or eliminate any groups that appear less important to the business. Once distinct roles emerge, add details to make the character more realistic, believable, and memorable.
Common pieces of information to include are:
- Name, age, gender, and a photo
- Tag line describing what they do in “real life”; avoid getting too witty, as doing so may taint the persona as being too fun and not a useful tool
- Experience level in the area of your product or service
- Context for how they would interact with your product: Through choice or required by their job? How often would they use it? Do they typically use a desktop computer to access it, or their phone or other device?
- Goals and concerns when they perform relevant tasks: speed, accuracy, thoroughness, or any other needs that may factor into their usage
- Quotes to sum up the persona’s attitude
Your goal should be to create a believable and alive character. Avoid adding extraneous details that do not have any implications for design. While a name and photo may seem irrelevant, their function is to aid memorability, which is the #1 job of a persona: to make sure that all team members remember the users they’re building the product for. On the other hand, a lot of unessential details can overwhelm the relevant ones and make them harder to remember.
Thus, each piece of information should have a purpose for being included: if it would not affect the final design or help make any decision easier, omit it. For example, identifying a persona’s favorite variety of wine would likely not help when designing an intranet, but could be very useful when designing a forum or marketplace for sommeliers and serious wine enthusiasts. Behavioral qualities such as being detail oriented may imply that the individual would need to see specific data points or aspects of a product before being convinced to buy, while valuing speed could suggest a need for an efficient and streamlined design.
Persona-Focused Design
The main benefit of using personas is that they create a common, more precise vocabulary for describing a certain type of user and thus focus design efforts on a common goal. In meetings, the persona’s name acts as shorthand for the full set of attributes, desires, and behaviors that need to be considered when making design decisions. If instead you tried to reference what “the users” would want, each individual in your meeting would interpret who those users are and their needs differently. Further, this “user” definition would shift based on each person’s mental model of what is being discussed. Framing a statement around a specific persona breaks the listeners out of self-referential thinking and removes the speaker’s reliance on opinions, shifting the discussion away from personal judgments toward that particular persona’s needs. Once the team can easily picture the same set of users, it can create better designs for them.
When making design-strategy decisions, those functionalities that would most benefit a persona should inform which features to implement and prioritize. Usually, one or two personas should be identified as the main targets for a product, or for a feature set within a larger product. Avoid wasting time designing and building extraneous features that aren’t useful to the target persona(s). This practice of focusing on only pleasing a particular user—or even two users—helps designers avoid having to create an interface that handles every edge case imaginable. You can’t design something to please everyone! But, it is possible to design an experience that is enjoyable and usable to a defined set of target users.
Ongoing Benefits of Personas
Strategizing and making design decisions are the primary uses of personas, but there are several other ways in which they can be of use past an initial design phase. In fact, even if personas were not created at the onset of the design phase, it’s still worthwhile to create them for these later activities.
When working with an outside agency or consultants, clearly defined personas provide an easy way to describe the target audience of a product or service: just list the personas’ top attributes, or hand over the full documents for the agency to reference. Once a design is created, personas can be used as a guide for expert reviews. For each top task or area of a website or application, consider how each persona would deal with the process to determine potential issues within an interface.
Recruiting participants for usability studies can also be made easier with personas. Consider personas as templates for prospective recruits; common traits across several personas or a persona’s distinct characteristics might be useful screening criteria for some if not all of your study participants.
If the website or application is already live and running, personas can be used for segmenting analytics data to evaluate the behaviors and use of real users. These segments are not only useful in cutting down the sheer amount of data to analyze at a time, but they also support the ongoing validation and refinement of the personas as living documents rather than something too precious to ever alter.
