Putting a Face to the Issue: Fostering User Empathy of Open Source Software Developers With PersonaFlow
本文介绍了 PersonaFlow，这是一种从开源仓库制品生成可编辑用户画像的工具，旨在帮助开发者更好地理解用户情境，而针对 13 名开发者的研究表明，该工具通过情感联结和务实的优先级排序，成功培养了同理心并促成了更具用户导向的响应。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象你是一名志愿者消防员，服务于一个由全球人群共同建造共享房屋的庞大社区（这就是开源软件，或 OSS）。每天，你都会收到数百张从门缝下塞进来的纸条。大多数纸条是用一种奇怪的技术代码写成的：“门铰链偏差了 0.4 毫米”，或者“屋顶桁架的荷载计算有误”。
你非常擅长修复这些代码，但你常常不知道谁写了这张纸条。是一个试图挂画的孩子？一位试图保暖的祖父母？还是一位专业承包商？因为你只看到了技术问题，你倾向于把每张纸条当作一个需要快速解决的数学谜题，而不是一个寻求帮助的人在向你求助。你甚至可能会感到沮丧，并说：“去读手册吧！”却未曾意识到，写纸条的人可能从未见过任何手册。
这篇论文所探讨的问题正是：开发者正在失去与人的连接。 他们过于专注于“什么”（即缺陷），而忘记了“谁”（即那个人）。
解决方案："PersonaFlow"
研究人员开发了一种名为PersonaFlow的工具。你可以把它想象成一个魔法翻译器，它能将那些冰冷、技术性的纸条转化为带有“人物档案卡”的形式。
开发者不再仅仅看到“缺陷 #405：文本工具忽略首次编辑”，而是会看到：
姓名： 妮娜，一位市场经理。
目标： 她需要在 15 分钟内修复一张用于演示文稿的截图。
痛点： 她因截止日期临近而感到压力巨大，而这个缺陷正在破坏她的工作。
信心度： 85% 确定该缺陷影响了她。
该工具通过阅读项目文档和过往讨论，自动生成这些档案，并将它们附加到开发者正在查看的缺陷报告中。
工作原理（实验过程）
研究人员用 13 位真实的软件开发者测试了这一工具。他们要求开发者完成两项任务：
- 之前： 查看一份缺陷报告，并按常规方式撰写回复。
- 之后： 查看同一份缺陷报告，但这次附带了“人物档案卡”。
结果如何？
结果令人惊讶且温暖人心。
1. “面孔”效应：
大多数开发者改变了他们的回复方式。之前，他们的回复机械且技术化；在看到“面孔”（即人物画像）之后，他们变得有人情味了。
- 之前： “请提供日志。”
- 之后： “我理解这给你的演示文稿截止日期带来了困扰。这里有一个快速修复方案。”
2. 两种起效方式：
论文发现，该工具通过两种不同的方式发挥作用，就像两把不同的钥匙打开了同一扇门：
- 情感路径： 一些开发者产生了真正的情感连接。他们将“妮娜”视为一个拥有高压工作的真实人物，并想要帮助她。
- 实用路径： 另一些开发者并不在意“同理心”这一概念。他们只是将人物画像视为一种分诊工具。他们会想：“哦，这个缺陷影响了一群陷入困境的特定用户。我应该优先修复这个。”即使没有产生情感共鸣，他们仍然表现得更加友善，并优先满足用户的需求。
3. “信任但验证”原则：
开发者并没有盲目信任人工智能。他们像编辑一样行事。如果人工智能说“这是一位高级工程师”，但开发者知道他们的用户大多是学生，他们就会说：“不，那是错的”，并修正档案。该工具为他们提供了起点，但最终决定权仍掌握在他们手中。
核心启示
论文认为，开源社区中缺乏善意或理解，并非因为开发者是坏人。而是因为系统隐藏了真实的人。他们使用的工具（如缺陷追踪器）是为效率而设计的，而非为了展示谁受到了影响。
PersonaFlow 并非试图教导开发者变得更友善。相反，它重新设计了环境，使得人类背景无法被忽视。它为问题赋予了一张面孔，提醒开发者：在每一行代码背后，都有一个有着目标、挫折和截止日期的人。
一句话总结
- 问题： 开发者将缺陷视为数学问题，忘记了背后的人。
- 工具： 一个 AI 助手，为用户创建“人物卡片”，并将其贴在缺陷报告上。
- 结果： 开发者开始撰写更友善、更有帮助的回复，并根据谁在受苦（而不仅仅是代码有多“坏”）来优先处理修复工作。
- 教训： 你不需要强迫人们产生同理心；你只需要向他们展示问题背后的人性面孔。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。