Who Uses Personas in Requirements Engineering:
The Practitioners' Perspective

label1] Yi Wang<EMAIL_ADDRESS>
label2] Chetan Arora<EMAIL_ADDRESS>
label1] Xiao Liu<EMAIL_ADDRESS>
label1] Thuong Hoang<EMAIL_ADDRESS>
label2] Vasudha Malhotra<EMAIL_ADDRESS>
label1] Ben Cheng<EMAIL_ADDRESS>
label2] John Grundy<EMAIL_ADDRESS>
[label1]organization=Deakin University ,

[label2]organization=Monash University,

Personas are commonly used in software projects to gain a better understanding of end-users' needs. However, there is a limited understanding of their usage and effectiveness in practice. This paper presents the results of a two-step investigation, comprising interviews with 26 software developers, UI/UX designers, business analysts and product managers and a survey of 203 practitioners, aimed at shedding light on the current practices, methods and challenges of using personas in software development. Our findings reveal variations in the frequency and effectiveness of personas across different software projects and IT companies, the challenges practitioners face when using personas and the reasons for not using them at all. Furthermore, we investigate the coverage of human aspects in personas, often assumed to be a key feature of persona descriptions. Contrary to the general perception, our study shows that human aspects are often ignored for various reasons in personas or requirements engineering in general. Our study provides actionable insights for practitioners to overcome challenges in using personas during requirements engineering stages, and we identify areas for future research.

Requirements Engineering, Personas, Human Aspects, Survey, Interviews.

§ INTRODUCTION

Requirements engineering (RE) focuses, among others, on understanding the needs and goals of the users who will interact with the system under development <cit.>. One effective way to achieve this is through the use of personas <cit.>. Personas are fictional (yet specific and concrete) characters that represent different user types, and they help to create a common understanding of the users' demographics, needs, behaviors, motivations, and pain points <cit.>. By using personas, requirements engineers can design systems that meet the needs of the intended users and ensure that the system is user-friendly and effective <cit.>.

Personas have been widely adopted in numerous fields, such as marketing <cit.>, product design <cit.>, education design <cit.>, and user experience design <cit.>. In RE, personas are anecdotally known to be widely used <cit.>. In the early stages of RE, personas are known to be typically created based on research and analysis of user data, such as surveys, interviews, and usability tests of previous versions of the software <cit.>. Despite the anecdotal evidence on the widespread use of personas in software development, there is limited research on how practitioners use them in RE. For instance, to what extent are personas used in practice, the kinds of projects where personas are more likely to be used, or the challenges associated with implementing personas in practice? There has not been much research to answer such questions.

