Persona: A User's Guide

Simply put, a persona is a realistic description of a fictional character representing the target user of a product. Unlike customer segments, which reflect relatively homogeneous groups based on demographic, behavioral, or psychographic factors, a persona represents a specific individual. This persona may describe someone who is already using our product or a potential user.

A persona can include various information, depending on what is considered most important and valuable at a given stage of the project and in the context of our product. It is essential to remember that the purpose of using personas is to continuously refer to them throughout the digital product development process by the entire team. Therefore, a persona should not be overly detailed or filled with excessive content.

- A suggestive photo - Reflects the characteristic features, disposition, or work context of the persona. The visual representation makes it easier to recall the persona and remember key traits.

- Name and demographic details - It is common to create a surname that reflects a distinctive feature of the persona, e.g., John Skeptic, Mary Workaholic, though this is not necessary. However, when creating a persona, avoid providing demographic information in ranges (e.g., 25–34) or location sizes (e.g., cities over 500,000). A persona is a specific individual with a defined age (e.g., 30 years old) and resides in a specific city (e.g., Warsaw). Focus on relevant information from the project's perspective. If the product is designed for corporate clients, omit details like residence or hobbies and instead include details like the person’s role in the company, the industry, and company size.

- A quote or life motto - This element helps in easily recalling the persona and reflects important traits or beliefs. For instance, if the project involves saving money, would the persona prefer the saying "A penny saved is a penny earned" or "You have to steal the first million"? It is a good practice to use a real quote or combine various user statements from previous interviews. However, if such sources are unavailable, you can create a quote using your imagination.

- Technical competencies - This is crucial for designing digital products—how proficient is the user in using the internet, computers, smartphones, or tablets? Which devices do they use? What is their experience? This part of the persona is often presented graphically rather than textually, such as using icons.

- Knowledge or expertise level in the service area - This can also be useful information—Is the persona a novice or an expert in the subject? Are they a demanding customer or do they rely on support and need expert assistance?

- Needs, habits, and expectations in the given area and regarding the product or service being created - These are key details that help focus on the most critical elements that define the persona. This may include the context of use, criteria for choosing a service, or high-level needs such as "speed," "reliability," or "low cost"—important to distinguish the persona from others.

- Pain points and frustrations - As with the previous point, focus on the context of the process. This part highlights the user's problems that we aim to solve and what we should be cautious of to avoid errors.

Personas are effective because many of us, including developers, designers, and stakeholders, respond better to concrete examples than to abstractions and generalizations. Personas allow all team members to "step into the user’s shoes," understand why we do what we do, and make decisions that are focused on real users' needs. If we describe users only in general terms, in statistical categories, as high-level, broad profiles, this information will not stick in the team’s memory as well as the representation of a specific (albeit fictional) individual.

Another advantage of using personas is that they create a common and more precise understanding of the user and standardize the vocabulary used by the team in the context of the target group. During meetings, the persona's name alone already conveys a set of needs, traits, and behaviors that should be considered when making design decisions. If we instead ask what "users" would want, each person in the meeting could interpret differently who those users are and what their needs are. Moreover, the definition of "user" might vary depending on each participant’s mental model. By framing the discussion around a specific persona, we remove the risk and temptation of relying on our personal judgments. When the team can easily visualize the same group of users, it can create better designs with less effort and fewer unnecessary discussions.

Personas are also very useful when making strategic decisions. By referencing the needs and pain points of our key personas, we can determine which features to implement and prioritize, while avoiding wasting time on unnecessary functionalities.

Furthermore, personas serve as an excellent starting point for many other modeling and mapping tools, such as empathy maps, use scenarios, Customer Journey maps, and Value Propositions.

It's best to create personas at the earliest possible stage of a project, but they should not be based solely on our instincts and imaginations. To be accurate and relevant, personas must be grounded in user research data. Although personas are fictional characters, they should be created based on information about real people. It is advisable to create personas collectively as a team. This increases the likelihood that the entire team will be more willing to use and refer to them. This process also integrates the team and enhances its work culture. If we want both the team and project stakeholders to use and "believe in" personas, we must ensure they contribute to their creation or at least transparently communicate the process and efforts involved in building personas. Additionally, it’s important to educate them on the significance and benefits of using personas, which is the main goal of this article.

One mistake to avoid is creating personas and then "shelving" them—failing to communicate them within the team and among project stakeholders, treating them as a finished artifact not subject to discussion or further changes, or even viewing personas as an end in themselves. Personas should be living documents. They can be referenced during meetings, planning, brainstorming sessions, and workshops. It is also worth revising them periodically, especially after conducting user research or testing, to ensure they remain current and accurately reflect our knowledge of users.

Another mistake is creating too many personas. The optimal number, depending on the project's scope and complexity, is between two and six personas. If there are more than two, it is advisable to select one or two primary personas representing the most significant or profitable customer segments, while the others serve as secondary personas. It’s important to note that the more personas we create, the harder they are to remember, and the more challenging it becomes for team members to recall their distinctive features, which significantly limits the benefits of using personas.

Personas for the R-Flex project were created as a result of collaboration between Product Owners, the UX team, and stakeholders in the following way:

1. We started by creating a persona template in Miro, listing areas we considered important for the project and where we wanted to gather user insights. We included guiding questions in each area. The template was created with the intention of using it during a workshop in Romania.
   
2. We analyzed data from a quantitative survey, focusing on differences between segments. The survey included questions about currency exchange habits and behaviors, as well as demographic questions like age, the industry in which the respondent's company operates, and their role in the company. We treated the quantitative data as the first input for personas (which we wanted to verify and discuss during the workshops).
3. We conducted a workshop, inviting dealers who work directly with clients, and together we tried to complete the prepared template. Several additional details emerged, providing us with a broader context of how clients (focusing on micro and small enterprises) function as R-Flex users. The meeting was recorded.
4. After the workshop, we revisited the recording and, in the PO-UX team, selected the most important information to include in the personas. We prepared two personas, aiming to capture as many differences between them as possible.
5. We conducted similar workshops in other network banks (Croatia and Hungary), and in Hungary, we also conducted in-depth interviews with clients.
6. We analyzed the similarities and differences between countries, resulting in two universal primary personas. At the same time, each network bank has its own personas, which can be used when creating country-specific functionalities and can also be used by local marketing teams.
7. In the final step, we graphically packaged the collected material.

Personas proved to be a helpful artifact during Customer Journey mapping for the deposit account opening process. The information contained in the personas perfectly complemented the knowledge gained from dealer interviews and helped in better understanding the client’s perspective, as well as developing ideas for improvements that could be implemented on the platform.

In summary, personas are one of the tools available to help us make decisions based on the needs of specific people rather than the needs of a general and undefined "user" or segment. They support the team in a shared understanding of user needs and provide a concise, easily digestible summary of what we know about our target group.

I strongly encourage you to use this tool in your projects. The experience with R-Flex has shown that creating personas is a creative and integrative process that opens your eyes to new, previously unknown user characteristics.