Kano模型是什么？五类需求、问卷设计与需求分析案例

Kano模型用于分析：同一个功能，在“提供”和“不提供”时，分别会怎样影响用户感受。它把需求分为基本型、期望型、兴奋型、无差异型和反向型，帮助团队发现必须补齐的基础能力、值得加强的体验，以及可能让一部分用户反感的设计。它回答的是满意度关系，不会自动算出开发顺序。

例如给会议工具增加“会前10分钟弹窗提醒”：主持人可能觉得有帮助，频繁参会的人却可能嫌打扰。只问“你想不想要提醒”很难看清差异。可以把正反两道问卷、用户分群和后续决策放进Boardmix在线协作白板，让产品、设计和研发围绕同一份需求证据讨论。

1. Kano模型是什么

基本概念：功能做得多，不一定更满意

Kano模型关注产品或服务的某个特性与用户满意度之间的关系。有些能力缺少时会引发不满，补齐后却只达到正常预期；有些能力越好越受欢迎；还有些设计本来没人期待，出现后才带来惊喜。把所有需求都当成“越多越好”，容易把资源放在不重要的细节上。

判断对象应具体到可理解的功能和条件。“提升会议体验”过于宽泛，“会议开始前10分钟出现一次弹窗提醒”才适合提问。分类还必须带上用户群、使用场景和调查时间，不能把某次调查中的结果当作功能的永久属性。

由来与适用范围

日本学者狩野纪昭（Noriaki Kano）等人在1984年发表的《魅力的质量与必备质量》中讨论了质量特性与用户感受的不同关系。今天，Kano方法也常用于服务和用户体验分析，而不只是产品功能清单。

实际应用不必先画复杂曲线。可以从一份Kano需求分类模板开始，先写清“哪类用户在什么情况下需要什么”，再把调查结果放入相应区域。

2. Kano模型的五类需求怎么区分

五类需求表达的是不同的满意度关系，并不是五档重要程度。尤其要区分“无差异”与“兴奋”：前者提供与否都没有明显影响，后者虽然不提供也能接受，提供时却能带来好感。

无差异型：有或没有，感受变化不大

这类功能对目标用户当前的任务影响很小。例如，用户主要关心是否能准时找到会议地址，对提醒卡片能否更换背景花纹没有明显偏好。它通常不宜挤占更重要需求的资源，但也要确认用户是否理解功能、是否真的属于目标人群，而不是看到“无差异”就立即删除。

反向型：提供反而可能让用户不满

反向需求意味着某些用户更偏好不具备该特性。强制弹出多次提醒，就可能打断正在专注工作的参会者。处理方式不一定是取消所有提醒，也可能是降低频率、改变触发条件，或允许用户自主关闭。要先找出反向反应集中在哪些人、哪些场景。

基本型：缺了不满，具备时视为正常

基本需求是用户认为理应做到的条件。例如，在一款会议预约工具里，已确认的时间和参会信息应当能够正常查看。满足基本需求未必带来惊喜，但缺失会破坏使用体验。涉及安全、隐私或必要合规的要求，也不能仅凭问卷中提及人数少就降低优先级。

期望型：实现程度与满意度较直接相关

用户能够明确比较这类特性，做得更好通常更满意，做得不足则不满。例如查找空闲会议室时，结果是否准确、响应是否及时，会影响完成任务的感受。真正要确认的是目标用户看重哪个维度，以及改善到什么程度有价值，而不是一味增加数量。

兴奋型：没有不苛求，有了会惊喜

某个用户原本没有期待工具能帮忙准备会议，却发现会前可以快捷看到上次未完成事项，可能产生额外好感。但这只是候选判断，不能由产品团队自行宣布它属于兴奋需求。同一特性对老用户可能是基本要求，对新用户可能是惊喜，也可能随市场普及而变化。

3. Kano模型能帮助决定什么，不能代替什么

对时间和资源有限的团队，Kano模型的价值在于拆开三个问题：哪些缺口正在损害体验，哪些改善能增加满意度，哪些新想法需要先验证。产品经理可以据此调整讨论顺序，而不是把会议变成“谁最想要哪个功能”的投票。

不过，满意度分类没有包含开发成本、业务目标、技术依赖和风险。同属期望型的两项需求，也可能一个只需调整说明，另一个涉及系统重构。应先保留分类结论与证据，再用成本、覆盖人群和依赖条件作取舍。

在白板上把需求卡片从分类区移到成本收益优先级矩阵时，保留原来的用户群、样本与反馈链接。不要只剩一张写着“兴奋型”的便签，就直接进入开发排期。

4. 如何用Kano模型分析需求：从问卷到决策

第一步：收集反馈，确定要研究的用户

