Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow Boniface Bahati Tadjuidje
arXiv:2604.24478v1 [cs.HC] 27 Apr 2026
[email protected] Department of Computer and Software Engineering Polytechnique Montreal Montreal, Quebec, Canada
Jin L.C. Guo
[email protected] School of Computer Science McGill University Montreal, QC, Canada
Abstract Open-source software (OSS) developers often struggle to understand and respond to user context, while existing tools, such as issue trackers (for handling bugs, requests, and feedback), largely focus on technical discussion. Although personas could help, limited resources and UX expertise make them hard to scale. We present PersonaFlow, a tool that generates editable user personas from OSS repository artifacts and integrates them alongside issue reports. In a user study with 13 OSS developers, most reported shifts in how they understood users, and more than half modified their responses by adding empathetic language, tailoring explanations, or raising priority ratings. We found two pathways to this change: some connected emotionally to personas as people, while others used them pragmatically for triaging. Both appeared to lead to more user-centered behavior. We contribute design implications for persona-based tools relevant to OSS and other contexts where efficiency-driven systems or workflows obscure valuable human elements.
CCS Concepts • Human-centered computing → Empirical studies in collaborative and social computing; Open source software; • Software and its engineering → Open source model.
Keywords Persona, Automatically Generated Personas, Open Source Software, Empathy, User-Centered Design, Human-AI Collaboration, LLM ACM Reference Format: Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng. 2026. Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow. In Designing Interactive Systems Conference (DIS ’26), June 13–17, 2026, Singapore, Singapore. ACM, New York, NY, USA, 25 pages. https://doi.org/10.1145/3800645.3813031
1
Introduction
Open-source software (OSS) development relies on social coding platforms to build and sustain its communities. Tools and platforms
This work is licensed under a Creative Commons Attribution 4.0 International License. DIS ’26, Singapore, Singapore © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2563-0/2026/06 https://doi.org/10.1145/3800645.3813031
Jinghui Cheng
[email protected] Department of Computer and Software Engineering Polytechnique Montreal Montreal, QC, Canada
like issue trackers [2] and discussion forums [16] offer the promise to allow developers and users to have direct communication to address user needs. However, in reality, these channels capture only a self-selecting subset of users (typically those with enough technical vocabulary to articulate problems) and rarely reveal underlying goals, frustrations, or the human context behind requests [42]. To aggravate this problem, OSS communities often lack the necessary resources and expertise to conduct user research or follow typical UX practices [43]. As a result, OSS developers and maintainers often struggle to understand their diverse user base, defaulting to technical-first prioritization that treats issues (bug reports, feature requests, and other project-related discussions) as puzzles to solve rather than people to help [12, 43]. This resource gap creates a persistent empathy challenge in OSS communities. Research has documented widespread patterns of dismissive responses in communication channels, unwelcoming behavior toward newcomers [39], and communication failures that escalate into toxic and uncivil exchanges [14, 26]. These are not isolated incidents but symptoms of a deeper problem: the information environment of OSS development provides rich technical data (labels, milestones, code references) but almost no user context (who is affected, how severely, what their goals are). This is not a matter of individual disposition but of information design. Developers simply lack the awareness triggers needed to empathize with users they never meet [15]. Personas—fictional representations of a product’s target user types—have long been recognized as effective tools for building empathy and grounding design decisions in user needs [7, 30]. However, traditional persona creation requires specialized UX expertise and extensive work that most OSS projects simply cannot afford. To explore how AI-generated personas could support OSS developers in understanding their users, we designed PersonaFlow, a tool that addresses this gap by supporting the generation of user personas from repository artifacts and integrating them directly into the issue management workflow. From a repository URL, PersonaFlow can generate diverse personas grounded in the actual project context through analysis of README files, documentation, and issue reports. Users can also provide any additional documents or resources to complement the project repository. Moreover, PersonaFlow maps these personas to individual issues in the issue tracker with confidence scores and explanations, showing developers not just what is broken about the software but who is affected by this issue and how. Developers can review, edit, merge, or regenerate personas at any point in the workflow, maintaining necessary
DIS ’26, June 13–17, 2026, Singapore, Singapore
oversight. Finally, an analytics dashboard is provided to help teams identify when certain user types face disproportionate issues. By embedding personas alongside the issue tracker that developers regularly use to manage and prioritize their work, PersonaFlow provides the context needed to prompt OSS developers to reflect on the impact on users. In a user study with 13 OSS developers, participants used PersonaFlow on repositories they are familiar with to explore AI-generated personas, respond to issues before and after persona exposure, and provide feedback on the tool’s features. Rather than testing specific hypotheses, our goal is to explore how developers engage with AI-generated personas in the context of issue handling and identify design considerations in this space. Our findings revealed that most of the participants reported shifts in how they understood users, and more than half modified their issue responses after persona exposure—they added empathetic language or tailored explanations in their replies and raised priority ratings based on user impact. We identified two distinct pathways through which personas nudged our participants to react to user needs. Some developers connected emotionally to personas as real people (empathy-driven), while others used them pragmatically for efficient issue resolution (utility-driven). These findings suggest that persona tools can benefit diverse developer orientations. Based on these findings, we contribute design implications for AI-assisted persona tools that can help OSS developers better understand and support their users. These findings can also extend to other work contexts where efficiency-oriented systems or workflows abstract away the human elements important for perspective shifting. Researcher Positionality. Our understanding of the OSS development workflow, as well as our approach in this study, is informed by our prior experience researching related topics in the context of HCI and software engineering, as well as by our direct participation in OSS projects. In particular, the first author is an active OSS contributor, currently maintaining multiple repositories. This provides the research team firsthand experience with issue handling and user interactions, and how this experience interplays with developers’ mindsets. The remaining authors had extensive prior research experience studying the aspects of usability, design, inclusiveness, and sustainability in OSS and collaborative work. All authors have had prior training and varied experience in interaction design and UX research. Overall, this positionality shaped how we approached the system design and how we collected, analyzed, and interpreted the user study data.
2
development is a prominent example of distributed software work, yet it presents unique challenges in managing contributions across diverse contexts. Through a series of studies, Steinmacher et al. [39] identified 57 distinct barriers that newcomers face in OSS, with communication issues, including impolite responses and unwelcoming behavior, representing a significant category. While this communication breakdown happened between developers, it reflects deeper challenges in understanding and responding to others’ needs in remote and distributed development environments. Building on this, Gunatilake et al. [15] found that while developers require specific “awareness triggers” to activate empathy toward users, OSS environments systematically lack these triggers due to limited direct user contact and asynchronous communication patterns, creating impediments to empathy building. Recent work has shed more light on the barriers between developers and users and their consequences [17]. Developers and users often speak different “languages” even when discussing the same issues [16], compounding the empathy challenge. Such communication failures can escalate into confrontational conflicts, as revealed by widespread and nuanced incivility and toxicity across OSS platforms. For example, research has detailed patterns of incivility, such as frustration and name-calling, within Linux Kernel code review discussions [14], while analysis of toxic discussions on GitHub reveals them to be empathy breakdowns at scale [26]. However, understanding and managing these interactions is complex; a study of GitHub’s “locked issues” feature found that many discussions labeled as “too heated” by maintainers did not actually contain uncivil content, pointing to inconsistencies in how communities identify and handle conflict [13]. More critically, Sin et al. [38] introduced the concept of “Digital Design Marginalization”, demonstrating how non-inclusive designs push certain users away from digital services with lasting social consequences. This marginalization is particularly evident in OSS: Balali et al. [3] showed how project structures encode systematic biases against women, while Wang et al. [43] found that OSS contributors struggle with usability concerns due to a predominance of technical thinking that overshadows user perspectives. These findings show that the empathy gap in distributed software development is not an isolated issue, but a systemic problem rooted in its information environment and priorities manifested in existing tools. Our work addresses this challenge by proposing a tool-based intervention that surfaces user context at the point of developerissue interaction, making it easier for developers to consider who is affected by the issues they handle.
Related Work
Our work builds upon prior research on the empathy challenges during software development, the use of personas as an empathybuilding mechanism, and the recent emergence of generative AI for persona creation.
2.1
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
The Empathy Gap in Distributed Software Development
The rise of distributed software development, accelerated by globalization and remote work technologies, has fundamentally transformed how software teams collaborate across geographical, temporal, and cultural boundaries [6]. Open-source software (OSS)
2.2
Personas as Empathy-Building Tools
Personas, a user-centric design tool popularized by Alan Cooper [7], are often used to bridge different communities of practice, such as developers, designers, and project managers [23]. Aiming to cultivate empathy and engagement with users, personas can be created by designers through user research or co-created with users [27]. From their experience at Microsoft, Pruitt and Grudin [30] observed that personas helped teams create “a strong focus on users” and provided a “shared basis for communication.” Similarly, Matthews
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
et al. [24] found that practitioners value personas primarily as practical tools for communication and decision-making, which makes abstract users concrete and discussable. Despite their effectiveness, the adoption of personas is often hindered by practical constraints. Pruitt and Grudin [30] noted that traditional persona creation, which relies on deep user research, can require months of intensive data collection and analysis, making it prohibitively expensive for many organizations. This challenge is especially acute in resource-constrained OSS projects. These resource limitations can force trade-offs that lead to personas becoming outdated or unused, a phenomenon known as the “file drawer effect” [32]. A recent survey of 203 practitioners by Wang et al. [44] revealed that while developers recognized the value of personas, practical barriers, including time, cost, and lack of expertise, prevented their regular use in software projects. Personas also carry risks when poorly implemented. Marsden and Haag [23] warned that personas can reinforce stereotypes and biases if not grounded in authentic user data, potentially causing more harm to users than good. Bennett and Rosner [5] later offered a deeper critique, cautioning that personas can inadvertently “sustain the very difference that it may seek to overcome” if they present users as fundamentally “other” rather than fostering genuine understanding. The high cost and potential pitfalls of traditional methods highlight the need for more accessible and reliable approaches that can scale to the needs of distributed software development.
2.3
Persona Creation with Data-Driven Automation
Recent advances in generative AI have opened new possibilities for creating personas at scale, potentially addressing the resource constraints that limit traditional approaches. The field has seen explosive growth, with recent HCI research demonstrating both the promise and challenges of this approach. Systems like PersonaCraft [20] have demonstrated that AI can generate credible and complete persona profiles from user data, achieving quality ratings comparable to traditionally-created personas. Zhang et al. [47] showed that AI-generated personas can effectively support design education, helping students develop user-centered thinking. The ability to assess the quality of AI-generated personas is a critical aspect of their development. Salminen et al. [33] investigated 450 LLM-generated personas and found that they are rated differently by subject matters and UX researchers. Salminen et al. [34] developed and validated the Persona Perception Scale, a framework for evaluating personas on dimensions of credibility, empathy, and likability. Recent research into human-AI collaboration has focused on how to create high-quality personas. Shin et al. [36] found that combining the strengths of both humans and AI produces personas that are more representative and empathy-evoking than those created by either humans or AI alone. In this collaborative model, the AI handles pattern recognition and synthesis across large datasets, while humans provide contextual understanding and quality control. While modern LLMs may address many technical shortcomings, a fundamental challenge remains: AI-generated personas, despite their increasing sophistication, still struggle to capture the authentic complexity of human users. When personas lack grounding in real
DIS ’26, June 13–17, 2026, Singapore, Singapore
user expressions and contexts, they feel hollow even when they meet technical quality measures [29]. Recent work on human-AI iteration also reveals a broader challenge on trust: Vereschak et al. [41] found that trust in AI systems is strongly influenced by human stakeholders rather than system features alone, while Ma et al. [22] demonstrated that humans struggle to appropriately calibrate their trust in AI during decision making. PersonaFlow builds upon this line of work by considering both challenges. It grounds persona generation in human-authored project artifacts, including documentations and issue discussions, to preserve user-targeted voices, while supporting control and trust calibration through confidence indicators, explicit explanations, and extensive editing capabilities. Moreover, with the recognition that automatically generated personas will always risk misrepresenting users, our work focuses on how persona-based tools can incorporate automation in a human-centric workflow for scale, while providing OSS developers the much-needed “awareness triggers” [15] for kick-starting their user-centric behavior.
3
PersonaFlow’s Design and Implementation
The design and implementation of PersonaFlow followed an iterative, user-centered approach. In the following sections, we describe our design goals (DGs), the design and implementation process, the final user interaction design of PersonaFlow, as well as its implementation details.
3.1
Design Goals and Considerations
To ensure that our tool effectively addresses the needs of OSS developers, we identified the following four key goals and considerations, informed by the literature and our own experience working on OSS projects and tools, to guide our design process. DG1: Providing Insights into User Impact. Effective decisionmaking requires situation awareness [10]. Research shows that during their regular workflow, OSS developers systematically lack the “awareness triggers” needed to activate empathy [15], often defaulting to technical-first prioritization without being conscious of user context. Personas can address this gap by making user impact visible and actionable [30]. We thus aim to incorporate personas in the OSS tool space to promptly provide insights into user impact to support OSS developers. DG2: Low-Barrier Automated Persona Generation. Traditional persona creation requires considerable effort, specialized expertise, and substantial budgets [30]. Practical barriers, such as time, cost, and expertise, may prevent regular persona use and related practices [44]. OSS communities especially lack these resources [43]. Recent work shows AI can generate useful personas from existing data [33]. We thus explore how automated techniques can be leveraged to lower these barriers. DG3: Workflow Integration and Flexibility. Prior research highlighted key factors impacting adoption, especially on how compatible the intervention is with existing values, experiences, and practices of practitioners [28, 37]. In software development specifically, automated tools that disrupt established workflows face resistance despite their intended benefits [45], while tools wellintegrated into the existing work see higher adoption [31]. In our tool design, we emphasize its integration into the existing social
DIS ’26, June 13–17, 2026, Singapore, Singapore
computing landscape for OSS communities, including both development tools (e.g., GitHub) and processes (e.g., issue triaging and responding). DG4: Transparency and User Control. Research on human-AI collaboration reveals that users often struggle to calibrate trust with AI appropriately, leading to over-reliance or under-reliance [9, 48]. Transparency and explanations that reveal AI limitations and uncertainty, rather than those designed to persuade acceptance, can foster appropriate trust [25]. At the same time, AI-generated personas risk reinforcing stereotypes through biased representations of demographic groups [33]. These findings suggest AI persona tools must provide uncertainty indicators (e.g., confidence scores that signal when AI is less certain), expose AI reasoning for critical evaluation rather than blind acceptance, and afford human control to validate and override AI outputs.
3.2
Design and Implementation Process
Guided by these design goals, we followed an iterative process to design and implement PersonaFlow. The design process involved multiple stages of ideation, prototyping, feedback collection, and refinement, ultimately resulting in a comprehensive web-based tool for persona-driven OSS development. Initial Ideation. Our initial ideation centered on a key insight from DG3: personas alone, however well-crafted, provide limited value if they sit outside of OSS developers’ actual work. Prior research shows that personas can remain unused when they exist as static artifacts separate from daily workflows [32], but their value shines when integrated as communication tools for decisionmaking [24]. In OSS contexts, issue handling represents the central activity for decision making and the primary interface between developers and users—issues are where user problems surface, prioritization decisions are made, and the consequences of those decisions become visible [39]. We thus decided to design PersonaFlow around this workflow, making personas actionable by connecting them directly to the issues where developers already engage with user needs. When initially ideating PersonaFlow, we explored two options for its overall architecture, also considering DG3’s emphasis on workflow integration: (1) a browser extension that would overlay persona information directly onto the GitHub web interface, versus (2) a standalone tool that integrates with GitHub through its API. During our examination of those two options, we realized a tension in our tool design: persona-driven development involves both reactive work (e.g., triaging issues, quick prioritization) that can benefit from lightweight tool augmentation, and reflective work (e.g., analyzing user segments, recognizing cross-issue patterns, refining personas) that can benefit from a dedicated environment. Browser extensions excel at reactive augmentation but risk fragmenting reflective tasks across constrained sidebars and overlays. As a novel tool idea, we saw PersonaFlow’s core value in supporting the reflective work. We thus prioritized designing this tool as a coherent, standalone environment, while acknowledging that a browser extension would offer superior workflow integration. Future iterations could explore hybrid architectures combining both approaches.
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
Prototyping and Design Iteration. Following the architectural pivot, we developed initial design sketches and mockups for the web-based interface, focusing on three key workflows: (1) repository analysis and persona generation, (2) persona management, and (3) issue management with persona associations. Different versions of the sketches and mockups were reviewed iteratively by team members. After several design iterations, we implemented a working version with the core functionalities of the tool. This process revealed several tensions among our design goals that require careful navigation. The most significant was automation versus human control, stemming from the conflict between DG2 (lowering barriers through automation) and DG4 (maintaining user agency). Fully automated persona generation would minimize effort but risk generating invalid or irrelevant content; manual creation would ensure relevance but recreate traditional barriers (e.g., demand on resources and expertise). We resolved this by emphasizing a “generate-then-refine” approach where AI produces initial personas that developers can edit, merge, or delete. Similarly, information richness versus cognitive load arose from pursuing DG1 (providing rich user insights) while maintaining usability to developers who may not be familiar with the concept of persona. We addressed this through progressive disclosure, showing summary cards with expandable details. Finally, confidence shortcut versus explanation directly emerged from DG4’s trust calibration concerns when we design features to map personas with issues. Specifically, quantitative confidence metrics offer efficient shortcuts but risk misinterpretation, while explanations of the linkage between issues and personas promote calibrated understanding at the expense of additional cognitive effort. We settled on providing both visual confidence indicators and short explanatory reasoning to navigate this tradeoff. Preliminary User Study and Further Improvements. To further iterate the design, we conducted a preliminary user study with two OSS developers (not included in the final study), each lasting approximately one hour. Participants used the tool with their own repositories and provided feedback on workflows, interface clarity, and persona usefulness. These studies surfaced several issues that we addressed accordingly. For example, persona generation was originally handled asynchronously—users will be notified after the generation process is finished. Participants found this process opaque, uncertain whether the system was progressing or stalled. We thus added clearer indicators with stage-by-stage feedback for the generation progress. Both participants also wanted to refine personas right after generation, instead of going into a separate screen to inspect and edit them. So, we improved editing capabilities to better support the “generate-then-refine” workflow. Further, participants wanted to have immediate and interpretable information about how certain the AI was about any association between issues and personas it predicts, leading us to add visual confidence indicators that expose uncertainty. Moreover, participants found common tasks like associating additional personas with issues required too many steps, so we streamlined these workflows to reduce friction. One feature we removed was automatic persona suggestions during issue creation, which participants found interruptive rather than helpful. This reinforced our assumption that workflow integration requires careful timing, not just proximity. Finally, participants noted that
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
some initially generated personas felt generic. We refined the AI prompts by requiring persona goals and pain points to reference specific product features, and by instructing the model to focus on behaviors in the personas rather than demographic assumptions. The preliminary user study also confirmed that our core design tensions were genuine: participants valued automation but immediately sought editing control, appreciated confidence scores but needed explanatory reasoning to act on them, and wanted rich persona profiles but engaged primarily with summary views. These observations validated our resolution strategies while revealing that DG4 (transparency and user control) required more interface prominence than initially planned. The final version of PersonaFlow reflects these insights, prioritizing visible confidence indicators and low-effort editing over an automated but opaque experience.
3.3
User Interaction Design
The final interface of PersonaFlow is organized around three workflows associated with how personas can be created, integrated, and used. Each workflow embodies our design goals while navigating the tensions and resolutions discussed above. 3.3.1 Workflow 1: Repository Analysis and Persona Generation. This workflow (Figure 1) transforms a GitHub repository into datadriven personas with minimal setup (DG2). The central design challenge is the automation-control tension: generation must be effortless enough to lower adoption barriers (DG2) while giving developers meaningful agency over the output (DG4). The process begins when users provide their GitHub repository URL (A on Figure 1). Before generation, a configuration panel (B on Figure 1) allows users to specify the number of personas (1–10), provide external documentation URLs for additional context, and add custom descriptions of their user base. These options support flexibility (DG3), allowing different projects to satisfy their unique needs. Clicking Start Persona Analysis initiates asynchronous processing, with a progress view (C on Figure 1) displaying stage-by-stage updates: fetching repository data, crawling external sources, analyzing domain, and generating personas. This transparency (DG4) directly addresses the preliminary user feedback about uncertainty during long-running operations. Upon completion, a preview page (D on Figure 1) presents all generated personas for user inspection. This is where the “generatethen-refine” resolution (DG4) becomes concrete: users can edit any 1 on persona’s details, delete personas that they feel irrelevant (○ 2 on Figure 1), and Figure 1), merge multiple personas together (○ manually add complementary personas or regenerate all personas 3 on Figure 1). After this review, users can click Save altogether (○ 4 on Figure 1), at which point the system stores the Personas (○ personas and automatically begins mapping repository issues in the background (DG2). 3.3.2 Workflow 2: Persona Management and Analytics. This workflow (Figure 2) enables the developers to inspect the personas, modify them, and recognize patterns related to user impact (DG1). The repository dashboard (A on Figure 2) serves as the central hub after persona generation completes. There, users are provided with quick access to three functions: (1) View Personas, (2) Browse Issues, and
DIS ’26, June 13–17, 2026, Singapore, Singapore
(3) Analytics, while summary statistics display persona and issue counts alongside processing status (DG1). The “Browse Issues” function contributes to the Issue Browsing and Management workflow (Workflow 3) and will be explained in Section 3.3.3. The “View Personas” function (B on Figure 2) presents all personas 1 on Figure 2) in a searchable grid with a management toolbar (○ offering three actions: (1) creating custom personas manually, (2) generating additional AI personas to fill potential coverage gaps, and (3) merging two or more personas (DG3, DG4). An issue map2 on Figure 2) also shows total, unmapped, and ping status panel (○ mapped issue counts, helping teams identify coverage gaps. 3 on Figure 2) displays its complete profile: Each persona card (○ avatar, demographics, representative quote, background narrative, goals and motivations, and pain points and frustrations. A tag is presented at the top-right corner of each persona card to indicate whether it is generated by AI or created manually by a user (DG4). 4 on Figure 2) also provides Edit and Delete The card footer (○ actions for ongoing refinement (DG4). The edit dialog (C on Figure 2) uses a tabbed interface to organize persona attributes. The 5 on Figure 2) allows modification of demographics, Basic Info tab (○ quote, tagline, and background narrative, with options to choose between AI-generated headshots or stylized avatars. The Goals & 6 on Figure 2) presents editable lists where users Pain Points tab (○ can add, modify, or remove individual goals and pain points. The “Analytics” function (D on Figure 2) provides aggregate in7 on Figure 2, including total sights through summary metrics (○ issues, active personas, coverage rate, and repository statistics) 8 on Figure 2). The label distribualongside two visualizations (○ tion chart reveals issue categorization patterns. The persona coverage chart shows how issues are distributed across personas (DG1). These analytics aim to help teams identify blind spots and inform prioritization decisions. 3.3.3 Workflow 3: Issue Browsing and Management. After personas are saved, the system maps repository issues to relevant personas. This workflow (Figure 3) is where persona insights become actionable, for developers to understand the impact of each issue on their potential users (DG1, DG3). After clicking on “Browse Issues” on the repository dashboard (A on Figure 2), users will be led to the Issues interface in which the original issue discussions on GitHub are imported. The interface offers two complementary views via a toggle. The GitHub View (A on Figure 3) preserves a familiar issue layout for developers (DG3)—issues appear chronologically, but now with persona badges indicating affected users on individual issues. Filter and sorting 1 on Figure 3) allow developers narrow results by issue controls (○ state (open or closed), recency, or persona mapping confidence level. 2 On issue cards, each persona badge includes a “why?” button (○ on Figure 3) that reveals a popover with the AI’s mapping rationale, allowing a quick glance without leaving the list view of issues (DG4). In comparison, the Persona View (B on Figure 3) organizes the issues by the personas that they affect. Persona filter chips at the 3 on Figure 3) allow viewing specific personas, with issues top (○ 4 on Figure 3) to reveal clustered beneath each affected persona (○ which users face the most friction by what issues (DG1). We retained both views because participants in the preliminary user study had
DIS ’26, June 13–17, 2026, Singapore, Singapore
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
D 2
A
B 1
3
4
C
Figure 1: Repository analysis and persona generation workflow. Users input the repository URL (A), configure generation parameters (B), track real-time generation progress (C), and preview, edit, and approve the generated personas (D). different preferences; some wanted personas layered onto existing mental models, while others valued the perspective shift of personafirst organization. By clicking on an issue card on either view, the user will be led to the issue detail page (C on Figure 3). This page displays full persona cards on the side of the issue discussion details (DG3). The 5 on Figure 3) shows its role default view of each persona card (○ and basic demographic information, together with a confidence score (0–100%) of mapping this persona to the issue, AI generated reasoning for why this persona would care about the issue (DG4), and representative quotes from persona profiles. Users can expand 6 on Figure 3) to view its details, such as goals each persona card (○ and pain points. When associations feel incorrect, users can click the “Map” button (D on Figure 3) to open the persona associations dialog, where they can manually add or remove personas to be associated with the issue; AI-suggested associations are clearly labeled on this dialog to provide transparency (DG4). Finally, on both views, users can re-sync issues with GitHub 7 on Figure 3) as repositories evolve, with options to fetch all (○
new issues or issues with specific IDs, labels, or date ranges (DG3). Newly imported or updated issues are automatically mapped to existing personas, keeping the persona association current without manual effort (DG2).
3.4
Implementation
3.4.1 System Architecture. PersonaFlow is implemented as a web application with a React frontend and a Django backend, using PostgreSQL for data persistence. Figure 4 illustrates the system architecture showing how the three user workflows connect to backend processing components. The system connects with several external services: the GitHub REST API for repository metadata and issue data, the OpenAI API for AI-powered persona generation and issue mapping, and the Google Gemini API for avatar image generation. Once users initiate persona generation, the backend fetches repository data from GitHub and constructs appropriate prompts to be sent to the LLM APIs. The LLM outputs are parsed, validated, and stored in the database. After users inspect and save
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
A
DIS ’26, June 13–17, 2026, Singapore, Singapore
B 1
C 5
2
3
D 7
4
6
8
Figure 2: Persona management and analytics workflow. The repository dashboard (A) shows three main functions: View Personas, Browse Issues, and Analytics. The View Personas function (B) allows users to inspect current personas, manually create or generate new personas, merge personas, edit personas (C) and inspect issue-persona mapping status. The Analytics dashboard (D) shows summary metrics and visualizations of persona coverage and label distribution. personas, the backend automatically initiates issue synchronization and mapping. Because persona generation involves multiple time-consuming steps (content fetching, AI analysis, avatar generation) that can take several minutes to complete, we used an asynchronous task processing mechanism with Celery and Redis as the message broker. When users initiate long-running operations, the backend immediately returns a task identifier while processing continues. The frontend polls a dedicated status endpoint to retrieve real-time progress updates and displays stage-by-stage feedback to users. This approach ensures a responsive experience despite computationally expensive AI operations. 3.4.2 LLM Prompt Design. As shown in Figure 4, we included three main prompting pipelines in PersonaFlow. Persona Generation Pipeline. We use a multi-stage approach in generating the personas. First, we used a Link Discovery Prompt (see Appendix A.1) to find links in the project README file that could help understand the end users. The content fetched from those links, together with other user-provided resources, is used to build a resource corpus. Then, the User Insights Summarize Prompt (see Appendix A.2) and the Domain Analysis Prompt (see Appendix A.3) are used to extract structured user-related and domain-related context from this resource corpus. Finally, the Personas Generation Prompt (see Appendix A.4) creates personas based on information extracted from the prior steps; this prompt emphasizes diversity across user characteristics and usage contexts, as well as adherence to the user
and domain insights. Overall, this chained, multi-stage approach aims to ensure that personas are grounded in actual repository data rather than generic assumptions about software users. Persona Merging Pipeline. In both Workflow 1 and Workflow 2, users can merge two or more personas when they identify overlaps. This is achieved through the Persona Merge Prompt (see Appendix A.6). This prompt combines input personas, while aiming to preserve a coherent narrative while representing the common characteristics of the original personas. Issue Mapping Pipeline. The Issue-Persona Mapping Prompt (see Appendix A.7) connects GitHub issues to relevant personas. Rather than keyword matching, it asks whether a persona would plausibly write or care about each issue given their goals and workflows. Anti-pattern checks are included to reject superficial matches (e.g., generic reasons that resolving issues can benefit “all users”). To support developers in verifying and overriding suggestions, the prompt also outputs confidence scores with reasoning. API Cost Estimation. Generating personas from a repository requires four text-based LLM calls (i.e., link discovery, user insights summarization, domain analysis, and persona generation, using GPT-4o) plus one image generation call per persona for avatar creation (using Gemini 1.5-Flash). Each issue mapping requires one LLM call. In our user study, the total cost per repository (each with four generated personas mapped with 20 issues, see Section 4.2) ranged from $0.50 CAD to $1.00 CAD, with issue mapping accounting for the majority of the cost ($0.40 CAD to $0.70 CAD).
DIS ’26, June 13–17, 2026, Singapore, Singapore
A
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
B
7
1
7 3
4 2
C
D 5
6
Figure 3: Issue browsing and management workflow. A toggle switches between GitHub-style list view (A) and persona-grouped view (B); each provides filtering options. Issue detail page (C) shows full persona cards with confidence scores, mapping reasoning, and expandable details. An associations dialog (D) is provided for manual addition or removal of persona mappings. 3.4.3 Assessing Persona Generation and Issue Mapping Quality. While it is challenging to systematically and quantitatively evaluate the quality of the generated personas and the accuracy of issue-persona mappings, we performed frequent manual inspections during our prompting and tool development processes. Here, we present example personas generated by PersonaFlow across a diverse set of OSS projects—from creative tools to developer infrastructure—showing how the system adapts to different product domains (see Table 1). Each persona was automatically created from a single input of the repository URL, without other manual input, representing a baseline for users of PersonaFlow to work on. The examples illustrate how goals and pain points reference specific product features rather than generic professional aspirations or user tendencies. The issue mapping example of each persona was randomly selected from the ten most recent issues mapped to the persona. The issue mapping is further explained by how the issue affects the persona’s goals and pain points, which is indicated in the AI’s reasoning text (see the Issue Mapping parts on Table 1).
4
User Study Methods
We conducted a user study using PersonaFlow as a probe to understand how OSS developers may engage with tools that embed AI-generated personas in the context of issue handling. Specifically, we explored (1) developers’ pre-existing empathic practices when responding to issue reports, (2) how persona exposure influences their mental models and communication with users, and (3) their perceptions of the various features of PersonaFlow for user-centered development. The study is approved by the ethics review board of the involved institutions.
4.1
Participants
Thirteen software developers who actively contribute to OSS projects were recruited through purposive sampling via developer communities, OSS mailing lists, LinkedIn, and Upwork. Participants represented diverse backgrounds in terms of the primary programming languages they use, OSS experience, age ranges, and geographic
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
DIS ’26, June 13–17, 2026, Singapore, Singapore
User Interface
Workflow 3: Issue Browsing and Management
User Input: -
Repo URL Additional docs and resources # of personas
Fetch Content From User Provided Docs
User Review, Revise, and Approve Generated Personas
Fetch README From Repo URL
User Inspect, Edit, Delete, Merge, Add, and Regenerate Personas
-
Inspect summary metrics and persona coverage
Generated Personas
Link Discovery
Generate Personas
-
Browse list with persona mapping Review issues with persona info Edit issue-persona mapping
Issues Mapped with Personas
LLM
Merge Personas
(Appendix A.4)
Generate Headshots
(Appendix A.1)
-
User Review Analytics:
LLM
LLM
User Browse Issues:
Workflow 2: Persona Management and Analytics
Workflow 1: Repository Analysis and Persona Generation
(Appendix A.6)
(Appendix A.5)
Map Issues with Personas
LLM
(Appendix A.7)
LLM
Fetch Content From Links
Analyze Domain
Resource Corpus Processing and Prompting
Fetch Issues From Repo URL
(Appendix A.3)
Summarize User Insights
LLM
(Appendix A.2)
Figure 4: System architecture of PersonaFlow, illustrating how the three user workflows connect to backend processing components. Shaded boxes with “LLM” labels are components that used an LLM (GPT-4o and Gemini 1.5-Flash in our case); the specific prompts are provided in the appendix sections indicated in the boxes. Black boxes with a data logo are storage components in the database. regions (spanning North America, Central America, Europe, the Middle East, and Asia). The sample was predominantly male (12 male, 1 female); while this is unfortunately imbalanced, it represents the general gender distribution among OSS contributors [49]. Participants’ experiences of OSS contribution ranged from beginners who just started to get involved in OSS projects to veterans who contributed to OSS for more than 20 years. The participants’ characteristics are detailed in Table 2.
4.2
Data Preparation
Since PersonaFlow requires processing time (typically five minutes) to generate personas and classify issues, we asked participants during recruitment to provide two GitHub repositories they actively contribute to or are familiar with so that we can prepare the data ahead of the study sessions. Prior to the study, we ran PersonaFlow on each participant’s selected repository to generate four personas for each repository. Additionally, we used the tool to retrieve and map the 20 most recent open issues to the generated personas. No editing to the personas or the issue mapping was performed to ensure that the participants experience the original output of the tool during the study, including potential AI errors and discrepancies. Subsequently, we selected one issue per repository from the issues retrieved by the tool, to prepare for the user study tasks described in the next section. Because we want to understand how PersonaFlow can affect participants’ user-centeredness tendency,
we selected the issue iteratively with the following process: we first identified issues less than one year old in which the participant did not involve with, to ensure that they carry out a fresh engagement with the issues during our study; we then filtered out issues that were overly technical or purely code-oriented (e.g., bug reports posted by someone with strong technical background); from the remaining, we then selected an issue where user frustration or contextual ambiguity was the most evident.
4.3
User Study Process
All study sessions were conducted remotely via Zoom. With participants’ consent, sessions were video recorded with screen capture. Each session lasted approximately 90 minutes and contained the following parts. Background Interview. We began each session with background questions about their professional role, programming experience, and OSS contribution history. We then explored their existing empathic practices by asking how they typically handle issue reports and whether they had prior experience with personas. PersonaFlow’s Impact on Issue Response. Subsequently, each participant completed the following three tasks using one of the repositories they had identified during recruitment: First, participants reviewed the issue we selected from this repository using PersonaFlow’s interface with persona information hidden. Without any additional context about the user, they described
DIS ’26, June 13–17, 2026, Singapore, Singapore
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
Table 1: Examples of AI-generated personas from repositories. Each persona was automatically created from a single input of the repository ID, without other manual input. For each persona, one example issue mapped to the persona is provided, including the issue’s ID and title, our manual summary of the issue content, and the AI’s confidence score and reasoning. Repository: musescore/MuseScore (Open-source music notation software) Yuki Tanaka, 32, Tokyo, Japan — Freelance Composer and Arranger Quote “I need my scores to look professional, but I also need to create them quickly to meet tight deadlines.” Background Yuki has been composing music since her teenage years, inspired by both traditional and modern Japanese music. Her freelance work ranges from creating scores for indie films to arranging music for local orchestras. Her clients demand high-quality scores under tight deadlines. Goals • Complete initial score drafts in half the usual time using MuseScore’s easy note entry • Transform rough musical ideas into polished scores within a week for client rehearsals • Develop professional presentation skills for quick adjustments to scores Pain Points • Frequent struggle with aligning musical elements neatly, taking unnecessary hours due to limited spacing options • Manual note entry requires extra effort when intuitive shortcuts could streamline workflow • 10% of scores lose formatting fidelity due to incompatible export settings, forcing last-minute adjustments Issue Mapping #28950 — Dynamics popup should not cover the staff to which the dynamic is applied Summary: When editing dynamics placed above a staff, the popup appears below and obscures the notation. AI Reasoning: “This UI issue directly affects Yuki’s goal of creating professional-looking scores efficiently. The popup obstruction would slow her workflow during time-sensitive client projects.” Persona
Repository: flameshot-org/flameshot (Cross-platform screenshot software) Nina Patel, 34, Mumbai, India — Marketing Manager at a Tech Startup Quote “I need tools that keep up with my pace and let me share ideas instantly.” Background Nina has been in the tech marketing field for over a decade, transitioning from traditional media to digital strategies. With Mumbai’s vibrant startup ecosystem, she often needs to capture and annotate screenshots for presentations and online campaigns. Goals • Achieve polished presentations with annotated visuals using integrated editing tools • Transform raw screenshots into shareable content within 15 minutes for quick team feedback • Customize appearance to match brand guidelines for consistent visual communication Pain Points • Weekly struggle with editing screenshots taking 30+ minutes due to switching between apps • Setting up tools requires more time than ideal, blocking swift adaptation to new platforms • 20% of shared visuals are delayed due to inconsistent formatting, forcing last-minute adjustments Issue Mapping #4062 – Text tool is ignoring first edit Summary: First text edit reverts to original content; subsequent edits work correctly. AI Reasoning: “Nina’s need for rapid sharing and customization of visuals aligns directly with this text editing bug. The issue would cause frustration during time-sensitive campaign work where quick annotations are essential.” Persona
Repository: calcom/cal.com (Open-source scheduling infrastructure) Marta Gonzalez, 45, Madrid, Spain — Operations Manager at a Small Consultancy Quote “Having a reliable scheduling system that clients can access without issues is crucial for our operations.” Background Marta has been managing operations for small consultancies for over 15 years. She’s responsible for ensuring smooth client interactions and internal coordination, prioritizing tools that are reliable and easy for clients to use. Goals • Streamline client booking processes with a branded scheduling interface • Enhance client satisfaction by reducing booking errors • Integrate Cal.com with existing CRM systems for unified workflow Pain Points • Occasional glitches in client-facing booking pages affect professional image • Limited customization in branded interface without technical input • Security concerns when integrating with CRM systems Issue Mapping #23463 – Slot Availability Bug: Extra unwanted slots appear despite 2-hour blocks Summary: In medical scheduling, extra time slots appear despite configuring 2-hour blocks, allowing patients to select unintended appointment times. AI Reasoning: “This directly affects Marta’s goal of reducing booking errors. Unintended slots in a client-facing system could cause scheduling confusion and undermine trust in her consultancy’s professional image.” Persona
Repository: pocketbase/pocketbase (Open-source backend in a single file) Olivia Martinez, 45, San Francisco, USA — IT Manager at a Non-Profit Organization Quote “We need a cost-effective backend solution that even our non-technical staff can manage.” Background Olivia manages a small IT team responsible for supporting the technological needs of a non-profit. With limited resources, she prioritizes solutions that are easy to manage and don’t require extensive technical expertise. Her team often includes volunteers who assist with tech tasks. Goals • Implement a secure, low-cost backend solution using PocketBase • Empower non-technical staff to manage app content via the Admin Dashboard • Reduce IT resource strain by leveraging built-in user management Pain Points • Difficulty training non-technical staff due to lack of intuitive setup guides • Missing audit log features complicate compliance reporting • Potential downtime during updates due to lack of backward compatibility Issue Mapping #5096 – Proposal: Hide record create and edit controls Summary: Feature request to limit UI controls for non-admin users to prevent accidental modifications. AI Reasoning: “This would help Olivia empower non-technical staff by preventing accidental data modifications—a key concern for teams with mixed technical abilities.” Persona
their initial assumptions about the user who submitted the issue, a priority rating on a scale of 1 (Low Priority) to 10 (Critical Priority), and a written response they would post to the user. This task captured their natural approach to issue triage before any intervention. Second, participants watched a brief introduction video to personas created by the NNGroup1 . They then were asked to explore 1 https://www.youtube.com/watch?v=rv9yfrV-EAs
at least two of the AI-generated personas we had prepared for the repository on PersonaFlow. They were asked to discuss what stood out about each persona to them and to propose a feature or improvement that would address one persona’s specific goals and frustrations. This task allowed participants to engage with the persona concept and our tool before applying it to a real issue. Finally, participants returned to the original issue from the first task, using the complete version of PersonaFlow. Now supported by
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
DIS ’26, June 13–17, 2026, Singapore, Singapore
Table 2: Summary of user study participants. Participants work on diverse OSS domains, with experience ranging from newcomers (<1 year) to veterans (20+ years). ID
Profession
Primary Language
OSS Domain
Country
Age Range
P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13
PhD Student Software Developer Software Developer Freelancer AI Engineer Author Sr. Software Engineer Developer Advocate Student Student Freelancer Consultant Software Engineer
Python PHP TypeScript C++ Python PHP Python Python JavaScript TypeScript TypeScript C C++
Data Science Web/CMS Productivity Multimedia Developer Tools Messaging Infrastructure Mobile Database Developer Tools Developer Tools Video/Multimedia Document Processing Game Engine
Canada Nepal Canada Poland Canada USA USA Taiwan Nicaragua Canada Nicaragua USA Egypt
30–34 35–40 25–29 25–29 25–29 40+ 40+ 40+ 20–24 20–24 20–24 40+ 25–29
the personas PersonaFlow had created and automatically matched to the issue, as well as other features of the tool, they rewrote their response to the issue post. Immediately after, we showed them their original and revised responses side-by-side and asked them to reflect on differences in language, tone, and content. We also asked whether their priority assessment of the issue had changed. This comparison allowed us to observe how persona exposure influenced their communication approach. Free Exploration of PersonaFlow’s Features. Participants were then asked to freely explore the tool for about 30 minutes. They could either continue with the same repository or analyze the other repository they had provided during recruitment. During this exploration, we asked questions about their feedback on various tool features, as well as their overall impressions of the tool’s potential for supporting user awareness and understanding during OSS development practices.
4.4
Data Analysis
The recordings of the study sessions were fully transcribed. We conducted a thematic analysis [1, 40] to identify patterns and insights within the data. The first author led the data analysis process, supported by frequent meetings and discussions with other authors for the synthesis of themes and clarification of any ambiguity. Specifically, we first assigned structural codes to different segments of the transcripts, aligning these codes with the overall structure of our study to facilitate subsequent analysis. Next, an inductive coding approach was employed to identify themes and concepts from participants’ comments and feedback. Descriptive codes were generated initially from the raw data, capturing distinct ideas, opinions, or experiences expressed by participants. The codes were then iteratively grouped into categories, which were further organized into themes. The themes were then arranged into four overall groups: (1) participants’ current issue handling approach, (2) the impacts of personas incorporated in PersonaFlow on participants’ user empathy, (3) participants’ perceptions and feedback on PersonaFlow, and (4) factors that can affect the adoption of tools like PersonaFlow in practice. The coding and grouping were done collaboratively through multiple rounds of discussions among the authors.
5
Gender
OSS Exp.
F M M M M M M M M M M M M
1-3 years 1-3 years 1-3 years <1 year 5-10 years >20 years 10-20 years 10-20 years 1-3 years <1 year <1 year >20 years <1 year
User Study Results
Our analysis shows that personas and the various features of PersonaFlow have affected how participants perceive and address users’ questions and requests raised in GitHub issues. Participants also provided feedback on our tool and discussed factors that can influence its adoption in their real-world practices. We present these findings in the following sections. In addition, Appendix B presents two detailed case studies from our study, walking through the full workflow of two participants—from repository input and system processing to persona generation, issue mapping, and developer interaction—on two real repositories.
5.1
The Pre-Existing Technical Orientation in Issue Handling
Before exposure to PersonaFlow, developers exhibited patterns consistent with the empathy gap identified in prior research on distributed software development [6, 15]. While some participants reported attempting empathetic behaviors (e.g., P10 described trying to “put myself in [the] position of someone without technical prowess” when testing UI), these efforts were inconsistent and unsystematic. We identified the following common tendencies of issue handling from participants’ comments and behaviors. When handling issues, developers lacked a user-centered perspective, prioritizing technical validation over understanding user needs. As P12 explained: “It’s about effective communication and reduction of time spent on a particular issue,” framing developeruser interaction as an efficiency problem rather than a human connection. Similarly, P4 noted their focus on “solutions... about the technicalities,” treating issues as puzzles to solve rather than people to help. This technical orientation extended to strategies to respond to issue requests: P10 described a systematic workflow of “try and get them [users] to give me step by step what they did... reproduce it on my end... do a lot of logs.” While methodologically sound, this approach treats issue reporters primarily as information sources for software problem diagnosis, where user goals, context, and frustration are rarely factored into discussions. Additionally, developers struggled to infer user characteristics and emotions from written reports. To assess the expertise
DIS ’26, June 13–17, 2026, Singapore, Singapore
of the software users, they relied on existing artifacts as proxies. For example, P8 observed how writing style signaled competence: “It’s properly written... [probably by] someone who has written an issue before... So it sounds like a person actually has a clue of what they’re doing.” P9 described checking GitHub profiles: “If it’s a new account... they don’t know much about coding, they just create the GitHub account and put the issue.” While these heuristics helped prioritize, they risked dismissing legitimate issues from less technical and novice users. Detecting emotions proved even harder—frustration was only visible through explicit signals, which are also sparse. P3 noted: “It would be difficult unless they make it very clear, like they’re typing in uppercase and they’re swearing... But if they’re just typing normally, I would assume they’re neutral.” Beyond technical orientation, developers faced systemic barriers that actively inhibited empathetic engagement. For example, P13 discussed the constant flow of issues that OSS developers often face, which can limit the time and energy available to consider the perspectives of others: “The open-source developers are the ones that actually carry the community and no one ever thinks about them... They are always getting just issues and then issue after issue.” Indeed, the high workload created an emotional burden on developers that can foster defensive stances. P12 depicted this stance bluntly: “RTFM. Read the f**king manual,”, illustrating their frustration with handling constant requests and their expected ways to resolve this tension: users should self-educate before engaging. This expectation is reasonable for certain issues, but can create a high barrier to entry that excludes users who are unfamiliar with the code base and documentation. When prioritizing issues, developers relied on aggregate metrics rather than individual user needs. P2 described a thresholdbased approach: “If any user comes and says if that’s not working for them but it’s working for 500 customers... we will collect feedback until a few of the customers hit that threshold.” This meant that individual users, no matter how frustrated, were systematically deprioritized until more reports surfaced. Technical severity further shaped prioritization, with UX issues ranked below functional failures. For example, P9 dismissed a UI/UX issue as low priority because “it’s not like breaking anything, it’s just an extra step the user has to do.” Such a perspective and approach often leave persistent usability issues affecting individuals unaddressed.
5.2
Persona Impact on Developers’ User Empathy
Of the 13 participants, eight (61.5%) modified their responses after seeing the personas, a notable shift given that participants had just written their initial response moments earlier. Among the five who did not revise, two considered their original responses already appropriate for any user type (P2, P6), two reported internal attitudinal shifts without visible textual changes (P8, P9), and one would only modify their response conditionally for a different persona type (P11). For those who changed their responses, the nature of the changes revealed empathy activation: responses shifted from purely technical to acknowledging user experience. For example, P1’s initial response advised users to “avoid the extra clicking,” implicitly blaming user behavior; but after seeing the persona, P1 added: “I can understand, with this bug, your workflow may be affected and
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
you may feel frustrated.” Similarly, P3’s generic acknowledgment of issue request transformed into: “I understand that you are having trouble with this because organization truly matters to you... You are not going to have to deal with this pain anymore.” P3 also raised their priority rating (measured on a 1–10 scale from Low to Critical) from 3 to 8, demonstrating that empathy translated into concrete prioritization changes. The impacts of the persona also manifested in participants’ verbally reported changed feelings about the users. Regarding these impacts, we have identified the following themes. Notably, personas had varying effects across participants. Some participants expressed empathy shifts, although without visible behavioral changes. For example, P8 reported that personas provide “some positive impact on having a name and having a face to a person... [though] it’s an AI generated person;” but they did not perform any change to their response comment to the issue. Others demonstrated conditional calibration towards a certain group of users. For instance, after assessing one issue with the mapped persona of a senior developer, P11 judged their response to the issue appropriate, and explained that they would modify their response for a junior persona who was “first time working with Remotion.” For many, however, exposure to the personas translated into major changes in their communication in the issue discussion thread. For instance, P5 explained how seeing the technical experience of the persona shaped their approach: “Since it’s a junior developer... I will try to maybe add some links to how to install the library properly.” Participants also added explicit personal acknowledgment of user impact when adjusting their response after seeing the personas. For example, P10 added this sentence in their response to personally address the issue poster as a user: “Hopefully this alleviates the friction for your debugging.” Generally speaking, personas steer the developers’ pre-existing mindset, that is primarily code-centric, closer to user-centric thinking, disrupting their default technical orientation. P10 succinctly summarized how the persona reoriented their focus: “As soon as you have this persona that you’re responding to... it helps me better ground myself in what the user needs... [without it] you’re thinking just in terms of the code.” These shifts are manifested in the following three ways. First, the personas enabled participants to see users as concrete individuals, transforming abstract issue reporters into individuals with backgrounds, goals, and frustrations. For instance, P10 observed how personas humanized what had been an anonymous exchange: “It’s easy to kind of say, ‘oh, like whatever, there’s this little bug, I’ll get to it when I get to it.’ But then once you see these personas and you get the idea of why they’re being affected by it, how it’s harming their workflow, I find I am a lot more empathetic.” Second, the personas allowed the participants to think about a broader spectrum of users. For example, P13 observed: “Without these personas, probably they wouldn’t think about all of these users for their engine...[such as] a professor who’s trying to teach... this is eye opening to say the least.” Finally, the personas helped participants understand the impact of issues on the users. In this, P1 described an attitude shift from annoyance to understanding, when looking at a persona generated for repositories they were familiar with: “From negative to positive... this person tried to integrate my code into his workflow but it does not work well. So I may have a more positive idea about why I should update.”
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
Moreover, while some participants remained skeptical of the usefulness of personas concerning empathy building, they still suggested benefits of PersonaFlow on issue impact analysis and productivity. For example, P10 described using persona analytics for issue prioritization: “If I see one Persona that has like eight bugs and the others have two, maybe I’ll prioritize that persona [with eight bugs] so those types of users aren’t getting the short end of the stick.” Others rationalized the persona’s benefits purely as efficiency gains. P9 explicitly rejected the empathy frame: “I don’t feel it more as an empathy tool... I feel it more [as a] way to easily triage the issue.” These expected usages suggest that using personas to approach the issue discussion space can nudge usercentered behavior even among developers who reject empathy as a goal: behavioral change occurred independently of conceptual buy-in. The case of P12 further demonstrated this observation: P12 stated “I don’t buy the persona concept,” but still added a practical workaround to their response after seeing the persona.
5.3
Participants’ Perceptions and Feedback to the Design of PersonaFlow
Participants provided feedback on both the persona content and the features of PersonaFlow. Overall, they valued the simplicity of the tool. For example, P7 praised the interface: “Hugely easy to use.” P4 also noted: “The UI of the tool is really nice... It’s clear what is where and it seems straightforward to use.” The concise persona formats also prevented information overload, as P4 mentioned: “It’s good that [the personas are] short and to the point... each persona is not a three-page essay.” Beyond general simplicity and usability, developers discussed which persona elements were effective at surfacing user context and how the tool design supported empathetic engagement. 5.3.1 Feedback to Persona Content Elements. Among the persona content elements, participants valued pain points, goals, and backgrounds for surfacing user context. For example, P6 valued how these elements synthesized user information: “I like how it ... shows you how they’re involved... what their main goals are and the main competencies they have.” P9 also appreciated: “I really like the pain points and frustrations because it let me know their goals and motivations.” P10 found it useful to have these elements always available whenever a persona is referred to, including on the issues page: “Being able to click on their goals, motivations, pain points... It’s very good to always keep in mind what their goals are.” However, participants held competing opinions about the demographic information of the personas. Some viewed such information as irrelevant noise. For example, P8 dismissed those attributes: “Location. Age. Name. And the picture? None of those things [are useful]... literally the only thing I would probably find helpful is the role.” Others valued demographics precisely because they enabled human connection. For instance, P10 noted that “having the pictures too... very like humanizes the personas,” while P4 saw the primary value as “a nice tool to remind developers that there is a person on the other side.” 5.3.2 Participants’ Strategies Navigating the Automatically Generated Content. Developers did not passively accept AI-generated personas. Instead, they drew on their domain expertise and existing
DIS ’26, June 13–17, 2026, Singapore, Singapore
knowledge of users to critically evaluate whether each persona accurately represented their user base. To calibrate trust, developers validated AI-generated personas by testing them against their existing knowledge of users. For example, P4 trusted a persona because it matched real people: “There are people who actually I know and they produce music with the help of Audacity... I am not surprised this persona appears here.” P8 also validated a persona when goals mirrored the product’s core value: “Being offline capable was the number one argument for why Realm is so amazing. So this persona has exactly the goals that make sense.” Conversely, when personas conflicted with developers’ mental models, they tended to be rejected. For instance, P5 dismissed non-technical personas for technical tools: “I don’t think a project manager would be interested in knowing anything about Python dotenv... this is more popular for developers.” P8 caught technical inconsistencies: “Realm Swift is for iOS because it’s Swift. So the whole backend thing [described in this persona] I’m not really sure about.” However, detailed backgrounds sometimes enabled reconsideration. P5 initially dismissed the project manager persona but changed their view after reading the context: “That becomes more interesting because our project manager will make sure that we’re using a proper tool.” Despite critical evaluations, developers accepted AI limitations while remaining vigilant about persona accuracy. P8 articulated a pragmatic stance: “You can’t trust 100%, but you get a lot of productivity boost out of it... AI is sometimes wrong. We’re humans, we’re also sometimes wrong.” However, developers recognized that persona accuracy carried significant stakes. P4 warned: “Doing personas badly, like low-quality personas, can possibly be devastating for the project... if you misrepresent the user base.” P3 suggested that AI could help maintain objectivity: “It would be nice if the AI could keep me non-biased... detect ‘I think you’re going out of context here.’ ” 5.3.3 Feedback to the Tool’s Features. For large-scale projects, automated persona generation reduced workload while preserving human control. P8 appreciated the scale: “Getting those personas out of a repository, especially if we look at 6700 issues. You’re not going to read them. You need some kind of tool to help you set up those personas.” The confidence indicator and editing feature were valued for correcting AI outputs. P8 explained: “The 85% confidence basically tells us it’s just 85% accurate... having an edit feature for exactly that reason I think super helpful.” P4 described the ideal workflow: “I would probably create as many [personas] as possible... try to merge the obvious ones... edit them as I go.” P5 also noted that merging helped make more reasonable personas: “Merging both of them to have a CTO with an interesting background in neural network development is a persona that is plausible.” When managing large backlogs of user-reported issues, issue-topersona mapping aided prioritization and decision support. For example, P2 appreciated this integration: “Pulling the issues from GitHub... and associating them to the personas automatically... help us to categorize the issues more precisely.” P10 found the rationale generated for persona to issue mapping useful as a quick reference: “I like this little section about why this match... if I don’t really remember the full persona, at least I get a little summary of why it matches.” Moreover, developers wanted further transparency
DIS ’26, June 13–17, 2026, Singapore, Singapore
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
to inform their judgment, as P1 explained: “I’m interested in why the other persona does not match... I want to have both perspectives... and make my final decision.” At the project level, the analytics dashboard enabled coverage synthesizing and strategic planning. P13 found value in such aggregate views: “As a visual person, having this persona coverage graph is for me one of the best features... You can easily see which persona [is more affected].” P3 appreciated how the dashboard surfaced development priorities: “It allows you to know... what’s my software struggling with the most.” P4 noted that the dashboard helped identify neglected users: “It tells you which kind of users are the most likely to have some issues with your software... a nice way to suggest some part of the audience that maybe should get more attention.” Looking ahead, developers requested various features to extend tool capabilities. P13 desired automated priority ranking to have “the critical level or the urgent level” to help them decide “what I should work on now.” P7 suggested features for generating or recommending issue responses based on persona characteristics. P8 proposed tighter GitHub integration: “If you generate those personas as labels... I don’t even need a secondary list view.”
Participants also considered PersonaFlow as a useful supplement for existing OSS tools, which offers prioritization signals but lacks visibility into the most affected user types; for example, P9 noted: “Currently, there’s no way on GitHub of easily seeing everything... if we have 18, 20, 50, 100 issues... finding out what should be worked on first, we have to go one by one. That’s a pain.” At the organizational level, however, developer-user distance created structural barriers to empathy. In many organizations, developers do not interact with users directly. Instead, project managers, support teams, or other intermediaries filter and relay user feedback, often stripping away the human context. P4 described: “There are just too many layers from the user to developer for the communication to stay human-like.” In such environments, personas might provide developers with the removed context for a more human-centered understanding of users and their needs. Moreover, organizational metrics often overrode persona insights. P12 stated bluntly: “There is a way more important persona in the company: the boss.” Payment tiers also determined priority regardless of user needs: “Paid customers receive highest priority... even if it’s a minor issue.” These findings suggest that persona tools operate within organizational constraints and need to find ways to navigate their influence on different stakeholders and their actual priorities.
5.4
6
Factors Affecting Tool Adoption
Participants discussed many factors that could shape not only whether they would use the tool, but also whether they had existing channels for user empathy that the tool might supplement or enhance. At the individual level, prior experience with personas or user-centered methods can increase adoption. Formal training provided conceptual familiarity, as P7 recalled: “I remember doing some vague training on them way back about personas.” Practical application in other contexts also helped; P8 had encountered personas in developer advocacy: “Sometimes you would, when you write an article, describe a persona that the article is for.” Even informal user-centered practices created readiness; for instance, P10 described routinely simulating user perspectives: “I’ll go through opening the UI and think, if I wanted to do this specific use case, how would I walk through step by step.” These varied exposures through training, practical use, or self-developed habits reduced the conceptual leap required for adoption. Developer role also determined perceived need for empathy support. Backend developers saw limited applicability, while product-facing roles found personas valuable. On this, P5 noted: “If I’m developing a new product because I want to launch my startup, then having a tool like this will definitely help me.” Adoption was highest among developers who valued empathy and lacked other means to achieve it. At the project level, scale drives adoption, especially in OSS projects where issue volume exceeds what maintainers can manually process. Larger projects saw greater benefit, as P8 noted: “The bigger the repository, the more helpful probably it is because AI is taking a lot of the [work].” OSS contexts amplify this challenge: issues arrive continuously from users that developers may never meet, making it harder to understand who is affected. On this, P10 explained: “I would absolutely use this... especially an open-source repository where it’s constantly being updated from new issues coming in... having a little persona next to it would help humanize the user.”
Discussion
Through our user study with 13 developers, we observed that the AI-generated personas, their mapping to user-initiated discussions, and other features provided in PersonaFlow helped the participants shift from a purely technical problem-solving mindset toward usercentered communication. The changes were substantial: developers acknowledged user frustration, tailored explanations to skill levels, and raised priority ratings based on user impact. Below, we reflect on what we learned from the design of PersonaFlow and discuss the broader conceptual implications of persona-based tools. Together, these reflections offer design implications for future tools that aim to bring human context into distributed work, such as OSS development.
6.1
Practical Implications for Designing AI-Assisted Persona Tools for OSS
6.1.1 Reflections on DG1: Providing Insights into User Impact. PersonaFlow aims to incorporate personas to help OSS developers remain mindful of and better empathize with their users. Participants appreciated seeing the roles, goals, and pain points of potential users in the personas. They seemed to respond more strongly to these persona elements than to the demographic information like age and gender. No participant mentioned being influenced by demographic details alone. This suggests that effective empathysupporting tools should emphasize what users are trying to accomplish rather than their surface-level demographics. Moreover, the analytics dashboard included in PersonaFlow emerged as an important synthesizing tool. Participants used it to identify when certain user types faced disproportionate issues and adjusted priorities accordingly. This systemic perspective complements empathy towards individual user types by making structural inequities visible at the project level. Future tools could further expand this synthesizing mechanism with metrics that track not just issue counts but
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
also resolution times, priority levels, and response quality across persona types. The system could also generate alerts when specific personas are being systematically underserved, prompting proactive attention to neglected user segments. On the other hand, however, we need to be aware that personabased approaches have their own limitations, depending on the nature of the OSS projects and their issues. Many OSS issues are indeed code-based and technical. Some of our participants found personas unhelpful when the barrier to response was insufficient technical information, rather than missing user context. Additionally, for large-scale projects, the number of issues can be overwhelming [4], making it difficult for OSS maintainers to assess user impact on an issue-by-issue basis. As a result, identifying a proper scope for applying persona-based tools is important. Prior techniques for characterizing usability and UX issues in OSS [35] can be used to identify issues for which personas are most relevant and helpful. And as discussed before, going beyond issue mapping to synthesize information at the project level can help OSS developers better cope with scale-related challenges. 6.1.2 Reflection on DG2: Low-Barrier Automated Persona Generation. To allow the OSS communities that often lack sufficient resources and expertise for traditional UX practices to benefit from persona-based approaches, by default, our tool derives personas directly from repository artifacts. This simple kick-start mechanism received some positive feedback from participants, who found the tool easy to adopt and use. However, this approach poses several important risks, since AI-generated personas inherit the biases of their source data. Particularly, README files, documentation, and issue reports are artifacts that reflect the perspectives of those who already have access and a voice in the project. Users who do not file issues, who lack the technical vocabulary to articulate problems, or who abandon software before reporting frustrations remain invisible. As such, rather than democratizing user representation, AI personas may amplify existing representation gaps by giving synthetic presence to the already-visible stakeholders while further marginalizing silent users. Tools should acknowledge these limitations rather than presenting AI-generated personas as comprehensive user coverage. Ideally, persona creation and generation should still be based on user research outcomes [7, 11]. In fact, by incorporating additional types of artifacts as input, our tool can be extended to support traditional persona approaches if the projects have the required user research infrastructure. This includes data-driven approaches generating personas based on user analytics or behavioral data [19, 33], as well as using traditional qualitative interview or survey data as input. Transparency features and user control mechanisms (see Section 6.1.4) are also important for OSS community members to assess and adjust the generated content. Moreover, PersonaFlow currently generates personas only once based on data input, while OSS projects and their user communities are dynamic, with evolving features, contributors, and usage patterns. The tool currently does not support automated persona updates to capture these changes. Future work could explore mechanisms for continuously evolving personas that adapt as the project changes, incorporating new issues, user research data, user behavior patterns, and other artifacts.
DIS ’26, June 13–17, 2026, Singapore, Singapore
6.1.3 Reflection on DG3: Workflow Integration and Flexibility. PersonaFlow closely connects with GitHub and integrates personas with existing OSS workflows related to issue review, triaging, and responding. Participants highly valued such integration, considering it facilitated smooth adoption and aided decision making. Particularly for issue-persona mapping, participants appreciated the design of this feature for providing quick references of unfamiliar personas and making AI reasoning transparent for validation. They further expressed interest in even deeper integration, such as embedding personas as GitHub labels, using such information for automated adjustment of issue priority, or notifying relevant team members when issues related to a certain persona are posted. Although connected with GitHub through its API, our tool is currently implemented as a standalone tool. This is a conscious decision made during our initial ideation (see Section 3.2). However, further integration could be achieved if the OSS hosting platforms, such as GitHub or GitLab, integrate related features through extensions or plugins. Similarly, plugins that integrate PersonaFlow features directly within existing development tools (such as IDE extensions) or communication tools (such as Discord or Matrix) could further reduce friction and increase adoption. 6.1.4 Reflection on DG4: Transparency and User Control. PersonaFlow provided multiple ways for users to examine, change, and override AI-generated content and decisions. Facing the automatically generated personas, our participants actively validated them against their existing mental models, rejecting those that conflicted with their understanding of the project. The persona editing and merging features were valued by participants for addressing AI limitations. The confidence scores for issue-persona mappings also prompted the participants to scrutinize these generated relationships. These validation behaviors suggest that participants treated AI-generated personas as provisional tools rather than authoritative outputs, considering them as starting points for reflection and refinement. These findings align with our purpose of using AI to generate personas in PersonaFlow: it is used to scale adoption of personas across a wider range of OSS projects, for activating developers’ user-centered awareness, allowing them to recognize the importance of users’ perspectives and appreciate UX work, rather than replacing actual user interaction or traditional UX practices. However, we recognize that, combined with low-barrier adoption (DG2), such tools may be perceived as shortcuts to increase efficiency, rather than enablers for stimulating a truly user-centered perspective. To mitigate this, future tool design should further emphasize user control by requiring more explicit human validation, revision, or justification before AI-generated personas are adopted. The transparency features could also be expanded to provide more detailed explanations of how personas were generated and why specific attributes were assigned. Information about possible biases and limitations, stemming from the source data used for persona generation (see Section 6.1.2), could also be presented to support critical evaluation of AI-generated content.
6.2
Critical Reflections on Empathy as a Systemic Problem
Stepping back from the specific design goals, our findings reveal a deeper insight into why personas were effective. In the current
DIS ’26, June 13–17, 2026, Singapore, Singapore
OSS development environment, developers simply lacked the user context needed to respond to user requests empathetically. This was not a personal failing but a consequence of how distributed development is organized: anonymous issue reports, intermediary layers between developers and users, efficiency-driven workflows, and aggregate metrics that obscure individual experiences. As a result, we should not consider OSS developers’ lack of user-centeredness as an individual “empathy gap” that developers should fix through training or attitude adjustment. Rather, it should be viewed as a systemic problem rooted in the information environment of OSS itself. This reframing has significant implications for tool design: rather than training individual developers to have more user empathy, we should redesign the information environment of OSS development to surface user context. Our findings suggest a role for AI not as a replacement for human connection but as infrastructure for enabling it. Features of PersonaFlow serve as catalysts to activate perspective-taking that would otherwise remain dormant among OSS developers. Concretely, our results revealed two distinct pathways for developers to engage with and benefit from tools like PersonaFlow. On the one hand, participants valued the empathy-building power of personas, perceived personas as strong triggers of emotional responses that motivated empathetic communication. On the other hand, some participants considered personas as pure utility-orienting syntheses, allowing them to efficiently assess impacts and prioritize requests. These dual pathways have practical implications: personabased tools need not force developers to adopt an “empathy mindset” that some may resist. Instead, by providing information useful for both empathy-driven and utility-driven purposes, tools can activate user-centered behavior across diverse orientations of developers. Beyond OSS development, our findings suggest broader implications. Domains where human contexts are removed by the platform or overshadowed by work-related content (e.g., remote teams [8], gig work on online platforms [46], healthcare relying on electronic patient records [18], AI-mediated job recruitment [21], to name a few) may benefit from similar tools that surface human context to nudge practitioners during the existing workflow. The systemic empathy problem is not unique to software: it emerges wherever efficiency-driven systems or workflows abstract away the humans who need to be served. Our findings offer a generalizable pattern: we could redesign information environments to activate perspectivetaking during the existing practice, just as PersonaFlow presents affected user personas alongside GitHub issues.
6.3
Limitations and Future Work
Our study has several limitations that suggest directions for future research. First, our sample of 13 participants, while providing rich qualitative insights, limits generalizability. Larger studies across diverse developer populations and project contexts would strengthen our claims. Second, participants completed a simulated task rather than responding to issues in their actual projects with real consequences. While we used authentic issues from real repositories, the experimental context may have amplified empathy effects that would be muted in real-world settings with time pressure, competing priorities, and organizational constraints. Third, our study procedure introduced the persona concept through a video before
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
participants used PersonaFlow, which may have primed empathetic responses. Regardless, most of our results reflect how participants directly responded to the various features provided by PersonaFlow. This short video priming, if effective, can also be integrated into future tool design to enhance its impact in real-world settings. Fourth, the user study only allowed us to capture immediate responses; longitudinal deployments would reveal whether effects persist or diminish through habituation. Finally, the trust dynamics we observed also merit deeper investigation. Developers validated AI-generated personas against their existing mental models, but these mental models may themselves contain biases. Future work should examine whether personas can productively challenge developer assumptions or whether confirmation bias leads developers to accept only personas that match their preconceptions.
7
Conclusion
OSS developers often struggle to understand user context because tools like issue trackers prioritize technical communication while obscuring human elements. Recognizing this challenge, we developed PersonaFlow, a tool that supports the generation of user personas from repository artifacts and integrates them into the existing issue management workflow of OSS developers. Our user study with 13 participants suggests that the tool helped activate and enhance their user-centric mindset and behavior. This is achieved through two distinct pathways: some developers connected emotionally to personas as real people (empathy-driven), while others used them pragmatically for efficient issue triaging and handling (utility-driven). This suggests that persona-based tools can benefit developers with diverse orientations, without requiring conceptual buy-in to “empathy” as a goal. Overall, our investigation emphasized empathy challenges in distributed development as a systemic problem rooted in information environments that provide rich technical data but little user context. We offer design implications for AI-assisted persona tools within and beyond OSS and hope this work encourages further exploration aimed at bridging the humancontext gap within socio-technical work systems.
Acknowledgments We thank our participants for their time and valuable insights. We also thank the anonymous reviewers for helping us improve the paper. This work is partially supported by the Alfred P. Sloan Foundation (G-2021-16745) and the Canada Research Chairs program (CRC-2021-00076).
References [1] Jodi Aronson. 1995. A Pragmatic View of Thematic Analysis. The Qualitative Report 2, 1 (1995), 1–3. doi:10.46743/2160-3715/1995.2069 [2] Deeksha Arya, Wenting Wang, Jin L.C. Guo, and Jinghui Cheng. 2019. Analysis and Detection of Information Types of Open Source Software Issue Discussions. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). 454–464. doi:10.1109/ICSE.2019.00058 [3] Sogol Balali, Igor Steinmacher, Umayal Annamalai, Anita Sarma, and Marco Aurelio Gerosa. 2018. Newcomers’ Barriers. . . Is That All? An Analysis of Mentors’ and Newcomers’ Barriers in OSS Projects. Comput. Supported Coop. Work 27, 3–6 (dec 2018), 679–714. doi:10.1007/s10606-018-9310-8 [4] Olga Baysal, Reid Holmes, and Michael W. Godfrey. 2014. No issue left behind: reducing information overload in issue tracking. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (Hong Kong, China) (FSE 2014). Association for Computing Machinery, New York, NY, USA, 666–677. doi:10.1145/2635868.2635887
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
[5] Cynthia L. Bennett and Daniela K. Rosner. 2019. The Promise of Empathy: Design, Disability, and Knowing the "Other". In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (Glasgow, Scotland Uk) (CHI ’19). Association for Computing Machinery, New York, NY, USA, 1–13. doi:10.1145/3290605.3300528 [6] E. Carmel and R. Agarwal. 2001. Tactical approaches for alleviating distance in global software development. IEEE Software 18, 2 (2001), 22–29. doi:10.1109/52. 914734 [7] Alan Cooper. 1999. The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Sams Publishing, Indianapolis, IN. [8] Catherine Durnell Cramton. 2001. The Mutual Knowledge Problem and Its Consequences for Dispersed Collaboration. Organization Science 12, 3 (June 2001), 346–371. doi:10.1287/orsc.12.3.346.10098 [9] Wen Duan, Christopher Flathmann, Nathan J. McNeese, Matthew J. Scalia, Ruihao Zhang, Jamie Gorman, Guo Freeman, Shiwen Zhou, Allyson I. Hauptman, and Xiaoyun Yin. 2025. Trusting Autonomous Teammates in Human-AI Teams - A Literature Review. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (Yokohama, Japan) (CHI ’25). Association for Computing Machinery, New York, NY, USA. doi:10.1145/3706598.3713527 [10] Mica R. Endsley. 1995. Toward a Theory of Situation Awareness in Dynamic Systems. Human Factors 37, 1 (1995), 32–64. doi:10.1518/001872095779049543 [11] Shamal Faily and Ivan Flechais. 2011. Persona cases: a technique for grounding personas. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Vancouver, BC, Canada) (CHI ’11). Association for Computing Machinery, New York, NY, USA, 2267–2270. doi:10.1145/1978942.1979274 [12] Joseph Feller, Brian Fitzgerald, Scott A Hissam, and Karim R Lakhani. 2005. Perspectives on free and open source software. MIT Press, Cambridge, Mass. doi:10. 7551/mitpress/5326.001.0001 [13] Isabella Ferreira, Bram Adams, and Jinghui Cheng. 2022. How heated is it? understanding GitHub locked issues. In Proceedings of the 19th International Conference on Mining Software Repositories (Pittsburgh, Pennsylvania) (MSR ’22). Association for Computing Machinery, New York, NY, USA, 309–320. doi:10. 1145/3524842.3527957 [14] Isabella Ferreira, Jinghui Cheng, and Bram Adams. 2021. The "Shut the f**k up" Phenomenon: Characterizing Incivility in Open Source Code Review Discussions. Proc. ACM Hum.-Comput. Interact. 5, CSCW2, Article 353 (Oct. 2021), 35 pages. doi:10.1145/3479497 [15] Hashini Gunatilake, John Grundy, Rashina Hoda, and Ingo Mueller. 2024. Enablers and Barriers of Empathy in Software Developer and User Interactions: A Mixed Methods Case Study. ACM Trans. Softw. Eng. Methodol. 33, 4, Article 109 (apr 2024), 41 pages. doi:10.1145/3641849 [16] Jazlyn Hellman, Jiahao Chen, Md. Sami Uddin, Jinghui Cheng, and Jin L. C. Guo. 2022. Characterizing user behaviors in open-source software user forums: an empirical study. In Proceedings of the 15th International Conference on Cooperative and Human Aspects of Software Engineering (Pittsburgh, Pennsylvania) (CHASE ’22). Association for Computing Machinery, New York, NY, USA, 46–55. doi:10. 1145/3528579.3529178 [17] Jazlyn Hellman, Itai Epstein, Jinghui Cheng, and Jin L.C. Guo. 2025. ’Ohhh, he’s the boss!’: Unpacking Power Dynamics Among Developers, Designers, and End-Users in FLOSS Usability. Proc. ACM Hum.-Comput. Interact. 9, 7, Article CSCW262 (Oct. 2025), 30 pages. doi:10.1145/3757443 [18] Linda M. Hunt, Hannah S. Bell, Allison M. Baker, and Heather A. Howard. 2017. Electronic Health Records and the Disappearing Patient. Medical Anthropology Quarterly 31, 3 (May 2017), 403–421. doi:10.1111/maq.12375 [19] Bernard J. Jansen, Joni O. Salminen, and Soon-gyo Jung. 2020. Data-Driven Personas for Enhanced User Understanding: Combining Empathy with Rationality for Better Insights to Analytics. Data and Information Management 4, 1 (2020), 1–17. doi:10.2478/dim-2020-0005 [20] Soon-Gyo Jung, Joni Salminen, Kholoud Khalil Aldous, and Bernard J. Jansen. 2025. PersonaCraft: Leveraging language models for data-driven persona development. International Journal of Human-Computer Studies 197 (2025), 103445. doi:10.1016/j.ijhcs.2025.103445 [21] Mitra Lashkari and Jinghui Cheng. 2023. “Finding the Magic Sauce”: Exploring Perspectives of Recruiters and Job Seekers on Recruitment Bias and Automated Tools. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems (Hamburg, Germany) (CHI ’23). Association for Computing Machinery, New York, NY, USA, Article 868, 16 pages. doi:10.1145/3544548.3581548 [22] Shuai Ma, Ying Lei, Xinru Wang, Chengbo Zheng, Chuhan Shi, Ming Yin, and Xiaojuan Ma. 2023. Who Should I Trust: AI or Myself? Leveraging Human and AI Correctness Likelihood to Promote Appropriate Trust in AI-Assisted DecisionMaking. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems (Hamburg, Germany) (CHI ’23). Association for Computing Machinery, New York, NY, USA, Article 759, 19 pages. doi:10.1145/3544548.3581058 [23] Nicola Marsden and Maren Haag. 2016. Stereotypes and Politics: Reflections on Personas. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems (San Jose, California, USA) (CHI ’16). Association for Computing Machinery, New York, NY, USA, 4017–4031. doi:10.1145/2858036.2858151
DIS ’26, June 13–17, 2026, Singapore, Singapore
[24] Tara Matthews, Tejinder Judge, and Steve Whittaker. 2012. How do designers and user experience professionals actually perceive and use personas?. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Austin, Texas, USA) (CHI ’12). Association for Computing Machinery, New York, NY, USA, 1219–1228. doi:10.1145/2207676.2208573 [25] Siddharth Mehrotra, Carolina Centeio Jorge, Catholijn M. Jonker, and Myrthe L. Tielman. 2023. Integrity-based Explanations for Fostering Appropriate Trust in AI Agents. ACM Transactions on Interactive Intelligent Systems 13, 4, Article 28 (2023), 39 pages. doi:10.1145/3610578 [26] Courtney Miller, Sophie Cohen, Daniel Klug, Bogdan Vasilescu, and Christian Kästner. 2022. "Did you miss my comment or what?": understanding toxicity in open source discussions. In Proceedings of the 44th International Conference on Software Engineering (Pittsburgh, Pennsylvania) (ICSE ’22). Association for Computing Machinery, New York, NY, USA, 710–722. doi:10.1145/3510003.3510111 [27] Timothy Neate, Aikaterini Bourazeri, Abi Roper, Simone Stumpf, and Stephanie Wilson. 2019. Co-Created Personas: Engaging and Empowering Users with Diverse Needs Within the Design Process. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (Glasgow, Scotland Uk) (CHI ’19). Association for Computing Machinery, New York, NY, USA, 1–12. doi:10.1145/3290605.3300880 [28] Sangeetha Palani, David Ledo, George Fitzmaurice, and Fraser Anderson. 2022. “I Don’t Want to Feel Like I’m Working in a 1960s Factory”: The Practitioner Perspective on Creativity Support Tool Adoption. In Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems (New Orleans, LA, USA) (CHI ’22). Association for Computing Machinery, New York, NY, USA, Article 478, 18 pages. doi:10.1145/3491102.3501933 [29] Monika Pröbster, Mirza Ehsanul Haque, and Nicola Marsden. 2018. Perceptions of Personas: The Role of Instructions. In 2018 IEEE International Conference on Engineering, Technology and Innovation (ICE/ITMC) (Stuttgart, Germany). 1–8. doi:10.1109/ICE.2018.8436339 [30] John Pruitt and Jonathan Grudin. 2003. Personas: practice and theory. In Proceedings of the 2003 Conference on Designing for User Experiences (San Francisco, California) (DUX ’03). Association for Computing Machinery, New York, NY, USA, 1–15. doi:10.1145/997078.997089 [31] Abdul Razzaq, Jim Buckley, Qin Lai, Tingting Yu, and Goetz Botterweck. 2024. A Systematic Literature Review on the Influence of Enhanced Developer Experience on Developers’ Productivity: Factors, Practices, and Recommendations. Comput. Surveys 57, 3 (2024), 1–46. doi:10.1145/3687299 [32] Joni Salminen, Bernard J. Jansen, Jisun An, Haewoon Kwak, and Soon-gyo Jung. 2018. Are personas done? Evaluating their usefulness in the age of digital analytics. Persona Studies 4, 2 (2018), 47–65. doi:10.21153/psj2018vol4no2art737 [33] Joni Salminen, Chang Liu, Wenjing Pian, Jianxing Chi, Essi Häyhänen, and Bernard J Jansen. 2024. Deus Ex Machina and Personas from Large Language Models: Investigating the Composition of AI-Generated Persona Descriptions. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI ’24). Association for Computing Machinery, New York, NY, USA, Article 510, 20 pages. doi:10.1145/3613904.3642036 [34] Joni Salminen, João M. Santos, Soon-gyo Jung, Motahhare Eslami, and Bernard J. Jansen. 2020. Persona Perception Scale: Development and Validation of an Instrument for Evaluating Individuals’ Perceptions of Personas. International Journal of Human-Computer Studies 141 (2020), 102437. doi:10.1016/j.ijhcs.2020. 102437 [35] Arghavan Sanei and Jinghui Cheng. 2024. Characterizing Usability Issue Discussions in Open Source Software Projects. Proc. ACM Hum.-Comput. Interact. 8, CSCW1, Article 30 (April 2024), 26 pages. doi:10.1145/3637307 [36] Joongi Shin, Michael A. Hedderich, Bartłomiej Jakub Rey, Andrés Lucero, and Antti Oulasvirta. 2024. Understanding Human-AI Workflows for Generating Personas. In Proceedings of the 2024 ACM Designing Interactive Systems Conference (Copenhagen, Denmark) (DIS ’24). Association for Computing Machinery, New York, NY, USA, 757–781. doi:10.1145/3643834.3660729 [37] Atefeh Shokrizadeh, Boniface Bahati Tadjuidje, Shivam Kumar, Sohan Kamble, and Jinghui Cheng. 2025. Dancing With Chains: Ideating Under Constraints With UIDEC in UI/UX Design. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI ’25). Association for Computing Machinery, New York, NY, USA, Article 1106, 23 pages. doi:10.1145/3706598.3713785 [38] Jaisie Sin, R. L. Franz, Cosmin Munteanu, and Barbara Barbosa Neves. 2021. Digital Design Marginalization: New Perspectives on Designing Inclusive Interfaces. In Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems (Yokohama, Japan) (CHI ’21). Association for Computing Machinery, New York, NY, USA, Article 348, 13 pages. doi:10.1145/3411764.3445180 [39] Igor Steinmacher, Christoph Treude, and Marco Aurelio Gerosa. 2019. Let Me In: Guidelines for the Successful Onboarding of Newcomers to Open Source Projects. IEEE Software 36, 4 (2019), 41–49. doi:10.1109/MS.2018.110162131 [40] Mojtaba Vaismoradi, Hannele Turunen, and Terese Bondas. 2013. Content analysis and thematic analysis: Implications for conducting a qualitative descriptive study. Nursing & Health Sciences 15, 3 (2013), 398–405. doi:10.1111/nhs.12048 [41] Oleksandra Vereschak, Fatemeh Alizadeh, Gilles Bailly, and Baptiste Caramiaux. 2024. Trust in AI-assisted Decision Making: Perspectives from Those Behind the
DIS ’26, June 13–17, 2026, Singapore, Singapore
System and Those for Whom the Decision is Made. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI ’24). Association for Computing Machinery, New York, NY, USA, Article 28, 14 pages. https://doi.org/10.1145/3613904.3642018 [42] Wenting Wang, Deeksha Arya, Nicole Novielli, Jinghui Cheng, and Jin L.C. Guo. 2020. ArguLens: Anatomy of Community Opinions On Usability Issues Using Argumentation Models. In Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI ’20). Association for Computing Machinery, New York, NY, USA, 1–14. doi:10.1145/3313831.3376218 [43] Wenting Wang, Jinghui Cheng, and Jin L.C. Guo. 2022. How Do Open Source Software Contributors Perceive and Address Usability?: Valued Factors, Practices, and Challenges. IEEE Software 39, 1 (2022), 76–83. doi:10.1109/MS.2020.3009514 [44] Yi Wang, Chetan Arora, Xiao Liu, Thuong Hoang, Vasudha Malhotra, Ben Cheng, and John Grundy. 2024. Who Uses Personas in Requirements Engineering: The Practitioners’ Perspective. Information and Software Technology 169 (2024), 107414. doi:10.1016/j.infsof.2024.107414 [45] Mairieli Wessel, Igor Wiese, Igor Steinmacher, and Marco A. Gerosa. 2021. Don’t Disturb Me: Challenges of Interacting with Software Bots on Open Source Software Projects. Proceedings of the ACM on Human-Computer Interaction 5, CSCW1, Article 97 (2021), 21 pages. doi:10.1145/3476042 [46] Angie Zhang, Alexander Boltz, Chun Wei Wang, and Min Kyung Lee. 2022. Algorithmic Management Reimagined For Workers and By Workers: Centering Worker Well-Being in Gig Work. In Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems (New Orleans, LA, USA) (CHI ’22). Association for Computing Machinery, New York, NY, USA, Article 14, 20 pages. doi:10.1145/3491102.3501866 [47] Xishuo Zhang, Lin Liu, Yi Wang, Xiao Liu, Hailong Wang, Chetan Arora, Haichao Liu, Weijia Wang, and Thuong Hoang. 2024. Auto-Generated Personas: Enhancing User-centered Design Practices among University Students. In Extended Abstracts of the CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI EA ’24). Association for Computing Machinery, New York, NY, USA, Article 52, 7 pages. doi:10.1145/3613905.3651043 [48] Yunfeng Zhang, Q. Vera Liao, and Rachel K. E. Bellamy. 2020. Effect of Confidence and Explanation on Accuracy and Trust Calibration in AI-Assisted Decision Making. In Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency (Barcelona, Spain) (FAT* ’20). Association for Computing Machinery, New York, NY, USA, 295–305. doi:10.1145/3351095.3372852 [49] Zihe H Zhao. 2023. The Distribution and Disengagement of Women Contributors in Open-Source: 2008–2021. In Proceedings of the 45th International Conference on Software Engineering: Companion Proceedings (Melbourne, Victoria, Australia) (ICSE ’23). IEEE Press, 305–307. doi:10.1109/ICSE-Companion58688.2023.00082
A
LLM Prompts
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
For each link found, determine: 1. Is it internal (relative path in repo) or external? 2. What type of end-user information might it contain? 3. How valuable is it for understanding user needs, behaviors, and use cases? Think about: - WHO are the end users? (their roles, backgrounds, needs) - WHAT do they use this software for? - HOW do they learn and get support? - WHERE do they discuss their experiences? Be smart about identifying: - Product homepages often have user testimonials and use cases - Documentation sites reveal user workflows - Forums/communities show user problems and needs - Feature pages explain what users value - Tutorial sites show learning patterns Exclude developer-focused resources unless they contain user stories. Focus on quality over quantity - prefer 3-5 highly relevant links over many marginal ones. Return JSON in the format below: {"internal_links": [{"path": "relative/path/to/file", "expected_content": "what we might find there", "user_relevance": "why this helps understand users", "priority": 1-5}], "external_links": [{"url": "https://...", "expected_content": "what we might find there", "user_relevance": "why this helps understand users", "priority": 1-5}], "reasoning": "explanation of choices and what was excluded"}
This appendix presents the LLM prompts used by PersonaFlow.
A.1
Link Discovery Prompt
This prompt discovers links that may contain information about end users within the README of a repository. Input: Raw README content from the repository. Output feeds into: The discovered links are fetched (via GitHub API and web scraping) and combined with the README to create the Resource Corpus used by the User Insights Summary prompt. A.1.1
System Prompt.
A.2
A.2.1 You are an expert at analyzing documentation to understand software end users.
A.1.2
User Insights Summary Prompt
This prompt analyzes repository documentation and extracts a summary of user insights to inform persona generation. Input: Resource Corpus (original README + content fetched from internal_links and external_links from Link Discovery). Output feeds into: The user_types, use_cases, and pain_points are combined with the Resource Corpus to provide context for Domain Analysis. System Prompt.
Extract end-user insights for persona creation.
User Prompt. A.2.2
Analyze this README for [owner/repo] and identify links that would help understand the END USERS of this software (not developers/contributors). README Content: [README text]
User Prompt.
Analyze all this content about [owner/repo] and extract insights about END USERS: [Resource Corpus content with internal and external documentation]
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
Provide a comprehensive summary of: 1. User Types: Who uses this software? (roles, backgrounds, skill levels) 2. Use Cases: What do they use it for? (specific tasks, workflows) 3. User Needs: What problems does it solve for them? 4. Pain Points: What challenges do users face? 5. Community: How do users get support and connect? Return JSON in the format below: {"user_types": ["list of identified user types with descriptions"], "primary_use_cases": ["main ways users interact with the software"], "user_needs": ["problems it solves, value it provides"], "pain_points": ["challenges or frustrations users experience"], "community_insights": "how users learn and get support", "persona_recommendations": ["suggested personas based on findings"]}
DIS ’26, June 13–17, 2026, Singapore, Singapore
- What is the primary use case and context? 2. Key Features (How): - List the SPECIFIC features and capabilities users interact with - For each feature, explain the user workflow and use case - Note performance characteristics (speed, efficiency, limitations) - Identify integration capabilities with other tools 3. User Evidence (Who): - Extract any mentions of user types, roles, or segments - Identify different ways people might use this product 4. Behavioral Insights: - What tasks are users trying to accomplish? - What friction points or challenges are mentioned? - What motivates users to adopt this solution? Focus on concrete evidence over assumptions.
A.3
Domain Analysis Prompt
This prompt analyzes repository documentation to extract usercentric domain insights that inform persona generation. Input: Resource Corpus content combined with user_insights from the User Insights Summary prompt. Output feeds into: The domain_summary, key_features, and user_characteristics JSON is passed directly to the Persona Generation prompt. A.3.1
System Prompt.
You are a domain analyst specializing in extracting user-centric insights from technical documentation. Your goal is to uncover the human context behind the technology - who uses it, why they need it, and what challenges they face. Focus on identifying: 1. Specific product features and capabilities that users interact with 2. Common workflows and use cases 3. Integration points with other tools 4. Performance or usability constraints 5. Target user segments and their distinct needs
A.3.2
User Prompt.
Analyze the following repository content to extract domain insights for persona generation: Repository Content: [README and additional context] Extract the following information: 1. Domain Summary (What & Why): - What is this product/tool/service? - What real-world problem does it solve?
Return JSON in the format below: {"domain_summary": "Clear description of what this is and why it matters", "key_features": [{"name": "Feature Name", "description": "What it does, how users interact, what workflow it enables"}], "user_characteristics": [{"trait": "Observed characteristic", "context": "Evidence or reasoning for this trait"}], "additional_insights": ["Behavioral insight or pattern observed"]}
A.4
Persona Generation Prompt
This prompt creates diverse, evidence-based personas from the extracted domain insights. Input: Complete Domain Analysis JSON output; desired number of personas to be generated. Output feeds into: Each persona in the personas[] array is passed to Headshot Generation, and the full array is used by Issueto-Personas Matching. A.4.1
System Prompt.
You are a user research expert who creates evidence-based personas that avoid stereotypes and capture real user diversity. Your personas must be: 1. Grounded in domain analysis data and SPECIFIC to the product 2. Diverse in demographics, backgrounds, and perspectives 3. Focused on behaviors and needs, not demographics 4. Free from bias and stereotypes 5. Useful for product decisions with clear feature connections
DIS ’26, June 13–17, 2026, Singapore, Singapore
CRITICAL: Every goal and pain point MUST directly relate to using THIS SPECIFIC product/tool, not generic professional challenges.
A.4.2
User Prompt.
Based on this domain analysis, create [N] distinct user personas: Domain Analysis: [JSON domain analysis] CRITICAL CONTEXT - Generate personas representing the FULL spectrum: - Technical users (developers, DevOps, data engineers) - Business users (managers, analysts, coordinators) - Customer-facing users (support, sales, consultants) - External users (clients, partners, community members) PERSONA REQUIREMENTS: 1. True Diversity - Go beyond job titles. Consider: - Usage Context: Internal tool vs. customer-facing vs. embedded - Interaction Mode: GUI users vs. API users vs. both - Frequency: Daily power users vs. occasional vs. one-time setup - Technical Spectrum: No-code -> Low-code -> Full developers - Geographic & Cultural: Global representation - Company Size: Freelancers -> Startups -> Enterprises -> Government - Feature Focus: Different personas care about different aspects 2. Feature Coverage - Ensure personas collectively cover ALL features: - Core functionality (main workflows) - Advanced features (power user capabilities) - Integration features (connections to other tools) - Collaboration features (sharing, permissions) - API/Developer features (SDKs, webhooks, extensions) - Admin features (user management, security, compliance) 3. Realistic Goals & Pain Points: GOALS - Mix different types: a) Feature-Specific: "Reduce API integration time from 2 days to 2 hours" b) Workflow/Process: "Streamline onboarding by embedding chat widget" c) Business Outcome: "Decrease support ticket volume by 40%" PAIN POINTS - Include various friction types: a) Missing Features: "Can’t share clickable links in embedded chat" b) Poor UX/Workflow: "Setting up integrations requires 15+ clicks" c) Technical Limitations: "API rate limits prevent real-time sync" d) Business Impact: "Lack of audit logs makes compliance
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
slow" 4. Confidence Scoring (0.0-1.0): - High (0.8-1.0): Strong evidence in domain analysis - Medium (0.6-0.79): Reasonable assumptions - Low (0.4-0.59): Speculative but plausible Return JSON in the format below: {"personas": [{"name": "Realistic name", "age": 25-65, "occupation": "Specific role and company type", "location": "City, Country (diverse locations)", "quote": "Something they would say about their work/challenges", "tagline": "One-line summary of their relationship to domain", "background": "2-3 sentences: How they got here, work context", "personality_traits": ["Work style", "Learning preference"], "goals": ["Mix of technical, workflow, and business goals"], "pain_points": ["Mix of features, UX issues, limitations"], "technical_skills": ["Relevant skills", "Tools they use"], "experience_level": "beginner | intermediate | advanced | expert", "confidence_score": 0.0-1.0}]}
A.5
Headshot Generation Prompt
This prompt creates portrait images for each persona using Gemini’s image generation model. Input: Individual persona fields from Persona Generation: age, occupation, personality_traits, experience_level. Output: PNG image stored and associated with the persona for display in the UI. A.5.1
Prompt Templates.
Template 1: Natural portrait of [gender hint], [age] years old, works as [occupation]. [expression] expression. Wearing [clothing style]. [setting]. [photography style]. Authentic, genuine moment. High quality photography. Template 2: Candid photo of [gender hint] in their element. [age]-year-old. [occupation]. [expression] while working. [clothing style]. [setting]. Natural lighting, [photography style]. Real person, authentic moment. Template 3: Environmental portrait: [gender hint], [age] years old, [occupation]. Natural [expression] expression. [clothing style]. Photographed in [setting]. [photography style], documentary style.
A.5.2
Required Output.
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
Returns a generated PNG image from Gemini’s image generation model. Settings, clothing, and expressions are dynamically selected based on occupation, personality traits, and experience level. Fallback: If generation fails, a DiceBear avatar URL is generated with parameters derived from the persona’s experience level.
A.6
Persona Merge Prompt
This prompt merges multiple personas into a unified representation when users identify similar personas. Input: Two or more complete persona objects from the personas[] array, selected by the user in the UI. Output: A new merged_persona object that replaces the source personas in the repository’s persona list. A.6.1
System Prompt.
You are a persona synthesis expert. Create a coherent, unified persona from multiple sources. Focus on what these users share, not their differences.
A.6.2
User Prompt.
Merge these [N] personas into a unified persona: [Detailed persona descriptions including name, age, occupation, location, quote, tagline, background, personality traits, goals, pain points, technical skills, experience level, and tags for each persona] Create a NEW unified persona that: 1. Represents the common ground between all source personas 2. Has a coherent narrative explaining their background 3. Synthesizes goals and pain points meaningfully 4. Feels like a real person, not a list of averaged traits 5. Highlights what unites these user segments The merged persona should help teams understand what these users have in common. Return JSON in the format below: {"name": "New name reflecting the unified segment", "age": 30-50, "occupation": "Role that encompasses the pattern", "location": "Appropriate location or ’Various’", "quote": "What unites their perspective", "tagline": "Their shared relationship to the domain", "background": "Narrative explaining their common journey", "personality_traits": ["Shared trait 1", "Trait 2", "Trait 3"],
DIS ’26, June 13–17, 2026, Singapore, Singapore
"goals": ["Common goal 1", "Goal 2", "Goal 3"], "pain_points": ["Shared pain 1", "Pain 2", "Pain 3"], "technical_skills": ["Common skill 1", "Skill 2"], "experience_level": "intermediate|advanced", "tags": ["unified-segment", "tag2", "tag3"]}
A.7
Issue-Persona Mapping Prompt
This prompt maps each GitHub issue to relevant personas using evidence-based scoring and anti-pattern checks. Input: (1) GitHub issue details (title, body, labels); (2) Complete personas[] array from Persona Generation. Output: matched_persona_ids and persona_rationales stored with each issue for display in the issue detail view. A.7.1
System Prompt.
Match issues to personas based on SPECIFIC documented goals, pain points, and use cases. Every match must quote exact text from the persona’s profile that relates to the issue.
A.7.2
User Prompt.
Match this GitHub issue to relevant personas: Issue: [Title, Body, Labels] Available Personas: [JSON personas] PHASE 1: ISSUE DECOMPOSITION A. Surface Analysis - What is explicitly stated in the issue? - What technical components/features are mentioned? - What error messages or symptoms are described? B. Deep Analysis - What is the USER trying to accomplish (not just fix)? - What workflow is interrupted? - What’s the hidden frustration behind the technical description? - If this were fixed, what would the user do next? C. Issue DNA Profile - Who would write this issue: - Language complexity: Simple/Technical/Expert - Emotional tone: Frustrated/Neutral/Constructive - Detail level: Minimal/Adequate/Comprehensive PHASE 2: REVERSE MATCHING - For each persona, ask: 1. "Would THIS persona write THIS issue in THIS way?" 2. "What language would they use differently?" 3. "What details would they include/omit?" 4. "How urgent would this be for them specifically?" Red flags for false matches: - Persona’s vocabulary doesn’t match issue language - Issue complexity exceeds persona’s technical level - Persona has workarounds the issue author clearly doesn’t
DIS ’26, June 13–17, 2026, Singapore, Singapore
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
PHASE 3: EVIDENCE-BASED SCORING (0-100 points) Direct Evidence (40 pts max): - Goal explicitly mentions affected feature: +20 - Pain point directly describes this problem: +20 Behavioral Evidence (30 pts max): - Would encounter this in primary workflow: +15 - Issue blocks a documented goal: +15 Contextual Evidence (30 pts max): - Technical level matches issue complexity: +10 - Persona’s context explains issue urgency: +10 - Language/tone alignment: +10 DEDUCTIONS: - Persona has easy workaround: -20 - Technical mismatch: -30 - Would rarely use affected feature: -40 PHASE 4: ANTI-PATTERN CHECK - Reject matches showing: 1. Keyword Matching: "Both mention ’performance’" without behavioral link 2. Role Assumption: "They’re a developer, this is code" without alignment 3. Sympathy Matching: "They’d care about users" without direct impact 4. Broad Benefit: "Everyone wants things to work" without specific need 5. Adjacent Feature: Persona uses X, issue affects Y nearby VALIDATION QUESTIONS before finalizing: 1. Would the matched persona say "Yes, this affects me!"? 2. Would they prioritize fixing this in their top 5 issues? 3. Does the match make sense to someone who knows the product? FINAL MANDATE: - Zero tolerance for generic matching - Every match must survive: "Would this persona lose sleep over this?" - When in doubt, NO MATCH is better than wrong match Return JSON in the format below: {"matched_persona_ids": [1, 3], "primary_persona_id": 1, "confidence": 0.0-1.0, "reasoning": "Overall rationale for matches", "persona_rationales": {"1": {"relevance_score": 0.0-1.0, "matched_goals": ["Specific goal addressed"], "matched_pain_points": ["Specific pain point addressed"], "use_case_fit": "How they would encounter this issue", "impact_level": "high|medium|low", "rationale": "Quote SPECIFIC goal/pain point from persona"}}, "analysis_notes": {"issue_type": "bug|feature|enhancement",
"technical_level": "beginner|intermediate|advanced", "urgency_indicators": ["Signs of urgency"]}}
B
Case Studies: PersonaFlow in Practice
To illustrate how PersonaFlow operates in practice, we present case studies from two participants drawn from our study. Each follows the study procedure described in Section 4: data preparation, initial reaction to generated personas, responding to an issue without and then with the persona context, and free exploration. We selected two contrasting cases: P3, who exhibited one of the most notable empathy shifts in our study, and P12, a veteran developer who was skeptical of the persona concept yet still demonstrated behavioral changes.
B.1
Case Study 1: P3 — SheetAble
P3 is a software developer aged 25–29 with 1–3 years of OSS experience, working with TypeScript on productivity tools. He had no prior experience with personas. B.1.1 Data Preparation. Prior to P3’s session, we ran PersonaFlow on SheetAble2 , described in its README as “an easy-to-use music sheet organizer for all the music enthusiasts out there.” PersonaFlow’s link discovery stage automatically identified and crawled the project’s homepage (https://sheetable.net/) from README links, adding context about the product’s positioning. PersonaFlow’s user insights summary stage identified four primary user types: musicians, music educators, tech-savvy individuals, and music students—noting that self-hosting created a barrier for non-technical users while offering privacy as a key motivator. The domain analysis then identified four key features from the README and crawled homepage: music sheet organization, user accounts and sharing (from the README’s mention of creating accounts for “friends or family”), cross-platform accessibility (from links to iPad and Android tablet clients), and self-hosting capabilities (from the homepage’s emphasis on easy installation “natively or with Docker”). The generated personas are presented in Table 3. The domain and user insights directly informed persona attributes: for instance, the sharing feature drove Priya Singh’s goal of collaborative learning; the cross-platform feature produced Carlos Rodriguez’s pain point about device sync; and the self-hosting emphasis shaped Akira Nakamura’s profile around data privacy. PersonaFlow also retrieved and mapped the 20 most recent open issues to the generated personas. Table 4 shows a sample of these mappings with confidence scores and AI reasoning. B.1.2 Initial Reaction to Generated Personas. During the study session, P3 explored all four pre-generated personas on PersonaFlow. He immediately noticed thematic overlaps: “Some of them share similarities... she cares about responsive use, he wants the access to be practical in laptop and tablet and this one too, he cares about mobile compatibility.” Despite these overlaps, he found the personas covered “realistic scenarios where this would be used.” He noted the age range could be broader (“It goes from 29 to 45, but I think it could 2 https://github.com/SheetAble/SheetAble
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
DIS ’26, June 13–17, 2026, Singapore, Singapore
Table 3: The four personas generated by PersonaFlow for the SheetAble repository (P3’s case study), from a single repository URL input without additional configuration. Persona
Role
Goals
Pain Points
Akira Nakamura, 34
Freelance Music Composer (Advanced)
Priya Singh, 28
Music Educator (Intermediate)
Carlos Rodriguez, 45
Orchestra Conductor (Intermediate)
Fatima Al-Shehri, 22
Music Student (Beginner)
• Organize large volumes of sheet music for different projects • Ensure data privacy through self-hosting • Facilitate collaboration with international clients • Distribute music sheets to students easily • Encourage collaborative learning through shared access • Simplify categorization by class and skill level • Quick access to sheets during live performances • Organize scores by composer and performance date • Streamline rehearsal preparations • Maintain organized digital library of practice sheets • Access materials on laptop and tablet • Track progress and manage practice routines
• Initial self-hosting setup requires technical troubleshooting • Difficulty accessing sheets during live sessions due to network issues • Lack of in-app collaborative editing • Initial tech setup for collaborative sharing • Cross-platform access inconvenient for students • Limited customization for student accounts • Sync issues across devices • Navigating app during live performances is cumbersome • Data loss concerns due to lack of automatic backup • Initial learning curve is overwhelming • Inconsistent UX across web and tablet • Limited offline access
Table 4: Sample issue-persona mappings for SheetAble, showing how PersonaFlow connects issues to affected personas with confidence scores and reasoning. Issue
Mapped Persona
#55 Chinese Composer and Sheet Name not supported
Priya Singh (Music Educator)
85%
#77 Limit on characters when inputting sheet and composer name
Akira Nakamura (Composer)
80%
#3 Add Search bar
Fatima Al-Shehri (Student)
80%
#41 Auto Scrolling Sheets
Carlos Rodriguez (Conductor)
80%
go even further and lower”). Based on the personas’ shared concern for mobile compatibility, P3 proposed a feature improvement: better responsive design for tablet and mobile access—demonstrating how personas enabled him to synthesize user needs into actionable development priorities. B.1.3 Responding to an Issue. The study issue was #77 (“Limit on characters when inputting sheet and composer name”), a bug where long text obscured the sheet thumbnail. P3 first responded to the issue without persona information, then revisited his response with the persona context visible. On the issue detail page (Figure 3, C), PersonaFlow displayed the mapped persona—Akira Nakamura, a freelance composer managing large volumes of sheet music for international clients. Baseline response (without persona, priority: 3/10): “Hi, Thank you for reporting this issue. I have a question concerning the issue that you came across. Is the text on top of the sheet the only issue that’s happening or also you having trouble visualizing the sheet itself, or other visual parts that are necessary. I assume that there is no limit enforced to the string for the name of the sheet and composer name...”
Persona-informed response (priority raised to 8/10): “Hi, Thank you for reporting this issue. I understand that you are having trouble with this because organization truly matters to you and you are dealing with many many sheets, and you also want to keep things smooth and have a nice user experience so that you can enjoy the experience with you or clients that you may have. I have a question concerning the issue that you came across... In any case, I can assure you that this issue will be soon solved and you are not going to have to deal with this pain anymore!”
Conf.%
AI Reasoning The issue of non-Latin character support uniquely affects users dealing with international music libraries. Akira’s persona specifically deals with organizing large volumes of music sheets and ensuring data is well-managed and accessible. The character limit issue aligns with his need for detailed organization. Fatima’s need for organization and seamless access to practice materials is directly impacted by the absence of a search bar. Carlos’s goals include efficient and reliable access to music sheets, especially during live performances.
P3 explained the shift: “I would just be more empathetic because I understand now organization is very important to this person.” He raised the priority from 3 to 8: “It would make me realize that many people care about organization more than they thought.” B.1.4 Free Exploration. During free exploration, P3 tested PersonaFlow with a second repository (Cal.com3 ), providing the project’s homepage URL as external documentation. He then explored various features of the tool. Editing personas. Using the edit dialog (Figure 2, C), P3 found adjusting persona location useful for matching a project’s user base. He requested conversational AI co-editing: “It would be even better if I could kind of interact with the AI, like not just give it data, but the AI to respond to me.” Separately, he suggested bias detection: “It would be nice if the AI could keep me non-biased... detect ‘I think you’re going out of context here.’ ” Merging personas. P3 selected two technology-oriented personas 1 with instructions and used the merge function (Figure 2, B, ○) to “keep it more software developer oriented.” The result was a “Technical Integration Specialist.” He noted: “If there are two personas that I really like, it would be nice to correlate them. And then I could use the edit to maybe remove things that I don’t want.” Issue browsing. P3 explored both the GitHub View (Figure 3, A) and Persona View (Figure 3, B). He valued the automated mapping: “It’s really good because that way I don’t have to go through 20 personas and then read each one—it would be a little bit annoying.” He emphasized the need for explainability: “What I would like to know is why this is a good match.” Analytics dashboard. The analytics view (Figure 2, D) drew P3’s most enthusiastic reaction: “The analytics part is probably what I like the most about the website.” He valued seeing issue distribution 3 https://github.com/calcom/cal.com
DIS ’26, June 13–17, 2026, Singapore, Singapore
across personas: “If I knew like 62% of the people have more issues in this side, then I would be like, OK, we’re having a lot of trouble in this side, so maybe we should focus a little bit more.” He requested additional features: time-series trends, absolute numbers behind percentages, and persona effectiveness scoring. Overall. P3 stated he would be very likely to adopt the tool: “I didn’t know personas were a thing... I’m happy. You kind of just taught it to me.”
B.2
Case Study 2: P12 — Ghostscript.NET
P12 is an independent consultant in his 50s with over 20 years of OSS experience. He is a veteran maintainer of Ghostscript, a legacy PDF/PostScript processing library. B.2.1 Data Preparation. Prior to P12’s session, we ran PersonaFlow on Ghostscript.NET4 , a .NET wrapper around the Ghostscript library. P12 later noted that this GitHub sub-project “is not particularly representative” because the main project uses its own Bugzilla instance with thousands of issues. The Ghostscript.NET README presented a more technical artifact, rather than user-facing documentation. PersonaFlow’s domain analysis identified five key features: GhostscriptViewer, GhostscriptRasterizer, GhostscriptProcessor, PDF/A-3 conversion, and XML invoice embedding. Notably, the README contained extensive PDF/A-3 conversion documentation with XRechnung and Factur-X e-invoicing code samples, which the system interpreted as a signal of business and compliance use cases. The user insights stage identified three primary user characteristics: developers (the library is “designed for integration into software applications”), business users (“PDF/A-3 conversion and XML invoice embedding aligned with business needs”), and system integrators (the ability to “run multiple Ghostscript instances simultaneously” suggested highperformance deployment scenarios). These artifacts directly shaped the generated personas (see Table 5). The e-invoicing code samples produced both Carlos Mendes (a fintech developer automating PDF/A-3 compliance) and Aisha Khan (a compliance manager concerned with international invoicing standards). The multi-instance capability generated Li Wei (a systems integrator deploying at government scale). The rasterization features, combined with issue reports about visual rendering problems, produced Ravi Patel (a graphic designer)—the persona P12 would later reject as misplaced for a developer-facing library, illustrating a case where the system’s interpretation of repository artifacts diverged from a maintainer’s understanding of the actual user base. PersonaFlow also retrieved and mapped the 20 most recent open issues; Table 6 shows a sample of these mappings.
Boniface Bahati Tadjuidje, Jin L.C. Guo, and Jinghui Cheng
users. A designer who does not create software... this user won’t report this kind of bug.” He identified the Li Wei persona (IT Systems Integrator) as more realistic: “The other person, system integrator, would be more relevant here.” He also dismissed demographic attributes: “What is the age of that person? Why the person is male, female?” B.2.3 Responding to an Issue. The study issue was #103 (“Missing elements/colors when converting PDF to image”), where PDF-toimage conversion via Ghostscript.NET produced visual artifacts while the command-line tool rendered correctly. The system had matched this issue to Ravi Patel (Freelance Graphic Designer) at 85% confidence. Baseline response (without persona, priority: “medium”): “Please provide the sample file. If possible, try to reduce the file size by excluding unaffected pages.”
Persona-informed response (priority: unchanged): “Please provide the sample file. As a workaround, use the command line conversion.”
Despite explicitly denying that the persona influenced him (“Absolutely not”), P12 replaced a technical debugging suggestion with a practical workaround. This change was triggered by the persona mismatch—because the matched persona was a graphic designer rather than a developer, P12 reasoned: “If somebody, if a graphic designer would report such a problem, there is a perfect workaround. Use the command line.” When asked about this adaptation, he reframed it as efficiency, consistent with his pre-existing technical orientation: “No, it’s not [empathy]. It’s about effective communication and reduction of time spent on a particular issue.”
B.2.2 Initial Reaction to Generated Personas. During the study session, P12 also explored all four pre-generated personas. His reaction was immediately critical: “Text generated by artificial intelligence... very little in common with real problems.” He articulated his own mental model of Ghostscript users as two groups: “Basically two groups of users: [those who] use software for file format conversion, and system integrators or professional users.” He specifically rejected the Ravi Patel persona (Freelance Graphic Designer) as irrelevant: “It’s completely misplaced because this .NET product is for developer
B.2.4 Free Exploration. During free exploration, P12 tested PersonaFlow’s generation on a second repository—Google’s OR-Tools5 — providing the project’s documentation URL as external input (Figure 1, B). He approached this as a self-validation test: “Let’s see if it can create a persona for me, as the user of this project.” Evaluating generated personas. On the persona cards (Figure 2, 3 P12 found some OR-Tools pain points resonant—“Cannot B, ○), directly define boolean expressions.” Those constraints matched his actual experience. However, he found others “absolutely irrelevant” (e.g., “limited access to real-world databases for testing”). He did not use the editing or merging features, instead suggesting the tool should support “nicknames for particularly notable users or groups of users” rather than synthetic personas. Issue browsing. When reviewing issue-persona mappings on the issue detail page (Figure 3, C), P12 dismissed the classification as too generic: “Yeah, that is 100% for everybody,” arguing that poor documentation affects all users, not just the specific persona matched by the system. He also identified a flaw in the AI’s reasoning: while the tool correctly matched an advanced researcher persona to an issue about missing advanced documentation, based on his experience, the project had no actual documentation whatsoever, making the match meaningless. Analytics dashboard. P12 acknowledged the analytics view’s (Figure 2, D) potential value but preferred real user data: “This may be useful, but... better if it is linked to real people with real names, real addresses, and customer numbers.” He suggested the tool should instead provide developer activity statistics from Git repositories.
4 https://github.com/ArtifexSoftware/Ghostscript.NET
5 https://github.com/google/or-tools
Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
DIS ’26, June 13–17, 2026, Singapore, Singapore
Table 5: Personas generated by PersonaFlow for the Ghostscript.NET repository (P12’s case study). Persona
Role
Goals
Pain Points
Carlos Mendes, 38
Senior Software Developer at a Fintech Company (Expert) Compliance Manager at a Multinational Corporation (Intermediate) Freelance Graphic Designer (Beginner)
• Reduce processing time by integrating Ghostscript.NET • Automate PDF/A-3 conversion for EU e-invoicing compliance • Leverage batch processing capabilities • Ensure digital invoices meet international compliance via PDF/A-3 • Reduce audit preparation time through automation • Facilitate cross-border e-invoicing within ERP systems • Streamline conversion using GhostscriptRasterizer • Ensure design integrity by viewing files before finalizing • Expand service offerings with document processing tools • Integrate Ghostscript.NET into government systems • Deploy high-volume processing without downtime • Ensure security compliance
• Compatibility issues with newer Ghostscript versions • Manual processing workload • Lack of real-time document processing • Lack of audit logs increases compliance reporting time • Need more intuitive tools • Compatibility challenges with legacy systems • Inconsistencies in document appearance post-rasterization • Limited support for new image formats • Complex setup processes • API rate limits impede synchronization • Complexity integrating with older components • Need more comprehensive documentation
Aisha Khan, 45 Ravi Patel, 30 Li Wei, 50
IT Systems Integrator at a Government Agency (Advanced)
Table 6: Sample issue-persona mappings for Ghostscript.NET, showing confidence scores and mapped personas. Issue
Mapped Persona
#30 Print big PDF dont work correctly
Li Wei (Systems Integrator)
90%
#103 Missing elements/colors when converting PDF to image
Ravi Patel (Graphic Designer)
85%
#30 Print big PDF dont work correctly
Carlos Mendes (Sr. Developer)
70%
Overall. P12 maintained his skepticism: “There is a way more important persona in the company: the boss.” He noted that site visits and direct client interaction remain the gold standard: “Developers may visit the user and vice versa.” Despite this, his behavioral change
Conf.%
AI Reasoning The issue directly affects Li Wei’s goal of deploying solutions for high-volume document processing without downtime. Ravi’s need to ensure design integrity by viewing files before finalizing is directly impacted by visual rendering errors. While Carlos is focused on efficiency and batch processing, this large-PDF issue relates to his document conversion workflows, though less directly than a systems integrator.
during the response task demonstrates that persona context can shift developer behavior even when the developer explicitly rejects the underlying concept.