To address this gap, this paper presents the results of a survey and interviews with practitioners to explore the status quo of persona usage in the industry.  Our main objective of the survey and interviews was to investigate the use of personas in industry, specifically including (1) the use of personas in software projects for customers, businesses, and government in different-sized companies, e.g., large corporations, small-to-medium enterprises (SMEs) and startups; (2) the key job roles involved in using and creating personas in the industry; (3) the methods utilized by different roles and companies to implement personas, including approaches for identifying the key `human aspects' of users <cit.> and providing feedback on current methods or standards, and (4) the challenges associated by practitioners with personas.

As mentioned above, one key factor (among others) we were interested in personas was the coverage of human aspects, such as personality, gender, motivation, culture, and physical or mental issues <cit.>. Human aspects have recently received increasing attention in RE research <cit.> and have become an integral part of the software development process, as developers aim to develop systems that are more responsive to user needs and better align with the user goals and values. Given that personas, by their very definition, emphasize the individual attributes (or human aspects) of users, we felt it was imperative to include a section in our survey and interviews specifically examining the extent to which these aspects are represented in personas.

We surveyed 203 practitioners and interviewed 26 practitioners to understand the usage (or not) of personas in their context. The survey included software developers, UI/UX designers, business analysts, project managers, and user researchers. User researcher was a slightly unconventional role that we came across in our survey. The role is responsible for understanding user behavior, needs, and motivations to inform the design and development of products and digital services. In our interviews, we had similar roles and a CEO of a startup for an e-learning system. We had good coverage of participants from large corporations, SMEs and startups, and people working in different application domains, such as finance, education, cloud services, and virtual reality (VR).

Our study revealed that the usage of user personas varies significantly among different types of software projects and different-sized IT companies. For instance, personas are less commonly used in startups, government software projects, or in VR and gaming projects. Moreover, various IT companies and practitioners tend to have diverse preferences for methods to collect and analyze user data and generate personas. Some companies deploy dedicated data-driven platforms for collecting and maintaining user information for personas, whereas some companies (including startups) favor traditional RE methods to analyze user data and capture user requirements. Moreover, we observed that the human-aspect-information within personas can differ based on distinct application contexts. Notably, certain user groups, such as those with specific physical needs, often go unnoticed. Finally, based on our analysis, we identify some current challenges related to using personas in industry and propose future research directions. In summary, the paper makes the following contributions:

* To the best of our knowledge, this is the first study to provide empirical evidence on the extent to which personas are used in RE and the factors influencing their adoption. Our empirical evidence is based on a survey with more than 200 practitioners and interviews with 26 practitioners.

* We report on the types of projects and organizations in which personas are most commonly used and the factors that drive their adoption in these contexts.

* We delineate the key challenges associated with persona adoption in the industry.

* We identify gaps and recommendations for future research on the use of personas in RE.

§ RELATED WORK

Personas are a critical approach for UI/UX design and development teams (e.g., large development teams) to gain a better understanding diverse users <cit.>. Prior work has noted that personas are used more widely in software development than in other areas such as healthcare and education <cit.>.
Billestrup et al. <cit.> investigated the use of personas in software development and found that personas can facilitate collaboration between designers and developers not working closely together. However, using personas may also bring some risks, such as when personas describe the wrong user groups. To address the limitations of personas, <cit.> proposed using data-driven methods to generate personas to support business-to-business software development companies <cit.>. <cit.> demonstrated a generating persona tool based on the GPT-4 model and knowledge graph. <cit.> pioneered the guidelines for using personas as an essential medium for communication among development teams. Additionally, <cit.> suggested that personas should include human factors to represent the target users of software applications better <cit.>.

Personas are frequently used in different RE phases, such as elicitation and validation <cit.>. For instance, <cit.> have argued that personas can enhance the understanding of software product goals, behavior, and the characteristics of users and their interactions with the systems. Persona's content must combine the various phases of RE and design processes with user insights <cit.>. In particular, different personas can be allocated to different designers and software developers in software projects. Software developers can also use ad-hoc or imaginary personas to analyze potential requirements in RE <cit.>. Although the literature on the use of personas in RE is limited, a recent study highlighted that personas have notable shortcomings in RE activities, particularly in the analysis, specification, and validation of requirements <cit.>. Many methods are combined with personas to analyze requirements and guide design and interface development, such as scenarios, semi-structured interviews, prototyping, and storyboards <cit.>. For example, prior research has proposed a method that automatically generates 3D avatars based on persona data by observing user behaviors in the virtual environment <cit.>. <cit.> have found that scenarios and personas can help improve shared understanding of functional requirements, thereby reducing ambiguities in the requirements. Scenarios can also help to complement the contexts of personas and provide a clearer description of user requirements in RE <cit.>. <cit.> proposed a survey instrument (Persona Readiness Scale) to measure organizational readiness for personas. This approach can help to improve compatibility between the organizations and personas.

<cit.> pointed out that human-centric issues are incorporated into the critical SE challenges. Some researchers have investigated important human factors such as personality, emotions, motivation, culture, and so on <cit.>. However, due to a lack of knowledge of the design and evaluation of these human factors, software engineers can not incorporate human factors issues into the development process <cit.>. Thus, some persona prototype tools have been designed to help developers address challenges in their software projects <cit.>. <cit.> demonstrated how persona prototype tools are used in industry. More than half of the participants agreed that the persona prototype tool helps discover potential issues such as accessibility needs <cit.>.

All these existing works cover several important factors related to persona creation, information captured in personas, and the importance of personas in RE and software development. However, no study (to the best of our knowledge) has covered the practitioners' perspective of personas and the status quo of persona usage in the industry, which our study attempts to do with more than 203 practitioners in our survey and 26 participants in our interviews.

§ METHODOLOGY

Our study aims to understand the practitioners' perspectives on the usage of personas in different types of companies and industries for different types of software projects. We base our study on a survey and semi-structured interviews to collect different types of self-reported data. The Human Ethics Advisory Group at Deakin University (Faculty of Science, Engineering and Built Environment) reviewed and approved our study (reference: SEBE-2022-62). Our material used for conducting interviews and surveys is publicly available in both English and Chinese languages <cit.>.

§.§ Research Questions

Our study was structured around three research questions (RQs):

RQ1. How common is the use of personas across different software development projects?
RQ1 aims to investigate the current state of persona usage in the industry for software development. We analyze the type of companies that employ personas (e.g., big corporations, small and medium-sized enterprises (SMEs), and startups), the type of software projects at hand (e.g., the software as part of corporate projects, government projects, and developed directly for end users), and the roles that use personas.

RQ2. What are the current practices for building personas? RQ2 aims to understand the current practices around capturing the users' information in personas. To this end, among others, RQ2 delves into the inclusion of human aspects — delineated as human attributes such as age, gender, cultural background, and physical and mental abilities — in the persona construct.

RQ3. What are the main challenges associated with persona usage in software projects? RQ3 aims to explore the challenges that practitioners associate with the implementation of personas in software projects, to understand the reasons for their limited adoption, and ultimately assess the feasibility of addressing some of these challenges.

To answer these RQs, we adopted a sequential exploratory strategy to comprehensively investigate the use and construction of personas in software development <cit.>. Our approach began with in-depth, qualitative interviews with 26 practitioners spanning diverse roles and organizations. The interviews offered valuable preliminary insights, helping us understand the nuances, key themes, and patterns around persona usage.  Informed by these findings, we designed and administered a survey to 203 practitioners to quantitatively examine our findings on a broader scale. Below, we discuss the design of our interviews and survey studies.

§.§ Participants Recruitment

In our study, we aimed at recruiting a diverse cohort of participants.  To ensure the relevance of our findings, we mandated that participants have at least three years of work experience and are familiar with personas. Additionally, for survey respondents we also wanted to ensure that they held positions in IT/SE domains or were associated with companies operating within the IT/SE sectors (some responses were filtered out during analysis). We advertised our study to various social media, such as LinkedIn <cit.>, WeChatp <cit.>, and Twitterp <cit.>. We also recruited some interviewees via our professional networks. For the online survey, we distributed the online survey through Web forums (e.g., GitHub <cit.> and Reddit <cit.>), and social media (e.g., LinkedIn <cit.>, Twitter <cit.> Discord-related Groups <cit.> and WeChat <cit.>). After the interviews, we also sent our survey to interviewees and asked them to fill out and distribute it to related departments within their companies. We provided each interviewee with an incentive of 20 USD Amazon e-gift cards, 30 AUD Amazon e-gift cards, and 150 RMB red envelopes using WeChat. Each survey participant received an incentive of 3 USD, 5 AUD or 20 RMB, online gift cards or WeChat red envelopes.

§.§ Semi-structured Interviews Design

As the first step of our study, we conducted a series of one-to-one semi-structured interviews with professional software developers, UI/UX designers, IT project managers, business analysts, and user researchers. The interviews were conducted via Zoom <cit.> and VooV <cit.>. The semi-structured interviews were based on an interview guide that included questions on the advantages and disadvantages of using personas, human aspects, special user groups in persona creation, and usage of use personas in the software development lifecycle <cit.>. As practitioners had various roles and work experiences, we iteratively refined our interview guidelines after each interview. The final interview was organized into the following main stages:

(1) Introduction and background questions. In this initial phase, we briefly outlined our study, introducing RE, human aspects, and personas. Before commencing the interview, we reiterated key points from the consent form, ensured it was signed by the participants, and informed them about the audio recording. We emphasized that participants could skip questions they found uncomfortable and had the freedom to halt the interview whenever they wished. Following this, we initiated the audio recording and gathered demographic information from participants, such as their years of work experience, types of previous software projects, and familiarity with using personas. Discussing the background acted as an icebreaker and provided us with additional context to analyze data.

(2) General persona questions. In this section, we asked participants general questions about the usage of personas in software projects. We asked about the advantages and disadvantages of using personas to analyze software requirements, how personas can be used to derive user requirements, and how personas can be covered in the software development lifecycle. We also asked more detailed questions based on the participants' work experience. However, some participants reported having limited experience using personas in their current role, but they all understood them from previous software projects.

(3) Human aspects and special user groups questions. In this section, we asked participants about the inclusion of human aspects and special user groups in personas in software projects. Firstly, we asked if participants considered human characteristics and special user groups in personas. For those who confirmed they did, we asked self-reported questions to determine whether human aspects or special user group personas helped improve requirements quality, user satisfaction, success rate, etc. We also asked participants to identify which human aspects or special user groups are important in software projects. For those not using these components in their personas, we introduced example human aspects, such as personality and motivation, and special user groups, like low-vision users, inviting their perspectives on the potential merits of these inclusions.

(4) Personas usage questions. In this interview section, we aimed to gather information on how personas are commonly used in different software projects, including business, customer, and government projects. We refer to Table <ref> for the details of the interviewees' experience. For those with limited experience using personas for user requirements, we asked about the requirements analysis methods they used in various software projects. Additionally, we asked participants to discuss current methods' limitations and benefits. Based on their responses, we further probed their thoughts on how personas could address some of the identified limitations and provide additional comments.

(5) Wrap-up. We concluded the interviews with general questions, such as “Are there any additional comments or suggestions about using personas for user requirements in software projects?” and “Do you have any questions for us?” We rounded off by expressing our appreciation for the interviewees' invaluable inputs.

§.§ Survey Design

In the second phase of our study, we rolled out a survey targeting practitioners to answer our RQs. Our objective was to validate and expand on the findings garnered from the semi-structured interviews and further answer our RQs more comprehensively (see §<ref>). We created the survey in two languages - in English using Qualtrics <cit.> and in Chinese using Tencent Questionnaire <cit.> and Wenjuanxing <cit.>.

The survey had 37 closed-ended questions in total, which included six single-choice, four multiple choice, seven items on a 5-point Likert scale, and three items on a 5-point matrix rating scale questions (ranging from `strongly disagree' to `strongly agree'). To ensure the quality of the answers, all survey questions were not required fields (see §<ref>). The survey was structured into five blocks of questions. In the following, we detail the design of the surveys and outline the participant's progress through each block of questions.

