Skip to main content
How I Built User Personas

How I Built User Personas

By Paulina Contreras•
User Persona

This is the story about the process carried out to develop User Personas for a retail company, as well as the books, articles, and step-by-step guide to define them. This article somehow becomes my own summary of everything done, and what worked to accomplish the task of building Personas.

Table of Contents

Defining Personas

But What are User Personas, Personas, UX Personas? In this adventure, I found many stakeholders who don’t know what they are, what function they serve, and how they can use them. So let’s start with that shared understanding.

“A persona is a fictional, yet realistic, description of a typical or target user. A persona is an archetype instead of a real living human being, but they should be described as if they were real people.”

NNGroup, own translation

Example of a UX Persona

Own creation

User Personas are a tool that allows us to create a story around our end users and empathize with them.

Other Benefits of User Personas

  • They simplify the process by designing for a few who represent many.
  • They facilitate prioritization of the audience for which you’ll design/ideate a solution.
  • They help identify innovation opportunities.
  • They facilitate communication among all stakeholders around the customer group(s) being designed for.
  • They facilitate transmission of research findings, so the entire team is on the same page.
  • They challenge our assumptions about users/customers. Minimizing the risk of “designing for me” (what I think we need) or “designing for the app/web user” (because it’s still too unspecific a definition of who that user is).

How to Use User Personas?

We can use User Personas for, among other things:

  • Recruiting users for prototype testing.
  • Prioritizing features. Evaluating from each Persona how usable, useful, and desirable each feature is.
  • Ideating new features.

Difference from Other Segmentation Methods

Difference from Marketing Personas

The main difference between market segments and User Personas is that the former are based on demographic data, distribution channels, and purchase behavior. While Personas are grounded in behavior and goals. They’re not the same and don’t serve the same purpose. Marketing Personas help us in the sales process, while UX Personas contribute to product definition and development process. However, both contribute information to each other and can serve as an initial filter to limit the interviews to conduct for building User Personas.

Graphic showing difference between Market Segments and Marketing Personas

Own creation

Difference from Proto Personas

Proto Persona is a more summarized version of a traditional User Persona, and is created when there aren’t resources to conduct user research. It’s based on any research that can be obtained from indirect (secondary) sources, such as interviewing internal stakeholders to obtain information about the user(s) you’ll be working with. One of the main advantages of this simpler version is the lower time and cost to create them. While it continues allowing alignment of stakeholders’ vision about the end user and provides a tool for accepting user-centered design. Despite containing less precise data and sometimes being based on assumptions unlike a User Persona, they help interested parties and team members be more empathetic with end users’ needs.

Beginning

The User Persona Systematization Process

I began this task with great initial uncertainty about how to approach it, what process to follow, and how to deliver something useful to the team. That’s why, in addition to the stages I followed, here are some questions that accompanied me at each stage.

This process corresponds to a description of what was done to build the Personas, more than a prescription of what was going to happen. I’d like to say I knew exactly what path to follow, so faced with that uncertainty, I dove into available literature and read everything I found in Spanish and English (I left a list of the texts I recommend most at the end of the article).

Here’s a summary of the process stages and the questions that accompanied me at each one.

Process diagram for building personas

Own creation

I. Define the Users of User Personas

Who will use the Persona tool? It’s almost a circular question – we had to define the users of the User Personas. In this particular case, the future users of the Personas would be members of an area within the company – in this case the digital area, which corresponds to a large team of people who are responsible for designing proposals and solutions for customers, mainly from digital channels but with an omnichannel view. It was important to define the potential users of this tool since validation of the user persona tool, as well as the depth of information for each persona, depends on who will use it later. So with this clear, we moved forward.

II. Collect Meaningful Data

The first thing was to begin collecting relevant information for building these Personas, in this case from secondary and primary data sources.

Secondary Source Data: 1) Previously created User Personas, we used at least those created up to 5 years back from the company both from the UX team, Marketing, and the Business Intelligence area. In total, more than 40 Persona profiles were found. 2) Research and available publications from the retail industry regarding user behaviors during and post-pandemic, national and Latin American, were also analyzed. 3) CENSUS data was reviewed to see average income and home ownership in the general population, which was relevant given the company’s sector. 4) National studies on the population’s technology level, most-used channels.

Primary Source Data: Direct interviews with users and user surveys were conducted. Both sources were done specifically for this Persona building, as well as interviews and surveys conducted during the previous year (2021), to have the pandemic and post-pandemic context within changes in customer/user shopping habits. The number of interviews grew until thematic saturation was achieved.

