This handbook page defines the process for creating user personas only.
At GitLab, we use two kinds of personas that we create based on data-driven insights that focus on user needs and emotions:
User personas - Used by UX professionals and Product Managers (PM) as a mechanism to connect with end users' needs, motivations, behaviors, and skills. Owned by Product Managers.
Buyer personas - Focus on the high-level goals of potential customers who may or may not be potential users. Owned by the Marketing team.
This insightful article by UX Collective goes into great detail on these differences and more.
User personas are developed to be useful to both Product Managers and designers. They can be used to help understand the priority of potential features, increase the empathy in our communication and presentation to our users, and help shape design choices by understanding the background of our users. Each user persona is crafted to have a high amount of accuracy so that the information can remain useful for our stakeholders over a long period of time. Because of the importance of obtaining highly accurate information, the process of creating each persona is very detailed and can take a significant amount of time to research.
Each persona in Gitlab's persona page has the following traits, which are critical in defining user personas:
Our Simone (Software Engineer in Test) is a good example of many of these.
Not all of the additional details are necessary, so it can be helpful to discuss with stakeholders to know which could be useful. If there is any doubt, a guideline is the more detailed, the better.
The process for building out user personas is based on data obtained through user research. The following steps are designed to provide teams with the data they need to build out a new user persona with a high degree of confidence and accuracy.
Stakeholders are team members who are likely to use this user persona in the process of their own work. They will typically be Engineers, Product Managers, Product Designers, and so on, who have experience dealing with the persona you are trying to build. For example, if you are building a persona for a security analyst then your stakeholders should have experience with building security tools for those users.
The goal of this step is to increase our understanding of how this user persona will be used and which screener questions you will use to find your population of users.
The second step is to interview between 5-10 GitLab team members who have the same or a similar job title to the user persona being created. Schedule the meeting for 1 hour, but be aware that you may not end up needing that much time.
The goal of this step is to expand on the information already gathered and to interact directly with the population you are trying to understand, which will help us know that we are asking the right participants the correct questions.
To conduct these interviews:
This is a critical step! The purpose of this step is to validate and prioritize the characteristics derived from our internal interviews and to establish the differences between our expectations and real-world findings. These moderated interviews should take approximately 1 hour. Recruit 8-10 participants for a given persona, focusing on participants who reflect the general makeup of the market. The goal of these interviews is to connect with our users and fill out the framework of our user persona with real user data.
To kick off participant recruitment, refer to the UX handbook guide on how to recruit and schedule participants. Open a recruitment issue and write down the screener questions derived from your previous research Step 2. Use the handbook page on writing screener questions for help, if needed.
After enough participants have been recruited and scheduled, it is time to conduct the interviews! To prepare for these interviews, be sure to understand GitLab's handbook page on how to facilitate a user interview. More help can also be found in our discussion guide template.
To help streamline data intake during interviews, you can use this Persona Interview template (Google Form) as a script and tool to fill in participant responses. For additional note taking, you can use the note-taking template.
A section of the external interview is dedicated to building the Jobs to be Done (JTBD) for this user persona. This approach focuses on addressing the following points:
If you are not confident with the Jobs to be Done for your persona after collecting this information, then you can follow this small guide on how to increase your confidence.
To conduct these interviews:
If you are using the Google Form template as described above, then the data synthesis will be a similar process for each round of research, and comparing all of the results will be easy. If you need more help codifying the results, this handbook article on data synthesis may help.
For all open-ended questions, you first have to transform the qualitative data into something easier to understand. Do this by clustering responses into themes and tallying the counts of all themes. An example of this can be found in the table below:
|Question asked||Participant’s answer||Themes|
|What obstacles do you face when trying to accomplish the goals for your job?||Sometimes when I don’t see that a coworker has sent a merge request, it can take a while for me to approve it.||Missed communication|
For all close-ended questions, document the number of times each answer was given across all participants for each question to identify trends.
Once you have all answers counted, look at how many participants answered each question and evaluate the data for any trends. There are no set rules for this analysis, but some trends to look for include:
|Trend to look for||Example|
|50% or more of participants selecting a small handful of answers||Answer A: 60%
Answer B: 20%
Answer C: 10%
Answer D: 10%
|A large drop off in certain answers compared to others||Answer A: 40%
Answer B: 40%
Answer C: 10%
Answer D: 10%
When the data for each step of research is summarized, compare the results with the previous step. If your data surfaced results that were unexpected, try to understand what possible assumptions were made in the research, or even what mistakes were made, if any at all.
Include these findings as a part of our results, because if they are assumptions that were made once, we will likely make them again.
When all of the data has been collected and summarized, it's time to update the Roles & Personas handbook page.
Copy the text from one of the already existing user personas, and paste it below the last persona that is currently filled out. Edit the information for the persona you have collected data on, and double check all of the information, including the name and title of the persona.
Assign the merge request to one of the managers found in the 'Maintained By' section on the same Roles & Personas page.
The most common ways that personas become misaligned is when there is a business or technology change, or when there is a change to the user base. This helpful Nielsen Norman Group article goes into more detail on both of these if you are unsure on the difference or how to recognize them.
If stakeholders believe that a particular user persona no longer provides the information that it needs to, or if market data is indicating a change that impacts a persona, then it's time to update an existing persona or create a new one. Message the UX Researcher in your stage group to begin the process.