(1) Introduction and consent page.  The survey began with an introduction, followed by sections detailing its purpose and procedure. The inclusion criteria included a reminder advising participants unaware of personas not to complete the online survey. The survey also collected personal information and provided assurances regarding data confidentiality and contact information should participants have any questions. We also informed participants that the study adheres to the low-risk ethical guidelines and requested their consent to use their data. Participants were also informed that they could withdraw from the study if they felt uncomfortable.

(2) Demographics. This segment solicited demographic details from participants, encompassing aspects like their job roles, years of professional experience, and the nature of their organizations. Demographic questions were included to help us identify respondents' information and understand the attitudes of different types of participants towards personas <cit.>.

(3) General questions about personas. In this survey section, we asked participants general questions about the feedback of using personas in software projects. For example, these questions included assessment factors such as costs, time, and value.

(4) Personas usage and creation-related questions. In this section, we explored participants' usage of personas in various domains, including business, government and customer projects, and virtual reality projects. We also inquired about the methods used to collect and analyze data for persona creation. We also asked participants how personas are used in different types of companies.

(5) Human aspects related questions. In the final section, we asked participants questions to collect information about three main types of human aspects: individual-related, technical-related, and team-related. We followed the design proposed by <cit.> to create questions about these human aspects. Our objective was to explore the value of using personas for capturing human aspects in software requirements.

