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