第2章 KANO模型基础知识

2.1 适用场景

KANO模型适用于需求分类与优先级排序的早期阶段，帮助产品经理、需求分析师和UX设计师区分不同类型的用户需求对用户满意度的影响。典型场景包括：

• 需求收集后分类：在产品前期，将原始需求映射到KANO类别，避免为“兴奋型”投入过多资源，或忽略“基本型”底线。
• 需求优先级争议：当开发资源有限时，使用KANO类别统一团队对“必需vs.亮点”的认知。
• 满意度驱动分析：用于衡量每个需求缺失时用户的不满程度，以及实现后用户的惊喜程度。

2.2 前置条件

1. 已完成初步用户需求收集（访谈、问卷、竞品分析等）。
2. 已定义目标用户群体（至少需要用户画像或典型用户角色）。
3. 团队对“满意度”和“实现程度”有基本共识（通常使用5级李克特量表）。
4. 准备KANO问卷模板（每个需求需提供正向/反向两个问题）。

2.3 操作步骤

KANO分类基于用户对每项需求在“有/没有”两个状态下的反馈，通过交叉表确定类别。共包含5种结果类型：

2.4 输入/输出物

2.5 责任边界

• 需求分析师 / 产品经理：负责问卷设计、数据收集、KANO分类计算、输出结果表。
• UX研究员：参与问卷用户筛选、访谈验证分类，确保用户反馈真实。
• 开发代表：提供技术可行性建议，特别是对“基本型”需求中的非功能需求（如加载时间）。
• 决策层：基于KANO结果调整产品路线图，但不得推翻分类结论（可由专家组重新评审）。

2.6 记录材料

分类过程需保留以下可追溯文档（建议使用共享表格）：

• KANO问卷原始副本（含正反题、用户ID、答题时间）。
• KANO分类交叉矩阵（每个需求原始得分 → 类别）。
• Better-Worse系数计算工作表（如果生成矩阵后使用系数）。
• 分类争议记录表：如果某需求的分类结果存在分歧（如两派意见），记录不同观点及最终裁定依据。

2.7 异常处理

• “基本型”与“期望型”混淆：重新审阅正反题组合。如果用户在“有”状态下给出4-5分，在“没有”状态下给出1-2分，则可能是期望型；若正反都是1-2分则可能是基本型。可增加一次用户深度访谈确认。
• 大量“无差异型”：检查问卷措辞是否过于模糊或用户群体不匹配。考虑更换样本或使用更细化的正反题设计。
• “反向型”需求占比过高：这表示该功能有明显的用户分群差异。应做用户子群分类，不可直接丢弃。若不可拆分，则标记为“配置型”并在产品中预留开关。
• 需求数量太大导致分类效率低：先人工合并同类项，再将模糊项放入下轮迭代；建议每轮不超过30个需求。

2.8 验收标准

1. 每项需求均被分配唯一的KANO类别（M/O/A/I/R），且无遗漏。
2. 分类结果与至少3名核心用户或领域专家的直觉判断基本一致（使用独立样本验证，一致性≥80%）。
3. 输出物表头完整，包含：需求ID、描述、类别、置信度（高/中/低）、备注。
4. Better-Worse系数（可选）已计算并附在表中，供后续价值矩阵使用。
5. 所有异常被发现并记录在争议记录表中，且有裁定说明。