Survey Respondents' Demographics.

§.§ Data Analysis of the Survey and Interviews

To analyze the interview data, we used the iFLYTEK professional automated transcription service to transcribe the interview recordings into transcripts <cit.>. We also translated the Chinese transcript into English, jointly completed by the first author and two external researcher assistants. To evaluate the accuracy of the data, the first author and two co-authors performed an initial accuracy check on the auto-transcriptions. They were proficient in both English and Chinese. This quality check aimed to rectify errors emerging from the automated transcription and organize the structure of the transcriptions. Then, the first author and two authors reviewed the transcripts and conducted a thematic coding analysis on the entire dataset using NVivo <cit.>. During the thematic coding process, we screened out sentences that were not related to our study. We used the card-sorting approach to analyze and categorize the interview. Specifically, the first author, two co-authors, and two external researcher assistants read and coded the interview data into cards. To ensure no repeat card themes, the authors merged the cards with the same words, themes, or meanings. The other authors then discussed and reviewed the final card themes. In this discussion, we evaluated the themes, reduced some potential misinterpretations of the participants' answers, and reviewed the card sort output. After reviewing the cards through discussions, we reached the final four main card themes, including 23 card sub-themes based on three research questions and participants' demographics.

To analyze the online survey data, we first combined the results of the Chinese and English questionnaires. We had initial 323 responses. We excluded any incomplete, unfamiliar with personas, and nearly identical responses. After this filtering step, we had a total of 203 responses. We categorized the survey results based on demographic information, such as participants' roles, years of experience, company size, and types of companies. We then imported the survey data into the RStudio and analyzed the survey data based on the statistical description <cit.>. The online survey questions were based on our research questions and interview findings.