III. Analyze Business Intelligence Team’s Internal Segmentation

The internal BI (Business Intelligence) team has its own customer segmentation based on quantitative data (where they buy, what they buy, when, etc.). This gives us a rich source of knowledge about our customers’ purchase behaviors, such as cross-channel purchases (digital, physical), and analysis by segmentation type. Plus changes in post-pandemic shopping patterns.

A small aside. At this stage, a personal question arose, which I later transferred to the work team: whether to continue with the segmentation the BI team already had, or create our own from UX. Thus, a conversation arose about the pros and cons of each version. Continuing with the customer segmentation proposed by Business Intelligence allowed us to have a common language known by business teams, but on the other hand, the BI team’s segmentation is based on the purchase (type, quantity, channel), and our goal was to understand the behind that purchase – the why, i.e., the Motivation or Goal of the customer/user/person making that purchase, and from that distinction, we continued with our version of User Personas.

As you can see up to here, I didn’t start ideating Personas from scratch. This is a company with years in the market and deep knowledge of its customers. There was already lots and lots of quantitative and qualitative customer data available, which I didn’t discard – quite the opposite, it turned out to be the first source of information to answer who are our User Personas today? However, there was a lot of information (40 User Personas, plus customer segments from the BI team)… so with that amount of data, I moved on to systematize, find patterns, and see what emerged.

IV. Identify Behavioral Patterns to Segment

Using quantitative and qualitative data from diverse sources (internal and external) we moved on to shape the user personas. I relied on the literature. To systematize the data, I identified some relevant points these Personas under construction should have, and grouped them according to some attributes, among which I highlight:

  • Motivation: What the person wants or needs. It’s why the Persona is taking action. This turned out to be the most relevant aspect of the personas. Identifying their motivator, and how it linked to their relationship with the company.
  • Relationship with the company: Needs, pain points, expectations with the company.
  • How it differs from other Persona profiles: How we could identify them if we see or talk with them.
  • How they shop across channels: Whether they’re fully digital/store, flow between channels, etc.
  • Technology level: Channels they use, and how comfortable they feel with technology.
  • How it relates to BI segmentation: A very high-level analysis was done to contribute to this language already known by product teams, and understand how these personas relate to the BI team’s customer segmentation. Clarifying that both views don’t have a perfect match since they’re built on different criteria.

This synthesis and pattern-finding work, I did in the Miro tool, but it could have been in Figma, Excel, on paper, or whatever allows iterating, writing, moving elements, and that others can see simultaneously to receive feedback.

On the Y-axis I grouped the Personas, and on the X-axis the attributes (Technology level, Motivation, etc.). Not all quadrants are complete, because it doesn’t always apply, or because I didn’t have the answers. It’s worth mentioning it was an exercise of constant iteration – the Personas became clearer as I completed the attributes.

Table with personas and their attributes

Pattern search schema for Personas

An interesting point is that new Persona classifications appeared that weren’t considered among the historical ones (those already created by previous teams), but rather appeared as a result of interviews, testing, confirmed by studies in the area.

Thus emerged a total of 8 Persona profiles: 4 Primary Personas and 4 Secondary Personas (of greater and lesser relevance).

Example of resulting personas

Screenshot of pattern search work based on relevant attributes according to customer type (Personas). Not readable since it’s the actual work done.

V. Iteration with Sales Staff

Having an initial definition of the identified Personas along with a brief description of them, I did the exercise of presenting these Personas to store salespeople, since they’re the ones in direct contact with users, and I saw it as a way to triangulate information and contribute to the validity of this research’s results. For this exercise with salespeople, I relied on the validation instrument: Persona Perception Scale (Salminen et al, 2018), and subsequently generated an open interview.

As support for this iteration, I created a research artifact (image below), like cards (printed on both sides):

  • on one side: each Persona’s goal and characteristic phrase were described,
  • on the back: a general description of Motivation, Pain, and Need.

Presenting personas to other teams

Research artifact as cards representing each persona, for work with salespeople.

From this exercise with salespeople, we iterated on the Personas’ description and arrived at a clearer and deeper definition of each one. This was the version presented to different internal stakeholders.

VI. Presentation to Specific Teams

We met with some groups of internal stakeholders with the purpose of getting their vision and feedback on the Personas. We considered it relevant that these meetings be prior to the general presentation of Personas to the entire area, so we could iterate and arrive at a more defined version, with consensus on the necessary depth of each one. Thus we met with 3 internal teams.

