你一定见过这样的场景：敏捷团队在冲刺中飞速前进，而“角色模型”（personas）却被遗忘在某个角落，干脆没有创建。以用户为中心的设计理念理想满满，却被两周一冲刺的节奏逼到墙角。但如果你可以同时拥有速度与深度呢？在“以用户的角度，我希望…”和“Sarah 需要这个，因为…”之间架起桥梁，看看你的用户参与度将如何提升，收入如何增长，用户流失如何消失。你的产品将变成用户生活中不可或缺的部分，而你也将成为实现这一切的关键人物。 

对于许多人来说，敏捷和以用户为中心的设计（包括角色模型）似乎难以兼容。然而，被誉为“Visual Basic 之父”、角色模型的开创者 Alan Cooper 指出，将以用户为中心的设计融入敏捷之后，其好处非常显著：

• 能将用户需求转化为可执行的需求。将原始反馈转变为精准叙述，开发团队可以真正使用，无需猜测用户意图，方向明确。

• 能消除一开始就浪费的工作。如果你真正理解用户所需，就不会构建他们最终会排斥的功能，避免了昂贵的返工和无效开发。

• 能桥接团队沟通鸿沟。当你、开发者、管理层和利益相关者有共同认知时，每个人都朝着同一个目标努力。

• 能释放更多时间专注于核心议题。UX 设计师负责用户研究和功能协商，开发人员可以专注于他们热爱的技术挑战——在会议中争论需求的时间减少，创造性的时间扩大。

• 能始终聚焦用户需求。在开发过程中，你会根据真实用户需求评估新想法，而非假设，从而构建对用户真正重要的解决方案。 

接下来，我们将探讨敏捷和角色模型为何不容易融合，以及如何解决这一问题。

敏捷与角色模型为何难以融合（以及如何修复）

敏捷强调速度，角色模型强调同理心。许多团队没能兼得这两者。

要让角色模型在敏捷中发挥作用，就必须把它当作一个“不断进化的活文档”，而不是一次性完成的研究项目。问题不在方法本身，而在团队如何对待角色模型。以下是让两者协同工作的关键方式。 

效率焦虑把用户研究边缘化

当两周一冲刺与数月用户研究发生冲突时，后者往往被抛弃。许多项目经理认为必须跳过角色模型，或者基于猜测草率制作角色——而传统的角色模型研究流程往往耗时：

• 进行几十次用户访谈的定性研究。

• 行为模式分析。

• 创建角色模型。

• 通过问卷调查进行定量验证。

他们担心深入研究会导致范围蔓延、错过截止日期，但跳过这一步，则让开发基于假设建造功能，支持成本攀升，用户转向更理解他们的竞争对手。 

William Hudson 提到，跳过这个关键步骤会带来严重后果。 

为什么角色模型能改造敏捷团队

角色模型将抽象用户具象化，避免代价高昂的错误，并帮助你交付真正有价值的产品。以下是它在不同阶段的价值：

初期阶段的优势

• 当用户故事变成“角色故事”时，它们更加有力量。比如，“Sarah，一个忙碌的妈妈，在通勤途中想快速保存晚餐食谱”比“我想快速保存食谱”更能激发设计与开发团队的同理心。

• 当高管提议添加 AI 聊天机器人时，你可以指出“我们研究的那位过载自由职业者角色更需要简单的任务组织，而不是更多功能”。真实用户研究胜过任何管理假设。

• 冲刺决策速度大幅提升。团队不再绕着用户偏好打转，而是直接查阅角色文档，清晰明确，去除猜测，加快开发。 

长期价值

• 从第一天起就构建正确的产品。如果在开发前先针对“技术焦虑的祖父母”角色发现静音按钮设计不清晰，就能避免后续大量支持成本和用户挫败感。

• 团队围绕共同理解达成一致。比如在评估音频压缩方案时，团队会谈论“通勤者 Maya 的需求”，而不仅仅是技术参数。