§ RESULTS

In this section, we present the results of the data collection.  For ease of analysis and due to space limitations, we present the results and discussions from both our interviews and survey together.

§.§ Demographics of Participants

Interviews. We interviewed 26 practitioners with an average of eight years of industry experience. All interviewees had at least three years of work experience in various industries. All interviewees worked in different types of IT companies: 14 in large corporations, six in SMEs, and six in startups. One interviewee (P3) was the CEO of an IT company. Five interviewees were located in the United States (P1, P4, P19-21), 15 in China (P2, P3, P5-P14, P17, P18, P25, P26) and five in Australia ( P15, P16, P22-24). Table <ref> summarizes the backgrounds of the interviewees.

Survey. Our online survey received responses from 323 respondents. Out of these, 75 did not complete the survey, leading to their exclusion. We further filtered out 64 responses from participants who did not align with our job criteria, notably those who lacked a background and were also not working in IT/software fields. This resulted in a final count of 203 valid responses for our analysis.

Figure <ref> (a) plots the respondents' experience, with a secondary level breakdown based on their role. Most respondents had 1-4 years of experience (48%), followed by 5-9 years of experience (24%), more than ten years (13%), and less than one year (13%) in the industry. Figure <ref> (b) shows the current roles of respondents. Among the respondents, a large number were software developers (50%), followed by UI/UX designers and IT project managers (16% each), user researchers (11%), and business analysts (6%).
We note that while respondents could identify with multiple roles, they were only able to use their primary role in our survey. Figure <ref> (c) represents the distribution of roles across varied IT company types. The breakdown was as follows: SMEs (50%), startups (26%), and large corporations (24%). In our attempt to achieve a globally representative perspective on personas, we sourced responses from a diverse set of geographical regions. We publicized our survey on social media platforms and received responses from three countries – the USA, Australia, and China. Overall, from our 203 respondents, we had 18 from the United States, 25 from Australia, and the remaining 160 from China.