结合市场调研、访谈、服务记录和使用反馈寻找候选需求。会议提醒的调查，可以先区分“经常组织会议的主持人”与“每天参加多场会议的成员”，记录他们当前如何避免忘会，以及提醒对工作有什么影响。

不要只邀请最活跃或最愿意配合的用户，再把结果推广到所有人。记录招募条件、样本构成和未覆盖的用户，后续才能判断结论适用于哪里。

第二步：把模糊诉求拆成单一特性

“提醒要智能、好看、不打扰”包含多个问题，应分别测试提醒时间、形式和关闭方式。本轮先限定为“会议开始前10分钟出现一次弹窗提醒”；不要在同一道题里同时增加短信、声音和自动打开会议，否则无法判断用户反应来自哪个部分。

第三步：对同一特性设计一对中性问题

正向问题问功能存在时的感受，反向问题问同一功能不存在时的感受。两题只改变该特性，其他条件一致：

• 提供时：如果工具在会议开始前10分钟弹窗提醒一次，你的感受是？
• 不提供时：如果工具不在会议开始前10分钟弹窗提醒，你的感受是？

两题均使用五个选项：喜欢这样、理应如此、无所谓、可以接受、不喜欢这样。先用少量访谈检查用户是否区分“理应如此”和“喜欢”，是否把“不提供”误读成“会议被取消”。不要用“这么方便的功能”或“错过提醒会很遗憾吧”等措辞引导答案。

第四步：按答案配对分类，再看分布

每位用户对同一特性的两道答案要配对查看。下表采用传统Kano评价表：A为兴奋型，O为期望型，M为基本型，I为无差异型，R为反向型，Q为需要复核的矛盾回答。Q不是第六种需求类型。该配对方式可见Kano模型实证研究及传统评价表。

行是“提供时”，列是“不提供时”的答案

提供时 ↓ / 不提供时 →	喜欢这样	理应如此	无所谓	可以接受	不喜欢这样
喜欢这样	Q	A	A	A	O
理应如此	R	I	I	I	M
无所谓	R	I	I	I	M
可以接受	R	I	I	I	M
不喜欢这样	R	R	R	R	Q

例如“提供时喜欢，不提供也能接受”归为A；“提供时理应如此，不提供就不喜欢”归为M。若两个相反条件都回答“喜欢”，先回查题目理解和答卷，不宜直接拿来支持产品决策。整理结果时同时保留各类别数量，不只留下最高的一类。

第五步：分群比较，再结合成本排序

会议提醒的20份问卷练习数据

用户群	A兴奋	O期望	M基本	I无差异	R反向	Q待复核
10名会议主持人	6	3	1	0	0	0
10名高频参会成员	1	1	0	5	3	0

如果只汇总两组，A最多，看起来值得增加提醒；分开看却发现，参会成员中有多人无感或反感。这时更有价值的下一步是访谈反感原因，比较可配置提醒与统一强制提醒，而不是直接把“兴奋型”写进需求文档。少量试填可以暴露问题，但不能据此宣称整个市场的偏好。

第六步：把分类结论转成可验证的开发决定

为选中的需求补齐五项记录：服务哪个人群、调查发现什么、准备做什么、暂不做什么、上线后检查什么。例如“先让主持人设置会前提醒；不默认对所有成员强制弹窗；评估提醒是否帮助到会，同时关注关闭原因与打扰反馈”。需求卡片还应关联负责人、依赖与验收条件。

可以在产品项目看板中跟踪这些任务，把原始调查摘要放在卡片附近。版本上线后重新观察用户反应；类别变化时回到需求分析，而不是一直沿用旧标签。

5. Kano模型适合哪些应用场景

• 产品开发和设计：在功能范围尚可调整时比较用户反应；先让用户理解候选方案，再调查，避免只凭功能名称作答。
• 市场定位和竞争分析：研究同一目标人群对不同方案特性的态度。它可以补充市场定位分析，但不能单独证明竞品整体更好或本品能获得多少份额。
• 产品线管理：比较基础版与扩展能力时，区分不同角色和购买条件，别把少数高阶用户需求强加给全部用户。
• 用户体验管理：把“体验差”拆成查找、等待、提醒和错误恢复等具体环节，结合实际行为确认哪个问题值得先解决。
• 市场推广与销售：用用户确实重视的特性组织说明，同时继续核对预算、购买权限和替代方案；满意不等于愿意付费。
• 服务与品牌管理：评估服务渠道、响应方式等可感知要素。对反向反应较多的项目，先查使用情境，不要直接给用户贴“不重要”的标签。

最终保留的不应只是一张分类图，而是一条能说清楚的决定：这个用户群遇到什么问题，问卷与访谈说明什么，团队因此选择了哪种方案，又准备如何验证。把这些材料放在同一画布，下一次需求评审才不必重新猜测当初为什么这样做。