把狩野分析作為一種探索研究工具
在概念發展階段使用 KANO 狩野分析的經驗記錄
前陣子奉命探索在一個特別的群體中，是不是存在某個需求？
有趣的事情是，在確定需求是否為真以前，原型設計師就已經拿了一台機器來「土炮」了一下，甚至產出了一些對這個產品概念的功能假設，並實作出來了。
所以呢，是一個很大包的研究，上從需求探索，下至概念、規格與價格探索。雖然初期在規劃的時候，同時在思考是不是應該拒絕回答規格與價格面的問題，畢竟那已經超出質化導向的 User Research 能回答的問題。
但這個問題最後我放下了，原因是跟這個產品（含假設概念、規格、預計價格）是一個完全跳脫競爭者的戰場，我認為是可以回答的，這邊就不多談背後的脈絡，只是自清一下。
話說回來，所接下來的這個研究任務包含幾個面向，同時附上我們所採用的手法：
- 了解該群體的行為樣貌，以及對他們的需求假設是否為真？（訪談法）
- 該群體對我們提出來的功能假設的觀點是什麼？（KANO 狩野分析）
- 該群體是否能夠接受這樣價位的產品？（雙界封閉式詢價法 & 訪談法）
在這篇記錄中，我會著重在第 2 點，記錄下在這樣的情境下我們怎麼使用狩野分析，以及在過程前、中、後我留下來的反思。免得以後要再做一次同樣的雷又再踩一次：
前期準備：「盡可能的」精準傳遞概念
我認為這是我這次 KANO 中碰到最大的問題，我其實覺得我們已經解決得很不錯了（盡量了啦）。
為什麼這是一個大問題？
因為這是一個未上市的概念測試，換句話說，我們招募到的使用者「都沒有使用過這個產品以及他的功能」，當他沒辦法體驗到、使用到的時候，只能透過 KANO 的字面來理解設計概念並給予回饋的時候，非常容易發生以下這種對話：
User：「你這個功能可以 OOO 嗎？ 沒有的話我就覺得有沒有都沒差。」
或是
User：「你這個功能可以 OOO 嗎？有的話我會覺得很喜歡。」
如果是線下施測，那還能回答、追問、註記下這個問題；如果是在線上進行的話，這個問題就會「一個功能，各自表述」，相信研究員們都不樂見。
然而這個問題，只要我們是在概念階段使用狩野分析，就無可避免的一定會碰上，畢竟他對一個沒體驗過的產品，總會充滿疑問跟自我假設。
除了在線下施測來掌握狀況以外，我們怎麼處理這個問題？
說起來跟以前在應用劇本實驗室的工作經驗很有關係。在正式進入狩野分析以前，我們對受試者進行大量的溝通，做了很多「假的操作物」來跟受試者溝通這個全新的概念。
首先，我們讓受試者觀賞一部概念短片，讓他理解這個產品的整體概念為何。概念短片則是從 Youtube 上剪輯其他產品的 Demo Video，再加上自行配音、配樂、畫面合成，有了畫面可以讓受試者很快的對產品的輪廓、預計的使用情境有初步整體的認識，是很有效率的溝通方式。
**當然影片僅供研究使用，播放以前也會向受試者說明這是我們由其他類似的產品概念影片剪輯合成的，並不是我們自己的產品，也僅供這次研究使用。
當然這要考驗研究員的十八般武藝了，除非你很有資源可以讓設計團隊放下手上的其他工作來幫忙完成操作物（笑），在在體現研究員也要有一些基本的 Prototype、平面設計或動態剪輯能力，這次的概念短片可都是我自己剪輯配樂的（笑），還好去年有趁半價買了一年期的 Adobe。
當然並不是所有研究都可以剛好找到可以剪輯的 Demo Video，要看每個專案跟產品的特性，以及願意花多少功夫來後製而決定。
除了以 Demo Video 提供粗略的認識以外，我們也採用了「假的」產品介紹型錄，讓受試者在填寫狩野分析的表單時，可以拿著產品介紹型錄反覆閱讀對照。產品介紹型錄的角色就跟 Demo Video 亮點式的介紹不同，讓受試者可以更具體的確定、了解產品所提供的細節。
讀到這裡你可能已經發現一個問題：
既然都只是概念，能夠給得出這麼細節的產品資訊嗎？
答案是「不行」。
因為我沒辦法讓他看著一個固定型態的 Prototype，卻問他那你比較喜歡這個型態(眼睛看著的）或是那個型態（只能靠腦補的）的 Prototype，。
所以在規劃這一段研究的時候，我們是不斷的跟關係人討論和溝通，必須要確認這一個階段我只能盡量的把必要的、受試者一定會問的細節定義下來，然後蒐集受試者對這些內容的「想法」，但不推論為需求。（狩野分析不能推論需求，看這裡）。
當然，在概念階段其實還有很多手段來探測受試者對產品概念的想法，像是 Card Sorting、Focus Group 等都是可以採用的方法。
操作中 ：五個獨立的態度，而非五點量表
準備好素材以後，在前測（一定要做前測！）的過程發現一個狀況：
很多受測者「相當熟悉五點、七點量表」，當他看到量表最左邊是喜歡、最右邊是不喜歡，很容易反射的帶入五點量表的邏輯來回答，而忽略了狩野分析中的五個態度（I like it / I expect it / I am neutral / I can tolerate it / I dislike it）是互相獨立存在的，並不是一個程度的表現。
因為在前測的時候發現了這個問題，在後續每一次施測以前，會請研究員依據指導語的定義，仔細的跟受訪者解釋每一個態度，並舉一個例子來讓他理解。
**其實狩野分析的選項一直是相當有爭議的議題，一直有文獻在討論 Kano 的五項度是否合適，而有其他衡量向度出現，例如：Basic Needs、Satisfiers、Delighters (直接問法，Emery & Tian, 2002)；Satisfied、Neutral、Dissatisfied (問卷是否為 Paired Questionnaire 未知，Kano, 2001)。這裡我讀的文獻還很少，暫不採取這樣的方式，還是以最原本的 Kano 模型（五項度）進行操作。
資料回收後，資料能代表什麼嗎？
其實我認為還是不行的。
最主要的原因是樣本數有限。我所屬的產業是硬體設計製造，精模的成本、體積都相對高，每一次測試要帶著產品到受試者家訪談、評價，其實相當費力費神，一位受測者就會花掉半天時間，因此難蒐集到大量的樣本數。也因為是未上市的產品，沒辦法透過網路問卷大量的進行問卷發放，當然在開發階段所有 Features 未定之前，也不適合這麼做。
此外，畢竟這是一個 Prototype，而且有許多 Features 還沒被真正的確定是不是和測試階段看到的一樣，所以拿這些資料要來決定什麼，個人認為有些危險。所以在這次測試中，在受試者填寫完 Kano 的問卷後，研究員會針對他的答案逐一討論，著重在了解他對這個功能的看法好壞、用法，以及想像。
因此，個人認為在 Prototype 階段（尤其是硬體測試！），Kano 模型應搭配其他的方法使用，將重點放在數字背後的想法。
所以在這個階段，我其實傾向於把 Kano 定義為一種探索的手法，除了替開發團隊蒐集回對功能假設的看法以外，還能透過後續的訪談取得設計上新的發現。
兩個 Remind
- 一定要前測
盡可能減少所有的用詞（功能、選項）帶來的問題。 - 建議線下施測
因為未定論的產品有太多我們無法料想到 User 可能會提出來的觀點，線下施測除了能記錄、維持受試者對產品的想像，也可以適時的提問、後續訪談挖掘洞見，都是在這個階段應用 Kano 必要的過程。
