第2章 用户场景采集方法：用户画像构建、场景卡片、典型用户故事
用户场景采集是PRD编写的第一个关键战场。没有真实场景支撑的PRD，本质上是「自嗨式产品设计」。本章围绕用户画像构建、场景卡片、典型用户故事三种核心方法，建立从「用户是谁」→「用户在什么情境下做什么」→「用户为什么做」的完整采集链路。
2.1 用户画像构建（Persona）
用户画像是目标用户的典型特征集合，它把分散的用户研究数据浓缩为一个可共情、可讨论的具体角色。画像是场景采集的起点——不知道为谁设计，场景描述就失去坐标。
- 人口属性：年龄、职业、地区、收入区间——决定用户的基本行为模式。
- 行为特征：使用频率、操作习惯、工具偏好——定义交互方式的选择。
- 目标与动机：用户想达成什么结果、为什么在意——场景价值的判断依据。
- 痛点与障碍：当前遇到的困难、效率损失、情绪摩擦——场景优化的突破口。
实践提示：一个产品通常需要 2~4 个画像，过多会导致场景碎片化。每个画像必须基于真实访谈数据，避免「编造用户」。
用户画像标准模板（推荐在PRD附录中交付）：
画像名称：运营总监·王强
人口属性：32岁 / 北京 / 硕士 / 互联网公司
行为特征：每天查看后台数据 3+ 次，依赖邮件通知
目标动机：及时定位异常指标，减少团队响应时间
痛点障碍：报表更新滞后，无法按需下钻2.2 场景卡片（Scenario Card）
场景卡片把画像放入具体的时间、空间、触发条件中，回答「用户在什么环境下使用、因什么事件触发、经历哪些步骤」。它是连接画像与需求的情境桥梁。
- 时空环境：办公室/路途/家中、网络状况、设备类型。
- 触发事件：什么信号让用户启动该行为（如：收到告警短信）。
- 使用流程：用户从触发到完成目标的关键步骤。
- 交互触点：用户与产品发生交互的界面/环节。
- 期望结果：用户认为「完成」的标准。
常见错误：场景卡片写成「功能清单」。记住——卡片里只能出现用户的行为和感受，不能出现「点击按钮A」「调用接口B」这类实现语言。
场景卡片模板：
场景名称：下班前批量审核工单
用户角色：运营总监·王强
使用环境：办公室内网，16:30~17:00
触发条件：收到每日待审汇总邮件
使用流程：
1. 打开审核中心，查看待审列表
2. 按优先级筛选，逐条确认
3. 批量通过，填写复核备注
期望结果：所有工单在 20 分钟内处理完毕2.3 典型用户故事（User Story）
用户故事用「角色 + 功能 + 价值」三元组表达一个独立的用户诉求，是PRD中最小粒度的需求单元。它直接映射到原型上的一个交互节点或功能点。
- 角色：对应一个用户画像。
- 功能：用户希望系统做什么。
- 价值：该功能带来的业务或体验收益。
- 验收标准：可验证的完成条件，是原型评审的检查清单。
需求拆解要点：一个场景卡片通常会拆出 3~8 条用户故事。每条故事必须独立可评估、可排期、可测试。
用户故事标准格式：
作为 运营总监·王强
我希望 按优先级排序待审工单
以便 优先处理高影响问题
验收标准：
1. 工单列表支持「紧急」「高」「中」「低」四级筛选
2. 默认按优先级降序排列
3. 优先级标签在列表页和详情页均可见2.4 三者对比与协同
三种方法并非替代关系，而是从不同抽象层级描述用户场景。下表梳理其核心差异：
| 维度 | 用户画像构建 | 场景卡片 | 典型用户故事 |
|---|---|---|---|
| 回答的问题 | 用户是谁？ | 在什么情境下？ | 要做什么/为什么？ |
| 抽象层级 | 高（角色特征） | 中（场景情境） | 低（具体需求） |
| PRD中的用途 | 背景说明、设计原则 | 流程描述、交互边界 | 功能规格、验收依据 |
| 典型交付物 | 画像卡片 | 场景卡片夹 | 故事列表 + 验收条件 |
| 与原型的关系 | 确定「为谁而做」 | 确定「页面流程」 | 确定「具体交互」 |
三者协同的采集流程：先构建用户画像锁定目标用户，再用场景卡片还原真实使用情境，最后从卡片中提取用户故事作为PRD的需求条目。每一次采集迭代都会反向修正画像的准确性。