很多时候，产品经理都会被滚滚而来的各种需求淹没。到底哪些用户是用户真正喜欢的需求呢？哪些是一些伪需求，或者是负面的需求呢？这都需要产品经理对其进行斟酌与分辨。近日，NVIDIA高级设计师Brian O’Neill在Medium上发表了一篇文章介绍了一个非常有用的分析模型——卡诺模型（Kano Model ）。
假设你现在是一个新的应用程序Crunchrr的设计团队，该应用程序能帮助用户发现他们喜欢的谷物。
用户可以:
- 创建个人资料并与他人联系
- 根据他们的喜好来发现谷物
- 评价谷物（对谷物进行评分）
一些早期尝鲜者非常喜欢Crunchrr的核心功能。也就是说, 直到需求开始滚滚而来，一切都很顺利。
营销部的Annelise说:”Crunchrr需要一个地图视图, 这样用户就可以看到每种谷物的制作地点。现在人们对食物的来源非常感兴趣，所以这是必须的！此外，每个应用都有一个地图视图。”来自销售部门的Kevin在与一位潜在的广告客户会面时被问道：“聊天机器人在哪里？你不能没有聊天机器人。会话式的用户界面就是未来！”
你的一位早期用户给出了这样的建议：“应该有一个按钮，这样我就可以给麦片制造商发电子邮件，请求无麸质的版本。”另一个用户说：“也许可以有像Shazam（音乐识别应用）这样的功能。如果我在餐厅吃饭，我可以拍下一张别人正在吃的东西的照片，它会告诉我那是什么谷物。”
接下来的事情就显而易见了：你的待办事项列表里会有很多建议、需求和要求。似乎每个人都对下一个版本该怎么设计有一个绝妙的想法。
这是不可避免的。每个人都有自己的观点，只要有机会，他们就会表达出来。人们很容易就会陷入一种“越多越好”的心态。更多的功能等于更好的产品。
但是，你不能满足每一个请求。不仅如此，所有的想法都不是一成不变的，用户不知道该如何表达自己真正想要和需要的东西。另一方面，内部的利益相关者则倾向于在他们自身利益的狭隘背景下看待这些功能。你该怎样才能阻止这种疯狂呢？
“一个团队能的最重要的事情就是对几乎所有功能的想法说‘不’。”——Jared Spool
你需要一种方法，能够预测用户的满意度，能帮你考虑功能的优先级，甚至重新评估现有功能。你需要有确凿的数据来支持你的决定，比如Crunchrr应该在什么时候添加什么功能。这就是卡诺模型（Kano Model ）的用武之地。
卡诺模型
1984年，日本东京理工大学教授狩野纪昭(Noriaki Kano)提出了一种模型，可以预测人们对一款产品的满意程度。从那以后，卡诺模型就逐渐成为一种标准的设计工具，因为它能有效地使人们对一个功能或者想法的好坏做出评判。该模型的核心原则是，可以沿着五条截然不同的曲线绘制用户满意度。
曲线1：期望的功能
还记得我说的越多并不总是越好吗？不过，有时候的确是越多越多好。更大的存储空间或电池续航能力更好。更快的下载速度？更好。这些都是用户通常会有更高的满意度的例子，与他们得到的功能的多少成正比。
期望的功能，用户满意度与功能实现成正比
在Crunchrr的情况下，用户期望的功能可能是：
- 速度和响应速度
- 连接的用户数量
- 基于所述的偏好和过去的浏览行为的建议
- 快速找到一种谷物的选项（分类、过滤等）
- 可供选择的谷物种类的多少
曲线2：必需的功能
必需的功能是用户期望和理所当然的功能。
一旦基本需求得到满足，用户的满意度就会放缓。
当一个必需的功能不存在时，用户会感到不满意，而当它存在时，用户会感到满意，但到了一定的程度，用户的满意度水平就不再上升了。这是有道理的。如果一个轮子不转动，它会引起不满。如果它真的转动起来，它会让你感到满意。但是，很难让人对一个转得比较好的轮子感到兴奋。与大多数其他应用程序一样，Crunchrr也可能需要包含以下功能：
- 可靠的正常运行时间
- 搜索
- 能够创建个人资料
- 轻松登录/注销
曲线3：令人愉悦的功能
令人愉悦的功能可以让应用变得有趣，并赋予它个性化的功能。它是用户喜欢的，但不会期待或者必需的功能。它可以很简单，比如当你输入错误的密码时，登录框会晃动（摇头）。当然，它也可以是文字的基调，或者是一个有趣的吉祥物角色或一些独特的互动。
用户对令人愉悦的功能感到满意，但没有这些功能的时候，也无所谓，并不会感到不满。
此外，正如必需的功能一样，用户的满意度也存在限制。在某一点之前，这些功能不会有什么“收益”。
Annelise的地图视图可能是一个明显的例子，因为它不过是一种华而不实的东西，而且它肯定不能解决Crunchrr目前定义的任何业务需求。
令人愉悦的功能是用户体验的重要组成部分，不应该被忽视。但它们的保质期很长，部分原因是它们很容易被模仿。
比如，有一段时间，通过左右滑动进行互动是Tinder独特性的重要组成部分。现在，Tinder只是有这个功能的众多应用之一。换句话说，随着时间的推移，令人愉悦的功能可能会成为用户期望的功能，甚至是必需的功能。
曲线4：无关紧要的功能
这些都是用户根本不关心的功能。无论它们是否完全实现，都不会改变用户对应用的看法，也不会改变用户使用该应用的方式。
无关紧要的功能不会影响满意度。
曲线5:反功能
反功能是用户不喜欢的功能。（还记得Clippy吗？）这种类型的功能越多，用户的不满就越大。反功能就像一面镜子，与期望的功能相反。
反功能是让用户感到沮丧或烦恼的功能。其满意度与功能的实现程度成反比。
把它们都放在一起
将所有这些功能结合在一起，不仅提供了一个清晰的图形表示，可以看出特征是如何被感知的，而且还可以帮助你找出战略方向。
期望的功能：应该在这些功能上投入大量资源，因为它们是获取用户和留下用户的关键，同时也是竞争优势。
必需的功能：在基本的需求得到满足之前，应该投入大量资源，得到满足之后，就不用投入大量资源了。
令人愉悦的功能：在这里投入资源是可以的，但不要以牺牲用户期望和必需的功能为代价。不过，值得注意的是，令人愉悦的功能往往是建立用户忠诚度和口碑的关键。
无关紧要的功能和反功能：把资源投入在识别这些功能上，以免浪费更多的资源。
那么接下来的问题是：如何确定哪些功能属于哪个类别？毕竟，这是卡诺分析的切入点。
卡诺分析
想要确定哪个功能属于哪个类别，我们需要问我们的用户。但请记住，用户通常不擅长识别或表达他们真正想要和需要的功能。因此，卡诺分析需要通过成对提问来解释一个问题：一个是直观的功能问题，后面是一个功能障碍问题。让我们回到Annelise对Crunchrr的地图视图的建议。我们可以这样问一组有关这个功能的问题：
- 如果Crunchrr有让你在地图上看到每种谷物的制作地点的功能，你会感觉如何？
- 如果Crunchrr没有让你在地图上看到每种谷物的制作地点的功能，你会感觉如何？
对于上面的问题，用户必须选择以下答案之一：
- 我喜欢这样
- 我期望这样
- 我对此中立
- 我可以接受
- 我不喜欢这样
你可以为你的待办事项列表中的每一个功能都准备一份完整的问卷。然后，可以通过在下面这种表格绘制结果来分析每个用户的答案。
分析表会告诉你用户对每个功能的感受，从而可以得出在卡诺模型中哪个功能属于哪个类别。
应该清楚的是，如果当一个功能存在的时候，用户很喜欢，当其不不存在的时候，用户就不喜欢了，那么这就是一个用户期望的功能。当答案明显相互矛盾时，就会出现问题。（这通常代表着用户对这些问题不理解。）
好。我们快做完了。最后一项是汇总所有的调查结果，以对每个功能进行总体评估。（或者，你可以进一步细化，并根据不同的用户群体来对答案进行聚合。）
系数
在你汇总了所有的结果之后，就可以计算出满意度和不满意度系数了。满意度系数是一个介于0到1之间的数：越接近1，就代表该功能对用户的满意度影响越大。不满意度系数是一个介于0到-1之间的数：越接近-1，就代表该功能对用户的不满意度影响越大。我们用下面这个两个公式计算系数：
比如说，地图视图最后的调查结果如下：
- 期望:5%
- 必需:12%
- 令人愉悦:4%
- 无关紧要:23%
- 反功能:31%
- 相矛盾的答案:25%
这样就能得出以下结论：
- 满意度：（4+12）/（4+5+5+23）=0.2045
- 不满意度：（5+12）/（4+5+12+23）*（-1）=-0.3864
正如你所看到的，地图视图功能对不满意度的影响要远远大于对满意度的影响。这清楚地表明我们应该把它从Crunchrr中排除出去。对不起，Annelise！（实际上，如果你在现实世界中看到这些结果，你甚至不需要计算系数。看到31%的反功能和25%相矛盾的答案已经能说服你不加入这个功能了。我用这些夸张的数字来强调这些系数所产生的差异。）
有些时候，这些系数在对用户满意度的影响上几乎没有差别。像这样的案例需要进行进一步判断或重新测试。
结语
卡诺分析不仅成本低又易于执行，并为判断用户真正想要的产品功能提供了清晰的结果。它还提供了硬数据，让每个人都脱离了偏见或短视思维的陷阱。也没有必要大费口舌，与内部的利益相关方争论和讨论哪些功能是应该加入或排除的。数字不会说谎！
原文地址：https://medium.muz.li/the-kano-analysis-c16e7d681158
译者：chiming，由36氪编译组出品。编辑：郝鹏程
译文地址：http://36kr.com/p/5109573.html
本文由 @郝鹏程 授权发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
