第3章 用户场景建模与业务问题精确定义

3.1 用户场景：需求的原始土壤

用户场景是需求分析的起点，它回答“谁、在什么环境下、想达成什么目标、会如何操作”四个问题。脱离场景的需求往往是伪需求。

要素	说明	示例（在线问诊App）
用户	具有特定角色、知识水平和动机的人群	36岁宝妈，孩子发烧，焦虑，非医学背景
情境	时间、地点、设备、网络、情绪等外部条件	深夜23:00，家里，手机端，Wi-Fi，孩子哭闹
目标	用户在该情境下想达成的最终结果	快速判断是否需要去急诊，获得用药指导
行为	为达成目标而采取的关键操作序列	打开App→选择“极速问诊”→拍照上传症状→等待医生回复

3.2 业务问题：从场景到问题的转化

用户场景描述客观事实，业务问题则提炼出“现状与期望之间的差距”。使用三层过滤法从场景中剥离出真正的业务问题。

1. 现象层：用户在场景中遇到的表面障碍或不适（如“找不到夜间问诊入口”）
2. 问题层：现象背后的功能缺失或流程断裂（如“首页未区分急诊与普通门诊入口”）
3. 根因层：导致问题的本质原因，通常涉及信息架构、决策逻辑或资源分配（如“未根据用户紧急程度动态调整入口优先级”）

业务问题陈述格式：“当[用户]在[情境下]，因为[根因]，导致[问题]，造成[负面影响]。”

3.3 用户访谈：验证场景深挖问题

访谈是将假设场景转化为真实证据的核心手段。采用三段式结构，确保信息完整且不引导用户。

阶段	目标	典型问题
开场（5 min）	建立信任，说明背景，消除紧张	“今天想了解您平时如何处理孩子夜间发烧的情况”
探索（30 min）	还原最近一次真实经历，挖掘细节	“上次孩子发烧是几点？您第一反应做了什么？”
确认（10 min）	验证痛点归因，评估方案方向	“如果有一个功能能帮您30秒内判断是否去急诊，您会使用吗？”

3.4 需求拆解：从问题到RICE维度

拆解的目的是将业务问题转化为可评估、可排期的需求条目。每个需求从四个维度打分，避免凭直觉决策。

维度	含义	评估基准	分值范围
Reach（覆盖）	需求影响到的用户数量/频次	月活跃用户 × 人均使用次数	0.1 – 10
Impact（影响）	对用户核心目标的改善程度	极低=0.25 / 低=0.5 / 中=1 / 高=2 / 极高=3	0.25 – 3
Confidence（置信度）	对需求价值和效果的把握程度	低=0.2 / 中=0.5 / 高=0.8 / 极高=1.0	0.2 – 1.0
Effort（投入）	研发、设计、测试等全链路人月数	按实际估算，单位：人月	1 – 100+

需求优先级得分 = ( R × I × C ) / E 。得分越高，优先级越高。所有需求必须附带场景来源和问题陈述，否则不进入打分。

3.5 方案表达：原型标注快速验证

原型不是设计稿，而是需求沟通的载体。用低保真原型配合结构化标注，让开发、测试、运营在同一页面上理解需求。

1. 画布尺寸：手机端 375×812px（iPhone标准），桌面端 1280×800px
2. 标注位置：右侧或下侧留出标注区，与原型元素用虚线或编号关联
3. 标注内容：交互触发条件、数据来源、状态变化、异常处理、边界值
4. 标注格式：“编号 + 元素描述 + 行为说明 + 补充条件”

标注示例（线上问诊App 首页）：
#A1 元素：极速问诊入口按钮
行为：点击后跳转至“症状描述页”
条件：网络可用；用户未登录时先弹登录窗
异常：按钮置灰并提示“当前时段暂无医生在线”

3.6 指标定义与验收标准

每个需求必须有明确的可度量指标和验收清单，否则无法判断是否“完成”。

类型	指标名称	定义	验收阈值
效果指标	问诊转化率	从首页点击极速问诊到成功支付的用户占比	≥ 35%
效率指标	平均接诊时长	用户提交问诊请求到医生首次回复的平均时间	≤ 120 秒
体验指标	NPS（净推荐值）	问诊结束后用户评分 0-10，推荐者比例	NPS ≥ 40
质量指标	误诊投诉率	因医生建议错误导致的投诉次数 / 总问诊次数	≤ 0.5%

3.7 交付物模板与输出规范

本章所有分析成果应沉淀为结构化文档，便于后续章节使用和团队同步。

交付物	内容要点	格式建议
用户场景卡	用户画像 + 情境照片 + 目标描述 + 行为路径草图	1页/场景，Markdown 或 Notion
业务问题清单	问题编号、现象描述、根因分析、关联场景、预期影响	表格，CSV 或 Excel
RICE 打分表	需求编号、R/I/C/E 各维度分值、总分、优先级排序	表格，共享在线文档
原型标注稿	低保真截图 + 编号标注 + 交互说明 + 异常分支	PDF 或 Figma 分享链接
验收标准卡	指标名称、定义、计算公式、阈值、采集方式	1页/指标，共享文档