§ DISCUSSION

In this section, we outline actionable insights from our findings on personas for practitioners and highlight avenues for future research.

Implications for Practitioners.

* Focused training on Personas. Our results highlight inconsistent use of personas across different job roles. Specifically, software developers tend to focus less on personas, while job roles more closely related to user needs tend to use personas more frequently.
[Takeaway] This disparity in persona usage emphasizes the need for improved education and training on the benefits of using personas and how to integrate them effectively into the software development lifecycle <cit.>.

* Engage Software Engineers in Persona Development. As suggested by P5 in their interview, encouraging software engineers to participate in RE-related discussions, including persona creation, can lead to a deeper understanding of user needs.[Takeaway] Regularly schedule collaborative sessions between software engineers/developers and the requirements analysts and product owners to discuss user needs and co-create personas.

* Understand the limitations. Our study highlights the potential limitations of using personas (discussed in Section <ref>). For example, some startup practitioners view personas as unnecessary due to lacking resources, data, or professional knowledge. Additionally, subjective personas without empirical data may negatively impact software development. [Takeaway] Before diving into persona creation, practitioners should understand its potential limitations, especially in resource-constrained environments, and ensure that they are backed by empirical data.

* Data-driven persona platforms may help. Several practitioners reported that their organizations successfully use third-party or internal data-driven persona platforms.
[Takeaway] Organizations should explore and consider investing in data-driven platforms to streamline and automate the persona creation process, to cater to diverse user requirements.

* Ensure accurate persona content coverage. Our study suggests that the content of personas should accurately reflect user needs and behaviors. This could include exploring how human factors and user requirements map onto personas and investigating effective methods for constructing and validating personas.
[Takeaway] Regularly validate and update personas. Consider workshops or feedback sessions to map human factors and user requirements onto personas effectively, to improve software products' quality and user experience.

Implications for researchers. Below, we present potential research avenues and recommendations derived from our findings.

* Usage of personas in resource-constrained development environments. Many participants noted that they do not implement personas due to resource shortages. The possible research directions are related to exploring how practitioners can create and use personas effectively despite limited resources. For instance, can RE researchers leverage natural language processing (NLP) solutions, such as large language models (GPT Model <cit.>)? Alternatively, what other lightweight options can practitioners use in lieu of personas in resource-constrained environments?

* Investigate the various impacts of data-driven personas in the industry. The open research questions related to data-driven platforms, based on our findings are: How effective are data-driven persona platforms in different contexts and for different software products? Investigate the impact of data-driven persona platforms on the quality and user experience of software products that use such platforms. In light of the privacy concerns raised by our participants, what are the ethical and privacy implications of using data-driven persona platforms?

* Consideration of human aspects in personas. As discussed earlier in the results of our study, many human aspects, e.g., special physical needs, were largely ignored in personas. Can we develop guidelines and best practices for building personas inclusive of the diverse user bases in different systems?

* Usage of personas in constantly involving application domains. Our study found that personas are `rarely' or `never' used in VR and gaming software projects, as these fields are constantly evolving. One possible reason could be that the user experience and interaction in VR and gaming environments are perceived as different from those in traditional software applications. If this is the case, then a possible research direction is to study these perceptions of user experience and investigate the user-centered RE methods for VR and gaming projects.

* Usage of personas in varying types of software projects and IT companies. Our study found that personas are `rarely' or `never' used in startups, and government software projects. Our study reveals the frequency of persona usage across different types of projects and IT companies. In the future, we should focus on employing personas to enhance practices in various types of software projects, such as government-based websites, applications, extended reality (XR), data visualization, culture exhibition projects and so on. We also should focus on how personas can effectively help in identifying and analyzing user needs and requirements for startups, or small/medium sized IT companies, evening focusing the differences across different countries and regions.