• 开发浪费减少。每个冲刺交付的都是用户真正提出的功能。转化率提高，支持成本下降，业务价值明显。 

在敏捷中实施角色模型：分步指南

下面是一套在敏捷环境中平衡深度用户洞察与速度的方法：

1. 在 Day Zero 之前开始（Start Before Day Zero）

Alan Cooper 提醒我们：“理清用户是谁、真正使他们满意的是什么，这些问题必须在第一天之前就回答。”在冲刺正式开始前，先进行必要的研究并构建用户直觉的基础。研究并不停止于冲刺开始，而是要持续。 

2. 让工程师与利益相关者参与用户研究

你的模型越多人参与创建，就越强大。工程师理解真实用户后，会从“构建功能”转向“解决人类问题”。高管看到用户真实困扰，也不会再推动毫无价值的功能。邀请团队共同参与访谈和观察，可以达到以下效果：

• 同理心取代假设：后台开发知道自己是为 “Maria，她在应用崩溃时失去销售机会” 去编码，而不是为匿名用户。

• 自然发生认同：团队更倾向支持自己参与制作的角色模型。

• 洞察力倍增：工程师可能发现研究者遗漏的技术限制。 

3. 创建“最小可行角色模型”（Minimal Viable Personas）

聚焦用户需求而非人口统计信息。一句“Jared 是个忙碌的家长，在步行去车上的路上 30 秒内点晚餐”比任何年龄、收入区间都更有指导意义。MVP 角色应仅包含必需信息：

• 名称、年龄等必要人口信息；

• 扮演的角色（如既是客户也是乘客）；

• 图片（真实或 AI 生成、与使用情境相关）；

• 核心目标、动机与行为；

• 简明使用情境、痛点等相关内容。

MVP 模型带来最大洞察，减少负担。 

4. 让角色模型无处不在

数字化整合使模型融入开发环境：在每个任务卡中附加角色模型标签，在 Wiki 或仪表盘中提供快速链接。实体存在也不可少：在团队空间张贴海报、制作与模型相关的杯子、鼠标垫等，甚至会议室中放入角色纸板，营造“用户参与”的氛围。每天谈论“这个功能如何帮助 Marcus？”让模型成为日常语言。 

5. 建立可持续的角色模型使用习惯

让角色模型成为团队日常习惯的一部分，而非边缘存在。在每日站会中以“这有助于 Sarah 更快保存食谱”为方式更新；在代码评审中考虑模型影响，“这一改动影响哪个角色？如何支持他们的目标？” 

6. 衡量角色模型的实际效果

通过衡量模型被提及的频率与使用情况来评估效果。定期（如每季度）调查团队对模型的帮助程度，统计哪些角色频繁出现在用户故事中，哪些被忽略。频繁提及的模型才是真正有价值的。 

在冲刺规划中让角色模型发光（Master Personas in Sprint Planning）

• 冲刺前规划：筛选待办事项时问自己：“这能帮助 Marcus 成功吗？”不能的话，考虑删除。角色模型应决定什么建、什么不建；避免处理边缘案例。

• 冲刺规划时：通过 Marcus 的体验来评估故事大小。例如：他在拥挤地铁上单手操作下拉菜单有多难？形成评估点；书写验收标准为情境形式，例如：“Marcus 通勤 7 分钟内创建发票”。情境驱动更有影响力。

• 冲刺看板结构：以 Marcus 的旅程地图组织看板，每张卡提醒团队如何改善他的生活；设立角色模型倡导者，让每个决定都考虑角色声音；让开发与设计/研究人员配对，共同理解用户，产生更具同理心的方案。

• 冲刺回顾演示：展示完整场景而非功能列表，演示 Marcus 如何使用解决方案，“离线优先，因为他常处于信号盲区”；跟踪重要指标（如生成发票时间、错误率、支持票等），真实成功意味着用户更成功。 

英国政府数字服务局（UK GDS）案例实操：让角色模型在敏捷中发挥作用

