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, who are also the DRI on persona-related research efforts.
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 Product 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 should have the following traits:
(Optional)
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.
It's strongly recommended to consult with a UX Researcher at the start and conclusion of each step. This will help set you up for success as you start efforts and also provide you with another set of eyes to review your data.
Stakeholders are team members who are likely to use this user persona in the process of their own work. Ideal team members would typically be Software Engineers, Product Managers, Product Designers, and so on, who have experience with tools for 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 what information is most important to ask in the interviews and which information to use in the screeners to collect participants.
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. This meeting should be approx. 30 min, but you may want to allow more time if you need more information.
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 use the screener derived from your previous research Step 2. Use the handbook page on writing screener questions for help, if needed.
Use the summarized information created from Step 1 and [Step 2 to craft the script for the external interviews. The first section of the script should focus on the top jobs of the persona, and the motivations and frustrations of those jobs.
If you are unfamiliar on Gitlab's JTBD, here is a small overview and guide
Later sections of the script may vary depending on what your past research indicates as important to the persona. You will most likely want to ask questions about key tools your persona uses, any areas of Gitlab they use or have trouble in, or other teams that provide essential work to your persona.
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 may use this Persona Interview template (Google Form) as a script and tool to fill in participant responses.
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. 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% |
As you summarize each round of research, you can compare the answers from the previous participants to the most recent participants. If you see unexpected results, try to understand the reason for the differences and incorporate those into your final insights.
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.
Personas that were originally independent from one another may become less distinct over time, either due to changes in roles or job duties. When stakeholders believe there are overlaps between two or more personas, there are some steps to follow prior to making a change.
There is no “correct” number of personas that a company should have. In general, personas should be distinct enough from one another, so that one persona is not easily mistaken for another. The more personas you have, the greater the chance that team members will not remember distinct information about them. A simple way to determine the number of personas within a company is to identify the most important user groups that you want to target with your product and create personas based on those groups.
Personas should be detailed enough that they can be believable, but should be broad enough to represent specific types of user groups. The level of detail desired for personas will depend on the goal of the effort. Ideally, personas should be detailed enough to at least cover each of their goals, motivations, and frustrations.
Personas should be evaluated over time to assess whether they represent the main types of users that were originally identified. Personas are seen as snapshots in time, so they can become outdated if you fail to consider changes in the business, marketplace, and demographics about your users. If you examine those factors and determine that there are differences between your data and current personas, additional research could be needed before you commit to update personas. If you need advice on potential research for personas, please consult with UX research for assistance.
There is no correct frequency for when to update personas, but companies should take into account time and resources needed to update personas (in addition to factors discussed above). Also, it is important to consider how much the product or user experience has changed since the persona was last researched. Generally, personas that have been stagnant for about 5 or more years might not be as valid as personas that are more up-to-date.
External research looked into the amount of time that employees at large (more than 500 employees) organizations spent on creating user personas. Overall, there were differences in the amount of time it took to create personas when using non-empirical data (leveraging past data or knowledge about a user population) compared to empirical data (utilizing research efforts to learn about a user population). For projects that used non-empirical data, the amount of time needed to create personas was approximately 55 hours. For projects focused on obtaining empirical data, large companies needed approximately 102.5 hours to create personas.