From these meetings we iterated and deepened the personas’ description to respond to doubts and concerns of teams that will use them. This iteration led us to the final version of each Persona that we presented to the entire area.

The Persona template looked like this:

Final persona template presented to other teams

Final Personas template we presented to teams.

Frequently Asked Questions Document

We created a document with questions that kept repeating in initial teams we presented the Personas to (and we anticipated other questions we thought might come up) along with their answers, grouped by theme. All with the purpose of supporting this understanding and subsequent adoption of User Personas.

Among those Frequently Asked Questions are:

  • What data were the Personas built on?
  • Why or when should I use these personas versus BI segmentation?
  • Does this represent all our customers?
  • Why Primary and Secondary Personas? What does it imply, how is it used?
  • Why these personas?
  • Do they represent all our customers?

This was a living document shared with the entire area, to incorporate doubts, ideas, and conversations on the topic.

VII. Present Final Personas

We presented the final version to the entire Digital area, which includes both business representatives: POs, BAs, and UXers.

We organized the presentation this way:

  1. What are Personas? Why build them?
  2. Methodology or process: How we arrived at them
  3. Difference from internal BI segmentation
  4. Personas: Primary and Secondary. Detail of each. What differentiates them from each other.
  5. Next steps

VIII. The Next Necessary Step: Adoption

We finished creating the User Personas, validated and presented to the team that will use them. We’ve finally finished the work!.. Not so fast. Having the personas is just the beginning. What good are these customer descriptions rich in content and context if they’ll be stored away in some forgotten document? What good are they if they’re not used? Thus the next phase is equally or more relevant – Adoption of User Personas by teams, and since it’s not brief, I’ll describe this experience in a future article 😀 (you can check it here)

Conclusion

The above description corresponds to User Personas, our current users, but we still need to start thinking about future Personas, those we want to reach as an organization, our potential customers and user personas. How do we make them become our customers? That’s a whole new topic and gives much more to discuss.

Updating Personas

There’s no single definition about how often to update Personas, because it depends on how often internal changes occur, for example in the company’s services, the way of delivering a digital and/or in-person experience. But external political and cultural changes also influence, such as the social uprising in Chile in 2019, the 2020- pandemic, etc. I believe it’s at least necessary to review/confirm the information annually.

Inclusion

Up to here I haven’t added the inclusion lens to these Personas, and by inclusion I mean a wide range of characteristics that make us unique, such as our gender, race, nationality, disability, indigenous identity, and others as relevant to the planet we live on today as sustainability perspectives. I believe adding these lenses is tremendously important for advancing innovation in our services and products, but above all to advance as a society toward one that develops differentiated solutions to the particular needs of human beings and our planet. The Persona-building approach I’ve described in this article I consider a first step for teams working on developing initiatives and solutions for our user personas to consider the (initial) variability our customers/users/personas have, since until now the view has been “our customer,” and who is that customer? Do they look like me, like you, like my neighbor, like my mom? Who do we think about when we design solutions, or who do we test a new App feature with?

Working with Others

This work could never have had the result obtained without collaborative work. I led this User Persona building project but worked closely with the brilliant UX Researcher Alejandra Veas Suárez. That’s why in the text I speak of me, and of us, in different places, since there are moments when I worked independently (especially the initial part of data collection and analysis), but together we refined, iteratively validated with different stakeholders, and presented the final version to the team.

Books and Articles I Recommend Most

Here are the resources that helped me most in this task. Just mention that the first two were the main documentation for building these User Personas, so if you have little time, go straight to them.

  1. [Book] About Face, Alan Cooper.
  2. [Book] The Persona Lifecycle: Keeping People in mind Throughout product design, Tamara Adlin, and John Pruitt.
  3. [Book] The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, Alan Cooper.
  4. [Article] Putting Personas to Work in UX Design: What they are and why they’re important.
  5. [Article] Personas - A Simple Introduction, Interaction Design Foundation.
  6. [Article] Why Personas Fail, NNGroup.
  7. [Article] The Story of Spotify Personas.

There’s still much to advance in defining our user personas, both in my own organization and many others in the sector, such as adding unique characteristics, particular needs for a more diverse group of Personas. But you have to start somewhere.

I hope this article has been helpful in your own Persona-building adventure. I’ll be happy to read comments, corrections, and your experience with Personas (you can go to the LinkedIn post thread), or contact me to continue the conversation 🙂