第3章 用户场景识别与描述：从业务问题出发，撰写用户故事和场景卡片
KANO 模型对需求的分型——基本型、期望型、兴奋型——从来不是凭空贴标签，而是扎根于真实的用户场景。同一个功能“推送消息提醒”，在凌晨两点的值班监控场景中是基本型（缺失即事故），在周末休闲阅读场景中可能变成骚扰（反向需求）。脱离场景谈分类，无异于刻舟求剑。本章从业务问题入手，沿着“问题 → 访谈 → 故事 → 卡片”的路径，建立一套可复用的场景识别与描述框架，让 KANO 分类有据可依。
3.1 业务问题：场景识别的源头
用户场景不是凭空杜撰的剧本，而是从真实业务问题中“生长”出来的。业务问题通常来自四个渠道：
- 用户反馈与投诉：客服记录、应用商店评论、退换货原因，直接暴露用户未满足的期望。
- 数据分析发现：漏斗流失点、功能使用率骤降、任务完成时长异常，量化指标背后的行为断层。
- 竞品对比差异：竞品上线后用户流失、对标评测中的功能落差，提示未被覆盖的场景。
- 业务目标差距：转化率不达标、复购率停滞、NPS 得分低于行业线，指向现有方案与用户需求的脱节。
关键原则：一个合格的业务问题描述必须包含“谁 + 在什么情境下 + 遇到了什么阻碍 + 造成了什么影响”。例如：“仓库拣货员在高峰时段手持终端扫码，因屏幕反光需反复调整角度，导致单小时拣货效率低于基准线 18%。” 这样的描述才能直接导出用户场景。
3.2 用户访谈：从问题到场景的桥梁
业务问题只是“线索”，用户访谈才是还原场景全貌的核心手段。推荐使用 STAR 追问法 挖掘场景细节：
| 维度 | 追问示例 | 获取信息 |
|---|---|---|
| S（情境） | “当时您在什么时间、什么位置做这件事？” | 环境约束、任务触发条件 |
| T（任务） | “您本来想完成什么目标？” | 用户真实意图，而非操作步骤 |
| A（行动） | “您具体做了哪些操作？遇到了什么问题？” | 行为路径、摩擦点、临时方案 |
| R（结果） | “最后事情办成了吗？您感受如何？” | 满意度、情绪标签、期望落差 |
访谈避坑提示：避免直接问“您想要什么功能”，用户往往会给出“解决方案”而非“场景”。应聚焦于“您为了完成什么目标，在什么情况下遇到了什么麻烦”，让场景自然浮现。
3.3 需求拆解：从场景到用户故事
访谈素材需要提炼为结构化的用户故事。KANO 模型的优势在于，故事的语气词和动词会暴露需求类型。标准模板如下：
As a [用户角色]
I want [功能目标]
So that [业务价值]
示例：
As a 夜班值班护士
I want 在熄灯后能通过手环震动接收紧急报警
So that 我无需打开屏幕就能判断是否需要赶往病房基于 KANO 模型的用户故事属性映射表：
| 故事中的关键词 | 典型句式 | KANO 预分类 |
|---|---|---|
| “必须”、“不能”、“起码” | “我必须能在弱光下看清屏幕” | 基本型（Must-be） |
| “越…越好”、“更快”、“更准” | “我希望扫码识别的速度越快越好” | 期望型（One-dimensional） |
| “居然能”、“如果…就好了”、“惊喜” | “如果设备能自动切换为夜间模式就太好了” | 兴奋型（Attractive） |
| “无所谓”、“能也行不能也行” | “这个颜色换成蓝色也行” | 无差异型（Indifferent） |
常见误区：不要根据功能本身的“技术难度”或“创新程度”判断 KANO 分类。对资深用户来说是基本型的功能，对新手可能是期望型；同一个功能在核心场景是基本型，在边缘场景可能是无差异型。分类必须绑定具体场景，而非功能本身。
3.4 方案表达：场景卡片的结构化描述
用户故事适合快速沟通，但做 KANO 分类时信息密度不足。推荐使用 场景卡片 作为正式交付物，一张卡片对应一个完整场景。卡片包含以下字段：
| 字段 | 说明 | 填写示例 |
|---|---|---|
| 场景 ID | 唯一编号，方便追溯 | SC-003- 夜班报警 |
| 场景名称 | 动词短语，概括核心任务 | 熄灯后接收紧急报警 |
| 用户角色 | 谁在操作 | 夜班值班护士 |
| 业务目标 | 用户想达成的最终结果 | 在不打扰病房的情况下确认报警信息 |
| 前置条件 | 场景触发前的状态 | 病房已熄灯；护士佩戴手环 |
| 基本流（事件流） | 用户与系统的交互步骤 | ① 报警触发 ② 手环振动 ③ 护士抬腕 ④ 屏幕微光显示报警等级 |
| 扩展流（异常分支） | 常见的偏离路径 | 手环电量不足 → 转推送到走廊看板 |
| 后置条件 | 场景结束后的状态 | 报警已确认 / 已转交同事 |
| KANO 预分类 | 基于关键词初步判断 | 基本型（“必须能不打开屏幕就判断”） |
3.5 工作流总览：从业务问题到 KANO 分类
下图完整展示了从业务问题出发，经过用户访谈、场景识别、用户故事编写、场景卡片结构化，最终输出 KANO 预分类的完整工作流。每个阶段的产物都是下一阶段的输入，形成端到端的可追溯链路。
3.6 指标验证与验收标准
场景卡片中的 KANO 预分类仅为假设，需要进入验证环节。每个场景卡片应附带 验收标准（Acceptance Criteria），用于后续的指标验证：
- 基本型需求验收：用负面测试验证“缺失即不可接受”。例如：“当护士手环电量低于 10% 时，系统必须在 5 秒内将报警转推至走廊看板，且看板显示延迟不超过 2 秒。” —— 这条标准不通过，该功能直接判定为不合格。
- 期望型需求验收：用连续指标验证“程度与满意度正相关”。例如：“扫码识别速度从 1.5 秒优化到 0.8 秒时，用户满意度提升是否超过 0.3 分（5 分制）？”
- 兴奋型需求验收：用惊喜度测试验证“使用后是否产生积极情绪”。例如：“首次使用夜间模式自动切换的护士中，是否有超过 60% 主动在周报中提及该功能？”
指标验证三板斧：
① 覆盖率：当前场景卡片是否覆盖了该角色 80% 以上的日常操作？
② 一致性：同一场景下不同用户的描述是否指向相同的 KANO 分类？
③ 可测量性：验收标准中的数字（时间、百分比、分数）是否能在测试环境中真实采集？
① 覆盖率：当前场景卡片是否覆盖了该角色 80% 以上的日常操作？
② 一致性：同一场景下不同用户的描述是否指向相同的 KANO 分类？
③ 可测量性：验收标准中的数字（时间、百分比、分数）是否能在测试环境中真实采集？
3.7 交付物模板
本章的交付物为 场景卡片集（Scene Card Set），包含三部分内容：
| 交付物 | 格式 | 用途 |
|---|---|---|
| 场景卡片清单 | 表格（.xlsx / .csv） | 每行一张卡片，包含 3.4 节所有字段，供团队评审与追溯。 |
| 用户故事地图 | 看板 / 白板截图 | 按用户角色和操作阶段排列故事卡片，暴露场景覆盖盲区。 |
| KANO 预分类矩阵 | 表格（.xlsx） | 以“场景 ID × 需求描述 × 预分类”三列输出，直接输入下一章的 KANO 问卷设计环节。 |
// 场景卡片集示例（JSON 片段）
{
"sceneId": "SC-003",
"sceneName": "熄灯后接收紧急报警",
"userRole": "夜班值班护士",
"businessGoal": "在不打扰病房的情况下确认报警",
"precondition": "病房已熄灯；护士佩戴手环",
"basicFlow": [
"报警事件触发",
"手环振动（非声音）",
"护士抬腕查看",
"屏幕微光显示报警等级与房间号"
],
"extendFlow": [
"手环电量不足 → 推送转至走廊看板",
"护士未在30秒内确认 → 自动升级至值班主管"
],
"postcondition": "报警已确认或已转交",
"kanoPreCategory": "Must-be",
"acceptanceCriteria": "手环振动延迟 ≤ 2秒；看板推送延迟 ≤ 5秒"
}
实战建议：在首次构建场景卡片集时，优先识别 基本型场景 和 兴奋型场景 的两端——基本型场景的验收标准必须包含“零容忍”阈值，兴奋型场景的验收标准必须包含“主动正向反馈”指标。中间层的期望型场景可以在后续迭代中逐步细化。
至此，我们已经完成了从业务问题到场景卡片的结构化输出，每张卡片都携带了 KANO 预分类标签。下一阶段将基于这套卡片集设计 KANO 问卷，用定量数据验证预分类的准确性。