在产品开发过程中，到能判我们经常会遇到一个看似简单却反复拉扯的底不断问题 ：

“这个功能，到底要不要做？做掌”

在产品层面，我们常会碰到“用户提了很多需求，模型但做出来用的个功人并不多”；

在设计层面，很多体验优化投入了大量精力 ，到能判却无法判断它们到底是底不断不是必要的；

在用户研究中
，我们能听到很多声音，做掌但很难快速判断哪些是模型“基本需求”，哪些是个功“惊喜附加”
，哪些其实“无关紧要”。到能判

换句话说，底不断我们缺少一种方法
，做掌来帮助我们从用户感知的模型角度
，把功能分个类 、排个序。这正是 Kano 模型所擅长的：它提供了一套从“用户满意度”出发的功能分类框架，帮助团队更清楚地知道——哪些是必须做到的底线
，哪些是值得打磨的加分项，哪些可以暂缓，甚至不做。

今天，我们来聊一个在用户研究与产品设计中都非常实用的工具——Kano 模型。

一 、KANO模型是什么？

Kano 模型并不是一个新概念 ，它的提出可以追溯到上世纪 80 年代。它的提出者是日本东京理工大学的教授狩野纪昭（Noriaki Kano） ，一位长期研究用户满意度与质量管理的专家 。

1. 诞生背景：从“质量”到“感知价值”

在那个年代，大多数企业对于“客户满意”还停留在“把东西做好”的阶段，但狩野教授提出了一个更深刻的问题
：

“同样的产品功能，不同用户对它的满意度是一样的吗？”

他的研究发现，用户对某个功能的感知
，并不是简单的“有就满意  、没有就不满意” 。实际情况远比这更复杂。有些功能是理所当然的存在
 ，一旦没有就引发强烈不满；而有些功能则是意外的惊喜  ，没有也不会介意，但一旦有了 ，会极大提升满意度。

于是，狩野教授基于对大量消费者满意度的研究 ，总结出了一种新的模型
，也就是今天我们所说的 Kano 模型。

2. Kano 模型的核心思想

Kano 模型的核心在于 ：不同类型的功能，对用户满意度的影响方式是不同的。

它将用户需求划分为五种类型：

简单理解
：基础项决定用户“不骂你”，期望项决定“喜不喜欢你”，兴奋项决定“会不会安利你” 。因此
，Kano 模型逐渐被产品经理、用户研究人员 、UX 设计师广泛应用 ，成为一个从用户视角定义功能价值的重要工具。

二、Kano 模型重要性

而 Kano 模型之所以能在用户研究中被广泛采用，不仅因为它提供了一种“功能分类”的方法 ，更重要的是，它帮助研究人员从用户满意度的角度 ，建立起用户需求与产品策略之间的桥梁 。

1. 为什么在用户研究中使用 Kano 模型
？

在实际调研中 ，我们经常会遇到这样的困境：

1. 用户表达出很多想法，用户什么都想要  ，但我们不知道哪些是“必须满足”的需求，哪些是“可选加分项”；
2. 团队希望更系统地判断不同功能在用户感知中的角色（如基础保障
   、满意加分 、无感存在），但传统问卷往往只能提供满意度的强度评分 ，缺乏将用户感知结构“类型化”的能力。
3. 高优先级的功能常常被主观判断或拍脑袋决定，缺乏用户视角的支撑。

Kano 模型可以有效应对这些问题
，让用户研究产出更具结构性与决策参考价值，它不是只看“用户要不要” ，而是看用户如何反应
，帮助我们把大量“用户想要的”功能做合理分类、分层投入。帮助用户研究人员挖掘“沉默的需求”与“伪需求”。

三、Kano 模型的落地

1. 定量问卷（适合功能归类与优先级排序）

Kano 原始模型推荐一套“双重问法”
：

通过将正向问题与反向问题的组合进行编码
，便可判断该功能在用户眼中属于哪种类型。

判断某个需求究竟是：

1. 是基础型需求：缺了会被骂，满足只是“不被批评”；
2. 还是期望型需求 ：直接影响用户满意度，是提升体验的关键；
3. 或是兴奋型需求 ：可打动用户 、形成差异化
   ，但不是必要项；
4. 抑或是无感/反感项：投入了也不一定产生价值，甚至适得其反。 。

适用于：功能列表明确
、样本量足够、希望做量化归类的项目。

2. 定性访谈（适合理解需求心理、补充洞察）

在定性访谈中，将功能放入真实任务场景中，引导用户表达对其有与没有的感受；分析用户的情绪反应词汇 、语气强度、对比陈述等  ，判断 Kano 类型；可作为定量结果的补充验证 ，尤其对“兴奋项”识别非常有效

示例提问方式：

“如果这个功能做了，对你来说最大的好处是什么 ？”

“那如果没有这个功能
，你会觉得会有多大影响？”

“有没有什么功能，你其实没想到，但用了以后特别满意
？”

访谈还原用户真实任务与心理模型 ，判断需求在使用路径中的“必要性”与“情绪阈值” 。

适用于 ：探索阶段、用户任务路径分析中 ，将需求放入上下文，判断其作用力与情绪反应  。

四 、误区与实践建议

误区一：用户说“重要”≠ 期望型需求

用户在访谈中经常会强调“这个功能很重要” ，但这并不意味着它是“越多越好”的期望型需求 。很多时候 ，这些“重要功能”其实只是基础项 ，是“不做会不满，做了也没感觉” 。

建议 ：

要结合“缺失时用户反应”判断真实属性；可使用 Kano 的“双问法”验证；搭配用户情绪词（如“必须有” vs. “我很期待”）区分基础型与期望型 。

误区二：模型适合所有功能评估

Kano 更适用于用户感知明确、易触达的功能，如：页面信息内容、核心交互操作、具体功能点等。对于功能过于底层或细碎 、感知微弱的点 、系统性能力  、抽象或宏观的体验指标
、未曾有过体验的高度新颖功能等
，难以直接归类。

建议
：

对抽象能力（如“平台安全感”）采用访谈理解其组成后再拆分评估，如根据访谈将其拆解成信息透明程度
、惩罚机制等 ，再将这些拆解维度对应成具体的功能点 
，再进行 Kano 模型构建；不建议将 Kano 用于隐性机制类（如推荐算法、系统响应时延）直接判断。

误区三 ：调研数据的归类就是最终结论

用户分布的 Kano 类型往往具有多样性与不稳定性，不能简单地看哪个占比高就下决策 ，需综合考虑用户价值、业务目标与实现成本。

建议：

引入加权判断（如核心用户 vs 泛用户；高转化用户 vs 普通用户）用 Kano 数据做优先级建议，而非单一排序；结合其他数据源（行为分析 、转化率等）辅助验证。

误区四：只在定量问卷中使用 Kano 模型

虽然 Kano 模型的经典方法是量化问卷 ，但在实际项目中，定性访谈+任务场景观察往往能更准确捕捉需求属性
，尤其适用于创新型功能或探索性场景。

建议 ：

将 Kano 框架嵌入访谈提纲 ：引导用户表达“有与没有”的态度对比；用情绪响应与使用路径判断功能类型；在无量化场景下，Kano 也可作为分析框架辅助归纳。

总结

Kano 模型不是代替用户调研的方法
，而是为用户研究注入了一种结构化的思维方式 ，让我们不再只是“收集用户声音”
，而是用用户的满意度逻辑去评估功能价值
，以数据支撑产品与设计的优先级决策。

作者：58UXD