UK Government Digital Service（GDS）“服务绩效团队”就是一个成功范例，展示如何在敏捷开发中保持角色模型的活力与可操作性：

研究方式与角色开发

采用协作研究方法：团队研讨会、探索期和 Alpha 阶段的用户访谈、以及使用便签进行协作分析，而不是传统文档化角色。他们创建了一个核心角色 “The Conductor”（指挥者），代表那些需要跨多个服务审视政府服务绩效的用户。

创新之一是将用户需求格式化为标准结构：“作为指挥者（我们的核心角色），我需要一个跨政府服务的概览，以便知道重点在哪里。”他们还将需求分为三类：清晰表达的（explicit）、可观察但未表达的（implicit）、服务所需的（created）。 

用户需求层级结构

构建了三级结构来组织用户需求：

• 高层需求：“我需要理解数据，以免误用。”

• 中层需求：“我需要信任这些数据，以便支持我的决策。”

• 详细需求：“我需要知道数据有多可靠，以便在必要时提供免责说明。”

这个层级结构使团队更易识别需求间的关系，并更容易在冲刺中确定优先顺序。 

向冲刺直接转化，无浪费

GDS 表现出的关键成功因素是如何简化研究成果的整合方式。他们表示：“我们不做 PPT 也不做详细报告，我们将节省下来的时间用于更紧密地与团队合作。”他们通过协作便签会话，将“粉色便签上的角色与研究发现”转化为“橙色便签上的行动项”，并将这些内容纳入项目待办、冲刺计划和产品设计中。 

同时使用“亲和图”（affinity diagram）方法，将用户观察和引用群组化，帮助团队洞察用户行为、动机，并以此共建角色模型。 

将研究者嵌入团队中

GDS 让研究人员嵌入跨职能团队，而非在多个项目间漂浮。他们这样做能够：

• 成为塑造设计的一部分；

• 深耕产品或目标用户群；

• 成为敏捷团队中角色模型倡导者。

这确保用户需求持续被关注并影响开发决策。 

持续精炼流程

团队建立了系统流程，通过结构化的电子表格列出所有需求，并保持标准格式显示；定期组织团队研讨与协作分析，确保随着项目推进，对用户的理解不断演进。他们指出：“我们会持续使用（角色模型），直到公共 Beta，乃至我们对用户理解不断深化，确保始终满足他们的需求。” 

成效显著

这种方法带来了具体收益：

• 通过研讨达成一致理解，提高团队对齐度；

• 嵌入研究者带来更快的洞察支持与角色倡导；

• 研究成果直接转换为冲刺任务，具备可操作性；

• 系统组织清晰，需求关系明确，优先级明确；

• 团队在解读与解读含义上达成共识，决策协作更佳。 

总结：让敏捷与角色模型协同工作

当你在冲刺开始前先进行角色研究，并将其当作活文档持续更新，敏捷和角色模型可以完美结合—速度与同理心不必是对立，你可以用更短时间交付真正以用户为中心的解决方案。 

你的敏捷角色模型工具箱

• 从精简开始：创建最小可行角色（MVP）—带姓名、目标和行为即可，无需详细人口统计。

• 随处可见：在任务卡中加模型卡片，打印海报，站会提问使用角色名称。

• 定期更新：每次回顾时用支持票和用户测试得出新洞察来更新角色。

• 决策过滤：构建前问自己“这能帮助 Sarah 吗？”

• 测量影响：跟踪对话中角色提及频率、功能使用和支持成本变化。

转化你的冲刺

• 编写故事使用“Marcus 需要 X，因为…”而非泛泛“用户故事”。

• 将冲刺看板组织为角色旅程而非功能列表。

• 演示整个工作流，展示角色如何完成实际目标。

通过角色模型，你的产品将真正解决用户的真实问题。每一行代码都将改善某个人的生活。敏捷角色模型让抽象功能转变为真实的人类影响。