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

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

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

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

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

换句话说，底不断我们缺少一种方法，做掌来帮助我们从用户感知的模型角度
，把功能分个类、排个序 
。这正是 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