2020-11-12 資深UI設(shè)計者
翻譯：Grace Gogh 審校：冠男Ben | UXRen翻譯組 #343譯文
作者： cary-anne olsen-landis（前IBM Power Systems的經(jīng)驗研究主管）
原文標(biāo)題：《Kano Model — Ways to use it and NOT use it》
設(shè)計團隊為產(chǎn)品提出了一系列用戶需求。
開發(fā)（工程師）團隊帶著的不一樣的功能包來到會議桌前。
管理團隊只想留下那些能使公司盈利的功能。
運維團隊認(rèn)為需要優(yōu)化的功能則完全不同。
產(chǎn)品團隊如何知道該朝哪個方向推動項目？
作為設(shè)計研究人員，我們借助用戶的所言所行來深入閱讀并洞察他們的需求。但是，我們中的許多人都在努力尋找新方法來實現(xiàn)需求的可視化管理，以便和上述的跨職能團隊達(dá)成一致（拉齊認(rèn)知）。用戶當(dāng)然可以對功能進(jìn)行投票并對其進(jìn)行排名，這可以提供很好的方向，但這并不能給到更深層次的需求定義，即哪些功能是必須有的，而哪些功能是在期望之中的。
現(xiàn)在開始認(rèn)識卡諾模型。
圖1：狩野紀(jì)昭（來源： Mind the Product）
Kano模型是由Noriaki Kano教授在20世紀(jì)80年代提出的產(chǎn)品研發(fā)和客戶滿意度理論，將用戶偏好分為五類。它通過評估每種功能的2套衡量標(biāo)準(zhǔn)：滿意度和情感度，來提供幫助我們了解客戶對產(chǎn)品功能的看法。這2種衡量標(biāo)準(zhǔn)的組合形成五類屬性：魅力屬性、期望屬性（線性屬性）、無差異屬性（次要屬性）、必備屬性和反向?qū)傩浴?
設(shè)計一個調(diào)查問卷，并獨立列出每個功能。最好在可能的情況下通過原型或交互式線框稿來演示每個功能。你不必花太多時間進(jìn)行原型設(shè)計，這只是傳遞想法的原型。有些人甚至只展示原型的某處細(xì)節(jié)，可能是因為他們喜歡這個點子，但并不喜歡它的實現(xiàn)方式。
圖2：功能用圖片展示的例子
如果無法使用demo來展現(xiàn)功能，說明性文字也可以很好地發(fā)揮作用。
圖3：功能用說明性文字表示的例子
專家提示：與其他IBM研究人員討論時，比較成功的研究人員測試了15–20個功能。那些不太成功的則測試了30-40個功能。 測試20多種功能對于客戶和研究人員來說都已經(jīng)足夠多的啦（不建議超過20多個）。
看到每個功能后，用戶可以對卡諾問卷的進(jìn)行選擇回答：
（Daniel Zacarias對于如何清楚地編寫這些問題提供了一系列優(yōu)秀的建議）
針對上述兩個問題的標(biāo)準(zhǔn)Kano問卷答復(fù)為：
Daniel Zacarias還為答案集提供了其他一些選擇。基本上，如果您要嘗試使用卡諾模型，請閱讀他的整篇文章。太奇妙了。
Jan Moorman還建議添加第3個問題：此功能有多重要？
她建議使用“一點也不重要”至“超級重要”的9級李克特量表。但是，當(dāng)嘗試在李克特量表上闡明重要性的9個點時，這有點棘手。似乎7點的李克特量表闡明起來比較容易。
圖4：李克特量表的7級重要性
當(dāng)你找到答案，Daniel Zacarias會介紹詳細(xì)的分析過程。 我強烈建議您仔細(xì)閱讀。
IBM的研究人員發(fā)現(xiàn)一個問題：得到這些數(shù)據(jù)很棒，但是數(shù)字本身并沒有告訴任何人背后的原因，這是研究人員無法避免會被管理團隊挑戰(zhàn)的關(guān)鍵癥結(jié)。 一個團隊使用卡諾模型進(jìn)行了大約15次定性訪談。另一個團隊在從40個人中獲得問卷樣本后，又進(jìn)行了5次定性訪談。兩個團隊都強烈建議在此過程中添加定性訪談，因為它有助于補充上下文的定性數(shù)據(jù)支持。
IBM的某個團隊不愿再使用Kano模型。該團隊之前會使用場景描述（Scenarios）來代替功能（features）進(jìn)行調(diào)研問卷的設(shè)定，但是，在測試進(jìn)展中他們明顯發(fā)現(xiàn)設(shè)定的場景并沒有真實反映客戶實際使用產(chǎn)品的行為，最終導(dǎo)致測試失敗。
使用場景來展示功能的想法很好，但是當(dāng)我們在討論該方法時必須事先驗證。經(jīng)過確定現(xiàn)狀的生成研究后，卡諾+場景組合（kano+Scenarios）將會非常有力。
另一條建議是減少正在測試的功能數(shù)量。承擔(dān)了30-40個功能清單的測試團隊表示，如此多的功能測試太密集了。這會導(dǎo)致在測試結(jié)束之前，用戶不知所措，且疲憊不堪。
卡諾模型非常擅長對功能進(jìn)行優(yōu)先級排序?？ㄖZ模型的基礎(chǔ)理論是Daniel Zacarias提出的“喜悅的自然衰減”。創(chuàng)新的想法和產(chǎn)品總會從令人興奮的新穎功能（在Kano圖表的頂部：魅力）轉(zhuǎn)變成預(yù)期的功能（在底部：最好的必備，被貶損的，最糟糕的）。
利用卡諾模型獲得最佳結(jié)果（來源：UX Booth和Jan Moorman）
以無線互聯(lián)網(wǎng)為例*（靈感來源于參考文獻(xiàn)中Jared Spool的示例）。
假設(shè)時間回到了2001年，你此刻正出差在外，帶著一臺具有以太網(wǎng)端口和WiFi的筆記本電腦。當(dāng)你來到了酒店，發(fā)現(xiàn)有以太網(wǎng)端口可上網(wǎng)。盡管房費中未包含無線上網(wǎng)，但可以在商務(wù)中心使用WiFi。你此刻會很高興！感覺太奇妙了！這是很棒的選擇！
快進(jìn)到2017年。你正在出差，并攜帶配備WiFi的基本筆記本電腦。當(dāng)在酒店中，發(fā)現(xiàn)有以太網(wǎng)端口供連接Internet。房費中未包含無線上網(wǎng)，但是可以在商務(wù)中心使用WiFi。你真的會生氣！這家酒店是什么鬼，需要額外付費才能上網(wǎng)？！還有誰依然在使用以太網(wǎng)端口連接到Internet？
經(jīng)過了16年的發(fā)展，有些功能從最初的一種吸引人的功能（比如房間中的以太網(wǎng)端口，商務(wù)中心中的WiFi），變成了不受歡迎的功能。
如果團隊不了解客戶的需求，他們可能會專注于自己期望的功能，而不是極具吸引力的功能。使用卡諾模型的某IBM研究人員，在自己的團隊中指出了這一點：“團隊對某些功能感到非常興奮，然后意識到這些都是桌面上的賭注?！?
在討論卡諾模型時，我們認(rèn)為該模型還具有其他一些潛力：
痛點深度（Depth of pain points）
該模型有助于揭示現(xiàn)有痛點的糟糕程度?？ㄖZ問卷很容易用于研究，以深入了解為什么痛點如此糟糕，以及為什么這些功能對客戶如此重要。它可能會揭示一些以前無法確定的需求，并推動進(jìn)一步的創(chuàng)新。
基準(zhǔn)功能（Baselining features）
我們討論了使用卡諾模型作為功能的定期評估項目，以觀察哪些功能降為較低類別。這種具有足夠大用戶基礎(chǔ)的縱向測試可協(xié)助分析市場趨勢和期望，并有助于隨著時間的推移持續(xù)證明研究價值。它還可以幫助團隊了解他們的產(chǎn)品何時開始趨于平穩(wěn)，何時需要創(chuàng)新的想法來回到引領(lǐng)潮流的狀態(tài)。
有時，IBM的設(shè)計團隊會擔(dān)任某些項目的咨詢顧問。IBM的一些設(shè)計團隊被要求參與到某些項目中，以“梳理可用性”并在產(chǎn)品發(fā)布前滲入神奇的用戶體驗的“灰塵”。其他設(shè)計團隊則暫時參與到邊界更廣泛的產(chǎn)品團隊中。
在討論結(jié)束前，我們還有一個懸而未決的問題：如果無法影響產(chǎn)品決策，卡諾模型還有用嗎？你無法影響產(chǎn)品可能是因為該產(chǎn)品已經(jīng)在開發(fā)中，或是由于管理層的壓力，亦或是設(shè)計團隊只是該產(chǎn)品團隊的臨時成員等等。使用卡諾模型的努力真的值得嗎？
或者，即使不能影響產(chǎn)品，卡諾模型仍然可能有用嗎？
你有什么想法嗎？
在奧斯汀的IBM，一組設(shè)計研究人員會在每個月的某些時間共進(jìn)午餐以討論感興趣的研究主題。之后，在IBM Power Systems的研究人員會收集并記錄對話的重點。以上來自IBM Power Systems研究人員的午餐系列文章之一。
參考資料
藍(lán)藍(lán)設(shè)計( www.teruid.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)
文章來源：UX Ren 作者：寶珠
藍(lán)藍(lán)設(shè)計的小編 http://www.teruid.com