第3章 Kano模型标识需求属性：基本型 / 期望型 / 兴奋型
需求优先级排序的常见困境是：所有干系人都认为自己的需求“必须做”，导致资源分散，核心体验受损。Kano 模型提供了一套可操作的需求属性分类方法，将需求分为三类：基本型（Must-be）、期望型（Performance）和兴奋型（Attractive）。本章将围绕用户场景、业务问题、拆解方法、优先级标识以及 PRD 模板展开。
3.1 三类需求的业务识别场景
| 需求类型 | 用户场景举例 | 业务问题 |
|---|---|---|
| 基本型 | 登录功能、支付成功、数据不丢失 | 不满足则用户直接流失，甚至引发投诉 |
| 期望型 | 搜索速度快、页面加载顺畅、筛选精确 | 线性影响满意度，做得越多好感越多 |
| 兴奋型 | 一键智能填充、离线模式、趣味动效 | 用户没预期，一旦提供则带来惊喜和口碑 |
关键认知：基本型是门槛，期望型是竞争力，兴奋型是引爆点。三种属性随市场变化会漂移（例如 5 年前的兴奋型可能现在是期望型）。
3.2 用户满意度曲线解析
Kano 模型的非对称满意度曲线是其核心工具。横轴为功能实现程度（不足 → 充分），纵轴为用户满意度（不满意 → 满意）。
- 基本型曲线：实现时不增加满意度，但缺失时满意度急剧下降。
- 期望型曲线：实现程度与满意度呈近似线性正相关。
- 兴奋型曲线：未实现时无感，实现后满意度陡升，且不设上限。
3.3 需求拆解与分类方法
采用问卷调研 + 功能卡片排序法对每个候选需求进行属性标定。每个需求需要从正反两个问题判定：
- 功能充分时用户感受？（喜欢 / 理应如此 / 无所谓 / 可以忍受 / 不喜欢）
- 功能不足时用户感受？（同上）
将答案映射至 Kano 评估表，得到每个需求的属性归属。具体映射规则可使用在线工具或以下简化版：
如果功能充分时用户选“喜欢”，不足时选“不喜欢” → 期望型（Performance）
如果功能充分时用户选“无所谓”，不足时选“不喜欢” → 基本型（Must-be）
如果功能充分时用户选“喜欢”，不足时选“无所谓” → 兴奋型（Attractive）建议每个需求至少收集 30 份有效问卷，用频次最高的属性作为最终分类。对于跨属性不明确的需求，可降级为期望型处理。
3.4 嵌入 PRD 的表格模板
在 PRD 中为每个需求增加“Kano 属性”列，并结合已有优先级标识（P0-P4）形成联合排序。以下为推荐的表格模板：
| ID | 需求描述 | Kano属性 | 优先级标识 | 满意度影响 | 备注 |
|---|---|---|---|---|---|
| US-001 | 用户登录后显示个人信息 | 基本型 | P0 | 缺失 → 满意度-80% | 必选，无容忍 |
| US-002 | 搜索结果按相关度排序 | 期望型 | P1 | 每提升10% → +5%满意度 | 可量化P0基准 |
| US-003 | 支持深色模式自动切换 | 兴奋型 | P2 | 提供后满意度+15% | 低开发成本优先 |
| US-004 | 支付失败后自动重试 | 基本型 | P0 | 缺失 → 满意度-60% | 需与后端联调 |
排序原则：P0 全部为基本型需求，P1 主要放置期望型（尤其是覆盖用户高频场景的），P2-P3 可包含少量期望型和部分兴奋型，P4 仅用于实验性兴奋需求。
3.5 指标验证与验收标准
- 基本型需求：验收标准为 100% 通过功能测试，且用户反馈中“无法完成核心任务”的投诉归零。
- 期望型需求：验收标准需设定量化门槛，如“搜索耗时 ≤ 1.5 秒（P95）”，并通过 A/B 测试验证满意度能否提升 ≥ 3 个百分点（NPS）。
- 兴奋型需求：验收标准为功能正确实现即可，但需要追踪使用率、用户主动提及率、社交分享率等指标，判断是否值得投入后续迭代。
避免将兴奋型需求列为“必须交付”，但也不要在 PRD 中完全忽略——应标记为“探索性交付”，并预留验收窗口。
3.6 交付物模板：PRD 中的 Kano 属性标识检查列表
每个版本 PRD 发布前，用以下清单自检：
- 每个需求是否标注了 Kano 属性？
- 所有 P0 需求是否均为基本型？如果不是，是否有充分理由？
- 期望型需求是否都有对应的定量验收指标？
- 兴奋型需求是否设置了灰度策略或最小可用范围？
- Kano 属性是否与满意度影响字段一致（如基本型缺失影响需标为红色）？
以上内容可直接复制至 PRD 的“需求优先级与分类”章节，作为团队统一认知的标准框架。