KANO 模型原型：五类需求定义
在数据产品原型设计的早期阶段，产品经理常常面对一个核心困境：同样是用户反馈的需求，哪些必须优先满足？哪些可以锦上添花？哪些甚至会让用户反感？KANO 模型为这一问题提供了经典的需求分类逻辑，帮助团队在有限资源下找到数据原型的功能边界。
1.1 用户场景与业务问题
假设你正在设计一款面向数据分析师的自助取数工具。用户提出：“希望增加实时数据预览功能”“导出格式支持 PDF”“页面加载速度更快”等一系列需求。如果没有分类逻辑，你可能会陷入“所有需求都要做”的陷阱。KANO 模型通过用户满意度与功能实现程度的关系，将需求划分为五类，让优先级排序有据可依。
业务关键点：数据产品的用户通常同时存在“快速完成任务”的实用需求和“操作愉悦感”的情感需求。两类需求在 KANO 模型中的位置差异巨大，直接影响原型边界决策。
1.2 五类需求定义
KANO 模型由东京理工大学教授狩野纪昭提出，将用户需求分为以下五个类型：
| 需求类型 | 核心特征 | 数据产品典型举例 | 满意度影响曲线 |
|---|---|---|---|
| 基本型 (Must‑be) | 不满足则极度不满，满足后满意度不会提升 | 数据查询不能超时；导出 CSV 格式必须正确 | 直线上升后趋于平缓 |
| 期望型 (One‑dimensional) | 满足程度与满意度线性相关 | 查询速度越快越好；可视化图表类型越丰富越好 | 线性增加 |
| 兴奋型 (Attractive) | 不提供不会不满，提供后满意度大幅提升 | AI 自动生成数据洞察摘要；一键分享仪表盘 | 指数增长 |
| 无差异型 (Indifferent) | 无论是否提供，用户满意度不受影响 | 更换主题配色；增加非常用图表类型 | 水平直线 |
| 反向型 (Reverse) | 提供后反而导致满意度下降 | 强制引导教程；加载广告弹窗 | 下降曲线 |
数据原型特例：基本型需求往往隐藏在用户“默认应该如此”的沉默中，需要通过用户访谈中的“负面追问”才能挖掘出来。例如问“如果查询结果需要等待 10 秒，你能接受吗？”
1.3 数据产品需求分类逻辑
在数据原型场景中，需求分类逻辑遵循“先基础后兴奋”的原则：
- 区分基本型：缺失会导致产品不可用，原型设计时必须包含最低可接受方案。
- 识别期望型：直接影响用户付费意愿或效率指标，原型中应提供可量化的优化空间（如响应时间、精度）。
- 发现兴奋型：通过用户访谈中的“惊喜话术”识别，原型阶段可只做概念验证或占位设计。
- 排除无差异与反向：利用 A/B 测试或用户反馈快速验证，避免原型资源浪费。
1.4 用户访谈与需求拆解
在数据原型边界确定前，通常采用“正反问题组合”（功能实现 vs 功能缺失）对用户进行访谈。典型的 KANO 问卷问题如下：
易错提醒：不要仅问“你喜不喜欢这个功能”，而要同时问“如果没有这个功能，你的体验会变差吗？”只有正反结合才能区分基本型与兴奋型。
- 正向问题：如果产品提供 A 功能，你的感受是？（很喜欢 / 理应如此 / 无所谓 / 勉强接受 / 很不喜欢）
- 反向问题：如果产品不提供 A 功能，你的感受是？（同上）
通过二维交叉分析，可以量化每个需求在用户群体中的分类归属，从而指导原型设计边界。
1.5 方案表达与指标验证
分类结果需要转化为可衡量的原型指标：
| 需求类型 | 原型阶段验证指标 | 验收标准示例 |
|---|---|---|
| 基本型 | 功能可用性（100% 通过） | 数据查询接口错误率 < 0.1% |
| 期望型 | 响应时间 / 完成率 | 90% 查询在 2 秒内返回 |
| 兴奋型 | 用户惊喜度调查（NPS 提升） | 原型测试中 ≥40% 用户主动称赞 |
| 无差异 / 反向 | 无指标要求或剔除 | 不进入 MVP 开发列表 |
交付物模板建议：在本章结束后，应立即产出一份《KANO 需求分类矩阵表》，按五类清单列出所有候选需求，并标明每个需求对应的数据原型交互边界（必做、可选、不做）。