§ THREATS TO VALIDITY AND LIMITATIONS

Various factors were potential candidates as threats to the validity of our qualitative study, e.g., research bias, which involves selectively recording information and confirming personal biases, as well as inaccurate responses <cit.>. In the following, we outline our strategies for mitigating potential threats to the validity.

During the interview, there was a possibility that we may have inadvertently influenced participants to provide researchers with desirable answers. To mitigate researcher bias, we employed several strategies. Firstly, we recruited participants from various fields and had many interviewees. Secondly, we arranged for multiple researchers to participate in the interviews and collect and analyze the data. Thirdly, the researchers avoided in-depth discussions on socially acceptable answers while providing important information about the study's purpose and topic. Another potential threat is participant bias, where some participants may not provide accurate answers due to their experience or biases. To avoid this, we ensured participants and their company names remain anonymous <cit.>.

To mitigate respondents' bias during the survey, we employed several strategies. Firstly, we asked interviewees, their personal industrial networks, and the professional research team's social media platform to distribute our online survey. Secondly, we invited three experts from the fields of requirements engineering and user-centered design in the survey design process, and two industry professionals (more than five years of experiences in software requirements) to evaluate our research questions with us to ensure that respondents could easily understand the questions' meaning. Thirdly, we conducted an initial survey to assess the quality of respondents' answers before the final evaluation, which was not included in this study. Fourthly, the survey went through four rounds of evaluation and modification before its final version. In addition, we added an introduction on the initial page to provide information about our study.

To ensure data quality, we sourced practitioners from diverse sources: job roles, software projects and IT companies. We excluded data that was ambiguous, incomplete, or where respondents were unfamiliar with personas, or repeatedly selected the same answers. Finally, to ensure the validity of our findings, we employed triangulation methods, enhancing result accuracy and reliability. Upon analyzing the interviews, we noted that the majority of our survey findings aligned with the interview outcomes.

While our study offers valuable insights and substantial contributions to the understanding of persona usage in SE, it is not without its limitations. Our participant pool predominantly comprises practitioners from Australia, China, and the United States, potentially not capturing a full global perspective. While the insights gleaned are valuable, we recognize the need for a broader global perspective and thus intend to expand our research scope to capture the viewpoints of practitioners from other underrepresented areas. Furthermore, some interviewees and respondents have never used personas represents a potential threat. To mitigate this threat, we required all interviewees to understand the concept of personas, which may provide valuable insights on why personas are not used in different types of IT company. We also added a reminder at the beginning of the survey to prevent respondents who are unfamiliar with personas from answering the questions. We removed all responses that were similar answers, and set up automatic function on the online platform to identify invalid responses. Additionally, we removed job roles that are unrelated to software and user requirements.

§ CONCLUSION

This paper explores the use of personas across different industry sectors. Our study indicates that while SMEs and corporations frequently use personas, startups rarely do so. Our interviews revealed five prominent job roles that employ personas: UI/UX designers, IT project managers, software developers, business analysts, and user researchers. We also observed that persona usage varies considerably depending on the type of software project. Specifically, government-related projects utilize personas the least, whereas customer and business software projects often employ them. Moreover, we discerned that IT companies and specific job roles demonstrate diverse preferences, methodologies, and attitudes towards persona usage. Notably, IT firms face challenges when utilizing personas, such as limited professional expertise, resource constraints, and data privacy concerns. Intriguingly, our study pinpointed several crucial human aspects that are often overlooked in personas. From our insights, we offer recommendations for both practitioners and researchers. In the future, we aspire to delve deeper into the potential of data-driven platforms and cutting-edge technologies, like VR, to navigate these challenges and cover a wider participant pool.