本文共3424字，作者推荐阅读时间：7分钟。
以后我会不定期找一些写得比较好的产品相关的英文文章，并尝试翻译成中文。
P.S. 我英文从小到大都不及格，大学四级都没过，翻译都是我蒙的，添加各种二三四五次创作，各位凑合看，接受语法指正，不接受吐槽，谢谢~
原文：Kano Model — Ways to use it and NOT use it
The design team comes up with a list of user needs for your product. The engineering team comes to the table with a different set of features. The management team only wants the features that will make the company money. The support team sees entirely different features that need to be fixed. How is a product team to know in what direction to go?
让我们来设想一个场景：
设计：我们这边有一个新idea，了解一下？
程序员：吼！（却给出了一套完全不同的方案）
boss：只想要能给公司赚钱的feature，我们都做！
测试：......（对方不想嗦发，并甩给你一座由bug堆成的“小”山）
（站在各种feature的十字路口）产品经理：......（脸上笑嘻嘻）
As design researchers, we rely on what customers say and do to read deeper and discover what they want. However, many of us have often struggled with new ways to quantify and visualize those needs in an effective manner for these teams to come into alignment. Customers can certainly vote on and rank features, which gives a great overview, but doesn’t always give that deeper understanding of what are the must-haves over what is already expected.
Enter the Kano Model.
作为一个产品经理，我们往往需要从用户的“言”和“行”中深挖用户的需要(want)。但是，如何高效地量化、可视化需求调查结果，并统一各个部门的意见，这一过程总是让人头大。我们大可以选择简单粗暴的方法：让客户直接投票，根据得票数高低决定feature的先后顺序，方法虽好，但不是万能的，如果你想追问“必须有”和“已满足”功能之间的区别，就需要借助Kano模型了。
What is it?
The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories. It provides techniques to help us understand customers’ perspectives on product features by assessing two measures for each feature: the satisfaction and sentiment. The responses to these two measures will fall into one of the five categories: Attractive, Performance, Indifferent, Must-Be, Undesired.
Kano模型主要用于产品开发和客户满意度调查，在上世纪80年代由日本教授Noriaki Kano提出，他认为：客户的偏好应该被分为5种，分别是：
- 引人瞩目的，也就是兴奋型需求
- 期望型需求
- 平平无奇的，也就是无差别需求
- 必须的，也就是基本型需求
- 不受欢迎的，也就是逆向需求
并将两个维度（满意度和客户对产品的情感认知）引入客户偏好。
How to use it 怎么用？
Craft a questionnaire with each feature listed separately. For each feature, ideally you demonstrate the what the feature can do through a prototype or interactive wireframe, when possible. Don’t spend much time prototyping for this: it’s just a prototype to get the idea across. Some people can get really tied up in the details even in prototypes, because they may like the idea, but not how it was implemented.
在设计调查问卷的时候，要把需求功能清单掰开来设置问题。理想情况是：尽可能地把每一个功能到底怎么用的都用原型图实现出来就够了，不要为了实现某个功能点而去做原型，免得有时自己被原型的细枝末节绕进去了都浑然不觉。大家只是喜欢这个点子，而非实现点子的方式。
If it’s not possible to demo the features, an explanatory text description also works well.
如果实在没法实现一个功能，就用贫瘠的语言来描述吧，不碍事儿~
After seeing each feature, users select their response to the Kano questionnaire:
- If you had (feature), how do you feel?
- If you didn’t have (feature), how do you feel?
看到功能之后，用户可以在问卷上投票：
- 如果有这个功能，你认为怎么样？
- 如果没有这个功能，你认为怎么样？
Daniel Zacarias(硬广) has some excellent pointers on how to write these questions in a clear way)
The standard Kano questionnaire responses to both of the above questions are:
- I like it
- I expect it
- I’m neutral
- I can tolerate it
- I dislike it
标准的Kano问题回答只有这五种：
- 我喜欢！
- 我期望（就没这么喜欢了）
- 随意
- 不能忍！
- 讨厌！
Daniel Zacarias（硬广） also offers some other options for the answer set for these answers. Basically, if you’re going to try the Kano model read his whole article. It’s amazing.
Jan Moorman（硬广） also recommends adding a third question: How important is this feature? She recommends using a nine-point Likert scale of “Not at all important” to “Extremely important”. However, when trying to spell out the nine points on the Likert scale for importance, it’s … a bit tricky. It seems that the seven point Likert scale is easier.
Jan Moorman（硬广） 还提供了一些答案模板，如果你想用这个模型，一定要点这里，这位大姐姐还奇思妙想，加了第三个问题：你觉得这个功能重要吗？大姐姐建议用9分而不是5分来量化Kano的回答（这是要逼死强迫症的节奏），那我们还是走中间路线，7分好不啦？
Once you have the answers, there’s an analysis process that Daniel Zacariasdescribes in great detail. I strongly suggest you go read through that.
如果你有了答卷，Daniel Zacarias（硬广） 能告诉你如何分析。
One issue researchers at IBM found was that having these numbers were great, but the numbers themselves didn’t tell anyone why, the inevitable question we will all get from our management teams. One team used the Kano model to conduct around 15 qualitative interviews. Another team conducted 5 qualitative interviews after getting questionnaires from 40 people. Both teams strongly recommended adding qualitative interviews to this process, as it added the narrative that helps to give the data its missing context.
有了定量指标，是不够的，因为我们不知道为什么会有这个量，所以需要结合定性和定量的问题，一份问卷，两种问题，通过定性问题补全定量问题中缺失的语境和场景，才能把用户那不可言说的傲娇需要(want)给揪出来。
How to NOT use it 啥时候不要用？
One of the IBM teams who used the Kano model was hesitant about using it again. This team set up the questionnaire using scenarios they believed to be the current way things worked to describe the features. However, as the testing progressed, it became obvious very quickly that the design team’s scenarios did not reflect how customers actually used the product, and the testing derailed quickly.
其中一个团队用了一次之后就不太想用第二次了，因为他们在设计问卷时假设用户使用功能的场景和用户实际使用的场景，差了不止一点半点，场景失之毫厘，结果自然谬以千里。
The idea of using scenarios to describe the features is good, but as we discussed their approach, it became clear that scenarios must be validated beforehand. The Kano + scenarios combination would be powerful following generative research that establishes the as-is situation.
利用场景来描述需求是非常吼滴！但是我们必须验证我们所假设的场景是真实场景。“Kano模型+场景”的组合拳是非常有用滴！
Another piece of advice was to scale down the number of features being tested. The team that took on a long list of 30–40 features said it was a bit too intensive, and that customers got overwhelmed and worn out by the end of the test.
另一个温馨小提示：不要一开始就想搞个大新闻，弄个三四十个需求让用户填写，换你在两小时内填个问卷决定三四十个功能，你愿意？
Benefits Kano的好处都有啥？
The Kano model is very good at prioritizing features. A theory that underlies the Kano model is what Daniel Zacarias（硬广） calls “the natural decay of delight.” Innovative ideas and products move from being exciting and new, at the top of the Kano chart (Attractive) to expected features, at the bottom (Must-haves at best, detractors, at worst).
Kano模型是进行需求优先排序的利器，我们管Kano模型的理论基础叫“你就是这么喜欢给你喜欢的东西排序”的一套理论。需求点子和食物链一样，从Kano图里顶端的极具吸引力的功能，到食物链底端期望需求（你做得再好，也理所应当，你做得不够好，我就骂你）
上图来源&解释：Leveraging the Kano Model for Optimal Results (credit: UX Booth & Jan Moorman)
Take wireless Internet as an example*. It’s 2001, and you’re traveling for work, and have a top of the line laptop that has an ethernet port and WiFi. You’re at a hotel, and you learn that they have ethernet ports for you to connect to the Internet. They don’t have wireless Internet included in your room rate, but you can get WiFi in their business center. You’re stoked! It’s amazing! What great options!
我们就拿无线网为例，假设你回到2001年，出差的时候带了台Thinkpad，这台Thinkpad既有网线接口又有无线网卡，等你到了下榻酒店，你发现房间里面只有有线网，想要无线网？可以，你去楼下的商务中心，商务中心有WiFi，你心里面还在寻思：哇这酒店太高档了，商务中心竟然还有WiFi。
Fast forward to 2017. You’re traveling for work and have a basic laptop that has WiFi. You’re at a hotel, and you learn that they have ethernet ports for you to connect to the Internet. They don’t have wireless Internet included in your room rate, but you can get WiFi in their business center. You’re furious! What planet is this hotel from that you have to pay extra for Internet?! And who still uses their ethernet port to connect to the Internet anymore?
于是你由回到了2017年，你还在出差，带的还是Thinkpad，到了下榻酒店（酒店还是你当年的酒店，但Thinkpad已经不是当年的Thinkpad了）你发现房间里面只有有线网，想要无线网？可以，你去楼下的商务中心，商务中心有WiFi，你心里面在想：卧槽！这是火星搬过来的酒店吗？我得花钱才能用WiFi？不花钱只能用有线网？
What started out as an attractive feature (ethernet ports in the room, and WiFi in the business center), 16 years later turned into an undesired feature.
16年间物是人非，当年极具吸引力的需求到了今天，已经成了必须。
If teams aren’t clued in to what customers want, they could be focused on features that are expected instead of attractive. One of the IBM researchers who’d used the Kano model noted this on her own team: “There were some features that the team was very excited about, and then realized that those were table stakes.”
如果你还是摸不着用户想要什么需求，那你就关注用户想要的需求就好。
Additional Potential
As we discussed the Kano model, we theorized it has the potential for a few other things, too:
- Gauging the depth of pain points
- Baselining features over a product lifecycle to assess the natural decay of delight over time
我们认为Kano模型还能做到以下两点：
- 抓住用户痛点
- 奠定产品生命周期的基准线，找到用户对功能满意度的衰减时间
Depth of pain points 痛点有多痛？
This model could help to reveal just how bad existing pain points are. The Kano questionnaire easily lends itself to allow for research to dig deeper to learn more about why the pain points are as bad as they are, and why these features are so important to customers. It could unveil some previously unidentified needs and lead to further innovation.
Kano模型可以通过其问卷，帮助产品经理了解用户现有的痛点有多痛，并揭示为什么这么痛的原因。还有可能意外淘到用户自己都没发现的需求，有利于后期制定产品策略。
Baselining features 基准线功能
We discussed using the Kano model to assess features on a regular basis to observe which features were downgrading to lower categories. This type of longitudinal testing, with a large enough base of customers, could indicate market trends and expectations and help continue to prove research value over time. It could also help teams to know when their product is starting to plateau and are in need of innovative ideas to return to a trend-setting status.
Kano模型还能用来评估哪个功能已经逐渐降级为更低等的功能。这种纵向的评测应该基于充分调查相当数量顾客的基础上。评测的结果可以预示市场趋势和偏好，随着时间的推移，结果也可以反证评测的价值。Kano模型还能及时发现产品是否进入瓶颈期，需要活水源头，来一泄死水，树立新风。
Open Question 画上问号
Sometimes design teams at IBM act as consultants for projects. Some design teams at IBM are asked to come on to a project to “clean up the usability” and sprinkle the magical UX dust on a product shortly before launch. Other design teams are temporarily embedded on a broader product team.
商业吹捧IBM团队，不翻译
We were left with one open question at the end of our discussion: is the Kano model useful if you can’t impact the product? You may not be able to impact the product because it’s already under development, because of management pushback, because the design team is only temporarily part of the product team, etc. Is going through the effort of using the Kano model worth it?
最后，我们留个开放性问题：如果我们没法干涉产品，建立Kano模型还有用吗？
inspired by Jared Spool’s example (see below)
Resources 补充阅读
The brilliant Daniel Zacarias（硬广） has a complete explanation of how to fully implement and use the Kano Model, where he gives not only a phenomenal overview, but tools to tabulate as well.
Jan Moorman discusses her experience with the Kano model at projekt202
Jared Spool discusses the Kano Model at length:
Kano模型：一种产品经理适用的方法论
需求入门 － 用Kano模型来确定需求优先级
卡诺模型—设计品质与设计价值的思考
如何用Kano模型量化用户需求？
Tableau10分钟上手操作Kano模型
Kano模型在用户调研中的应用：客户关系管理工具调研实例
完。