本文共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:

1. If you had (feature), how do you feel?
2. If you didn’t have (feature), how do you feel?

看到功能之後，使用者可以在問卷上投票：

1. 如果有這個功能，你認為怎麼樣？
2. 如果沒有這個功能，你認為怎麼樣？

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:

1. Gauging the depth of pain points
2. Baselining features over a product lifecycle to assess the natural decay of delight over time

我們認為Kano模型還能做到以下兩點：

1. 抓住使用者痛點
2. 奠定產品生命週期的基準線，找到使用者對功能滿意度的衰減時間

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模型在使用者調研中的應用：客戶關係管理工具調研例項

完。