用户场景分析：用户故事、用户画像、场景卡片

数据产品与业务功能产品最大的区别在于：数据产品的交互是数据驱动的，用户与数据的每一次碰面都带有明确的决策或认知目标。因此，脱离用户场景定义的需求，到了原型阶段往往会被打回——因为无法验证“这个数据指标对用户到底有什么用”。本章聚焦于数据产品需求分析中的三大核心模型：用户画像、用户故事和场景卡片，并演示如何从人物洞察逐步演进为可落地的PRD需求。

1. 为什么用户场景是数据产品的基石

在真实的业务环境里，一位销售经理需要的不只是“昨日的销售额”，而是“如果华东区销售额下降了5%，我应该立刻知道是因为哪个品类、哪个SKU出了问题”。这种场景差异直接决定了原型中是需要一个静态仪表板，还是一个带有异常检测和归因分析功能的交互式数据产品。

2. 三大核心概念对比

在开始案例之前，必须先明确用户画像、用户故事、场景卡片三者之间的区别与联系。在数据产品PRD中，它们分别对应不同的颗粒度和产出物。

3. 真实案例场景：零售销售仪表板

我们继续使用第1章引入的“零售销售仪表板”案例。目标用户是区域销售经理 Alice。她每天早上8:30到岗，第一件事不是查看邮件，而是打开销售仪表板快速巡检昨日数据，为9:00的晨会做准备。

4. 构建用户画像

用户画像是场景分析的起点。一个优秀的数据产品画像应该包含以下维度：

• 基本信息： 角色、行业经验、技术熟练度。
• 数据行为： 使用数据的频率、最关注的数据粒度（日/周/月）、常用的分析维度（区域/品类/门店）。
• 决策场景： 战略规划、战术调整还是日常监控？决策的时效要求有多高？
• 核心痛点： 目前获取数据的方式（手工提取Excel？）、遇到的最大困难（数据滞后？口径不统一？）。

5. 编写用户故事

用户故事帮助我们将画像中的痛点转化为具体的功能诉求。标准的三段式模板同样适用于数据产品：

格式：作为【用户角色】，我想要【功能/能力】，以便【预期价值】。

示例：
作为区域销售经理Alice，我想要在登录仪表板后第一眼看到**销售额异常预警**，
以便我能够在晨会前快速定位问题区域，并准备好应对策略。

数据产品开发中的故事编写技巧：避免在故事中直接写UI细节，例如“我想要一个红色的按钮”。UI细节应该放在场景卡片或验收标准中。故事的核心是业务意图。

6. 扩展为场景卡片

场景卡片是用户故事的“升级版”。它将一句简短的故事，扩展为包含数据流、交互逻辑和异常处理的结构化文档。这是从“需求描述”过渡到“原型设计”的关键一步。

7. 需求映射流程

下面的SVG流程图直观展示了从用户画像到PRD需求的完整映射链路。该流程也是本章的核心交付思维：每一个原型交互都必须能追溯到具体的场景与故事。

8. 验收标准与指标验证

场景卡片中的预期数据展示和异常处理，将直接转化为PRD中的验收标准。以SC-001为例：

• 功能验收： 用户点击区域后，页面应顺利下钻至该区域下的品类列表，并自动按销售额降序排列。
• 数据验收： 仪表板首页加载时间不超过3秒；首页的KPI数值与数据仓库中T+1的汇总数据一致。
• 异常验收： 当后端服务返回HTTP 500时，前端应展示“数据暂不可用”的状态页，并记录错误日志到分析平台。

9. 交付物模板：用户场景分析画布

在PRD评审前，建议用一张画布将本章的所有分析工作汇总。该画布是原型设计和后续测试用例编写的核心输入。