1. 一维模型
在过去我们对用户满意度的思考中，由于行业发展程度不足，对用户研究的深度和广度也不够，所以我们会倾向于认为用户的满意度与功能的完备程度是线性的，一维一次的，即：某个产品所具备的功能越完善越丰富，用户越满意；相反，功能越少，越不满意。
但事实似乎并不是这样，当越来越多应用变得臃肿、华而不实、全而无序时，我们发现用户们对「简洁」、「小而美」的呼声越来越高，此时一维模型基本上就无法再对真实的用户需求和满意度进行准确地描述。
2. 双因素理论
1959 年，美国心理学家赫茨伯格对企业员工对工作的满意度进行了一次深入的研究， 把影响员工满意度的因素分为两种：激励因素和保健因素。
保健因素的特点在于：如果没有，员工满意度会下降；但就算再努力改善，满意度达到一定程度之后也不会继续上升。它就好像基本工资，给全了你会觉得理所当然，给少了一定会觉得不可理喻。
而激励因素则呈现了另一种态势：如果没有，员工满意度也不会下降，但如果有，满意度则会持续提升，极大地激发员工的工作热情。它就好像奖金，给的越多越开心，谁不想说一句 “但他给的实在太多了” 呢？
3.KANO 模型
受双因素理论的启发，东京理工大学教授狩野纪昭博士 (Noriaki Kano) 提出了一套描述产品需求与用户满意度之间非线性关系的工具，并于 1982 年日本质量管理大会第 12 届年会上宣读了《魅力质量与必备质量》的研究报告，正式确立了 KANO 模型的基本型。
KANO 模型，翻译叫卡诺模型或狩野模型。网上摘抄到对它的解释大概如下：
对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。
不说那么抽象的，讲人话，就是一个帮助我们定义 “需求影响力” 的工具，通过定义评价的标准，来衡量每条需求可能对用户造成的实质影响。
KANO 中比双因素理论更进一步，定义了 5 个基本的需求模型，即魅力、期望、必备、无差异、反向型，通过一定的分析步骤对每个属性进行打分，最终搞明它属于哪一类型。
这么做的目的，是为了辅助我们更好的理解需求的有效用，为后续需求的优先级、工期、精细度安排做参考。
有了基本的概念，我们就要来详细了解一下 KANO 的具体原理了。
在 KANO 模型的理念中，产品功能、服务的完成度，与用户满意度的相关性并不完全一致，可能功能非常出色完善但用户并不买账，也可能做的非常简陋但是备受用户吹捧，以及其他一些可能更复杂的情况。
所以，KANO 定义了一个由功能完成度和用户满意度组成的 2 维坐标轴。
并在这个坐标轴中，通过一定的曲线、区域，来表达下面说到的五种需求类型：
魅力型A：提供了会让用户惊喜，但是不提供用户满意度也不会受到影响
必备型M：提供了用户满意度不受影响，但是没提供则满意度大幅下降
期望型O：用户非常渴望的功能，提供了用户满意度会上升，反之则下降
反向型R：提供了会导致用户满意度下降
无差异I：无论提供还是不提供，都不会有什么影响
我们可以在很多分享看到这些图例，但是要注意这只是一个对概念进行直观呈现的示意图，我们并不需要直接应用。
我们要先来理解一下，基础的五种需求类型都有什么特点。
魅力型（Attractive Quality）
魅力型的需求，是能让用户产生 “意外惊喜” 的东西。虽然没有这个功能也完全不受影响，但是提供之后会让用户非常的兴奋和满意。
比如在设计中常说的 “情感化” 设计，就是增加魅力型需求到产品中，通过一些有趣的交互、提示，来提升用户的满意度。
**
或者，像微信提供的拍一拍功能，没有的时候完全不受影响，但是诞生以后可以大大增加社交中的趣味性，提升用户的满意度。
**
期望型 (One-dimensional Quality)
期望型则是用户非常想要有的功能，通常是用户的主要诉求或痛点，如果没有得到满足，那么用户始终会觉得不够满意，或者认为被厂商忽视。
期望型需求另一个最大的特点就是，用户满意的程度与功能的完备程度大致呈线性关系，功能越是完备，用户越是满意，比较符合一维模型的描述。
例如使用支付宝进行公共交通的支付就是期望型功能，在它们还没上线的时候，用户有非常大的呼声希望扫码支付能得到统一的应用，所以在当时用户的满意度其实是不高的；然而当其逐步上线之后，我们会发现杭州用户和上海用户对此功能的满意度呈现不同的层次。
杭州作为阿里的快乐老家，大多数交通工具都可以直接使用支付宝扫码，而上海却需要通过一个 “中间商 “— 大都会，所以这个功能在两个城市之间完备程度的不一致，导致了两地用户对此功能的满意程度也不太一致。
**
必备型 (Must-be Quality)
必备型，通常是一个应用最底层的功能之一，是用户默认你应该具备的。例如聊天工具可以发表情，电商有购物车。如果这些底层的功能实现不符合预期，那么就会对用户的满意度造成极其负面的影响。
比如在线支付这个操作，我们默认所有主流支付渠道都包含了，但是京东、美团的支付选项中移除了支付宝，这对于相当数量的用户而言是不可理喻的 (同理淘宝不支持微信支付，两大派系的距离堪比生殖隔离)，尽管这很大程度上是由厂商之间的利益关系导致的渠道和数据垄断，而不是产品团队想不到，不过用户可不会管这些，没有就是没有。
无差异 (Indifferent Quality)
无差异，则是一些你做和不做，用户都一点也不在意的东西。可以说，它们就是 “无效需求” 的代名词。
这类需求常常来源于老板、产品经理拍脑门做的决定，或者用户反馈中没有虚无的建议和要求。
再有可能，就是紧跟潮流趋势做的功能，比如饿了么最近上线的 “真香” 频道，在一个外卖应用中上直播和短视频……
反向型 (Reversal Quality)
反向型需求，则是做了会起反相效果的需求，也就是让用户反感。
除了某些刚愎自用的决策者根据自己喜好添加需求以外，多数情况下是出于商业上的考量，为了促进转化或者流量强加给用户的一些功能。
比如 UC 这类浏览器不会老老实实的在首页放基础搜索框和收藏，而是一定要加入新闻流媒体来强制用户进行关注，而简单清爽的夸克近几年却屡受用户好评。
了解了这 5 类需求是什么，下一步，我们就要来熟悉应用它们的方法。
首先我们看看下面的表格，包含功能有或没有的复合表格，两个维度都包含了从喜欢到不喜欢的 5 个分数等级。
我们通过获取用户对有或没有的打分，来判断这个功能处于哪一个类型。当然，当调查访谈的用户数量较多时，是需要进行均值或加权计算的。
除了用这个表格记录外，KANO 还经常使用一个四分位 Better-Worse 系数坐标轴（奇怪的知识又增加了），通过对相关系数进行计算将需求置入对应坐标象限。
这个坐标相对于前面的表格来说，看上去更直观了，但是对横纵坐标的理解却要稍微拐个弯。横纵坐标之所以是百分数，是因为这两个值表达的是某一个需求的具备性对 better 或 Worse 评价的影响系数。简而言之，Better 的值越高，说明该功能的完备性对提高满意度的影响越大；Worse 的值越高，说明该功能的不完备性对降低满意度的影响越大。
而去获得坐标系对应数值的办法，也同样没那么讨喜。
这两个百分比要通过一定的计算来完成，公式如下：
公式了解下就好，只要知道在四象限应用中的原理就足够了，而不需要我们真的去进行这种计算。
既然两种方法各有优缺点，我们在实际应用中自然应该要做出一些有效的改良，即结合它们各自的优点，创建出一个新的，简化的坐标体系。
我们只要根据第一种方法的数值，将功能对应分配到这个列表中，就可以获得一个直观的需求影响力图表了。
同时，根据可视化的原理，对需求的其它权重或分类进行表现，例如该分值下的用户数，则使用点的大小进行区分，让图表可以更直观。
有了上面那张需求象限的点图，我们就可以来进行需求排序了。我在这里给出一种可行的优先级排序原则作为参考，在具体实践的过程中还需要大家发挥主观能动性，具体问题具体分析。
1. 类型优先级
这是非常符合直觉的排序，凡事总得打好基础，你才有辗转的空间去整一些花里胡哨儿的活，这一点想必不用我再赘述。只不过我们需要注意一点，反向型需求虽然它伤感情，但是有时候我们却不得不做，比如前面提到的 UC 首页的新闻流，所以我这里还是把它放了进来。
2. 频次优先级
在类型相同的情况下，我们需要另外增加一个纬度来判断其优先级 —— 用户诉求的频次。可以简单地理解为：频次越高优先级越高。
之前说坐标系中点的面积大小可以用来描述对此需求表达诉求的用户人数，那么自然点越大说明用户需求量越大，优先级也就越高，同时受调研的用户数量越多，此项也就越具参考意义。
但用户本身就是有权重的，目标用户的权重一定比其余用户的权重更高一些，他们的看法相对来说也就更加重要，所以在做用户调研和问卷的时候也要考虑到这一点。
3. 位置优先级
在某些极端的情况下，点的大小可能也会出现相似甚至干脆相同的情况，这就表明两个需求的优先级大体上不分上下，如果实在无法同时处理，硬要排个优先级出来，那从我个人的经验出发，我的建议是必备和期望型需求位置越靠右的先处理，而魅力和无差异型需求位置越靠上的先处理。
综上来说，我们可以利用 KANO 模型对需求进行一定程度上的优先级排序，但不管怎么说 KANO 模型仅仅只是一种参考，而不是真理。我们可以一定程度上考虑 KANO 模型的排序结果，但实际情况才永远是第一位的。
KANO 模型只是需求分析中的其中一个环节，用来帮助团队更好的理解需求的属性，但并不是代表需求的理解仅此而已。
同时，KANO 模型的可信度是建立在准确的用户打分之上，这是一个非常严苛的要求，不仅需要非常有效的实验、调研计划制定，同时受限于样本数会出现数据置信区间变大，置信度降低的问题，导致结果不堪用甚至无参考价值。
在以效率为导向的团队协作中，除非是非常重要的功能，否则使用用户画像、卡片等工具进行大致的推导即可。
KANO 的应用场景多种多样，需要大家根据实际应用场景进行调整。尤其对于设计师来说，KANO 不是一个我们教育 PM 怎么做需求的工具（某种情况下也不是不行），而是辅助团队对需求的影响力有清晰认识的方法，帮助团队做出更有效的决策。
若有收获，就点个赞吧
0 人点赞
