前言
筆者以下欲分享在神達數位擔任使用者經驗研究員兩年以來規劃研究計畫的小小心得。本文章會著重說明在硬體開發的生態中，會需要考慮哪些事情，來決定需求的優先緩急與適當的規模，並了解該研究結果可以回答的範圍等等。文章內容較偏經驗談而非技術性指導。
筆者時常覺得研究員的工作就是一個攻城計，當接到一個研究需求的時，如何在一堆條件與限制下，運籌帷幄地想出一個最佳攻克的方法，一直是件很有挑戰也有趣的事。因此，了解一個方法的所能與不能是非常重要的，而同一個題目，解題的方式百百種！因此，若有不同的想法，請不吝指教。
這篇文章適合有實作經驗的人，尤其是在硬體產品開發中的各種限制下掙扎的人們！（笑）看了可能會很有感，但也非常適合想了解這個業界狀況的初心者，可以了解一下硬體廠的業界生態。
在此篇文章你可以暸解到：
在接到一個研究需求時，你的腦袋會爆炸般地需要處理哪些資訊？
在爆炸的過程中，要如何快速抓住該硬體產品的測試重點
針對定義好的測試重點，如何設計合適的測試內容？
本文
在接到一個研究需求時，你的腦袋會爆炸般地需要處理哪些資訊？
主要有以下三點：
產品線與其商業模式
專案資訊
設計端的產品資訊
在神達數位的組織編制下，使用者經驗部門屬於in-house的內部支援團隊，需要處理來自四面八方，不同部門單位所提出的研究需求。這些需求可能是來自不同產品線，各自會有不同的商業模式，這些都會影響到設計研究計畫時的佈局，因此掌握好與產品與專案資訊永遠都是必要的第一步。
一、 產品線與其商業模式
以神達數位來說，產品內容主要有強固平板、barcode掃描機、行車記錄器、自行車車錶、導航、車隊管理系統等等。這些產品有些是純硬體代工，有些已發展為成熟的企業品牌，如Mio專業導航與行車記錄器，清楚這些產品各自的商業模式能幫助了解研究設計的重點與限制。
B2B vs B2C的差異
依據產品的內容與特性，對應到的客戶、終端使用者會為大大不同。商用情境與消費端情境是完全不同的思考路線。
如強固平板、barcode掃描機、車隊管理系統是屬於B2B的產品，在特性上，接觸到終端使用者本身是件困難的事情。再加上，開發團隊口中的客戶很有可能是系統整合商，如果一開始沒有好好搞清楚，誤以為大家口中的“客人”是消費者，這會造成大大的溝通代溝，會覺得牛頭對不上馬嘴呢。
當客戶為系統整合商時，在執行研究上會有哪些有限制與困難呢？
最常見的狀況，像是無法確切了解產品的應用情境與用戶需求，或者產品定位上非常曖昧...。
一是系統整合商的客戶資訊都是屬於高機密的性質，如果系統整合商分享了太多他們的客戶資訊，難免會擔心上游廠商把這塊市場吃下來的可能性; 二是他們的客戶性質可能本來就很多元。
即使可以透過搜集一些二手資料窺探一下潛在目標族群與使用情境，但這些資料的範圍較窄與深度較淺，也難掌握資料的內容與品質。再加上競品的戰略與商業模式不一定相同，因此也無法保證類比的程度到多少。若要取得深入的資料，無非需要花費相當多的時間在蒐集資料上，或是購買價格昂貴的產業報告，這又要回到研究規模上的討論。
相對於B2B，B2C的研究在了解目標族群與使用情境上相對容易很多，招募使用者的管道也較多元以較容易，比較有挑戰性的地方是當面對跨國產品時，在研究設計上，都需要考量文化、國情、環境、政策、法律、人因上的差異與影響到研究內容設計的程度。
由於跨國研究需要花費高昂的研究成本，因此需要多加考量研究的成果是否符合效益。在這樣的前提下，更需要確認哪些關鍵因素會影響到是否能正確解答研究問題，哪些不是？有沒有在本國也能進行的替代方案？哪些部分是必須接觸到當地用戶，在當地的使用情境，才能有效回答研究問題？
釐清後，即可確認研究應如何設計與相對應的規模為何，並在報告說明此份研究的限制與適當的預期。
利用5W1H提問
在了解目標客戶、使用者與使用情境後，即可著手分析該項產品。你可以利用5W1H的方式，幫助自己組織一些初步問題。如：這個產品是什麼？（what）如何使用？(how)它的關鍵價值是什麼？(what)大家為什麼需要它？(why)誰會使用它？(who)在哪裡使用？(where)什麼時候需要使用？(when)
有了初步的資訊後，你可以進一步把5W1H切分地更細，也可以再把格局拉大，我建議詢問以下問題：
這個產品在該服務藍圖擔任什麼角色？“what is the big picture of this product?”
此產品使用的過程會包含哪些人？他們用來完成什麼事？誰是主要用戶？誰是次要用戶？
產品生態系的樣貌是？（搭配了哪些其他服務？軟體？硬體？）
以全貌觀的角度、使用者旅程的方式去思考產品可能地接觸點，慢慢地湊出整體全貌起來。當然以上沒有絕對的順序，找出適合自己的方式即可。
2. 專案資訊
以上是針對產品商業定位與用戶資訊做討論，接下來是針對內部環境的專案歷史脈絡，來了解如何判斷案子的輕重緩急、研究的著力點、該投入多少資源？
1. 你的專案團隊成員有誰？
在執行上，需要了解專案負責人是誰？（需求文件要起來！）有哪些關鍵成員（如當測試裝置有問題時，該找誰幫忙處理？想理解設計概念，要問誰？誰可以幫忙對接到客戶窗口？）、有哪些sku（了解產品的策略，或團隊目前有哪些因地制宜而不同的設計方針）、硬體規格（馬上了解這次要推的是高階還是低階產品）等等...。
2. 揭露內隱知識
透過關係利害人訪談與需求訪談，我們可以了解研究員在專案的定位與角色是什麼？團隊成員期待我們完成什麼事？或是站在我們的立場，去發現哪些事情需要團隊的關注。再來是很多關於專案的重要資訊，其實都沒有記錄在產品需求書上，因此....挖掘企業內隱知識implicit kowledge（挖八卦）是這個階段非常重要的事情。(帳面上的需求可能與實際需求不同...)
3. 對應到不同的開案原因，會有不同的研究處方箴
先前提到，UX team在神達組織內是內部支援型團隊，因此各個專案其實是既熟悉又陌生的存在。專案之間是不是有什麼子母關係？（產品迭代更新）或是某產品的延伸？（因應客戶新需求所做的accessory）增加業務銷售（使用一樣的placement做不同的外觀設計）還是針對新市場的開發（前無古人後無來者）？都會有不同的研究著力點，如以下：
產品迭代更新：需索取母層產品專案資料，了解版本差異，跟這些差異的原因是什麼？
產品應用延伸：了解原本產品的應用場景，思考兩個不同裝置的互動關係為何
增加業務銷售：了解專案框架，知道設計優化的幅度在哪
針對新市場的開發案：大展身手，是個提案做前期研究的好時機！！
專案開發的歷史變化可能朝令夕改，搞清楚發展的脈絡很重要，產品策略都可能因為技術限制、商業資源變化、公司經營方針的改變而有所軸轉。
3. 設計端的產品資訊
硬體廠開發流程主要分為以下不同幾個階段：product concept development、EVT、DVT、PVT到最後量產。依據不同的階段，研究需求跟著的不同，因此需要掌握好產品目前的開發狀況。
產品的開發階段
在產品在kick-off前，是屬於做前期研究的好時機，可以藉機釐清使用者需求與痛點、使用者旅程、機會點等等。產品kick-off之後，多以易用性測試為主，根據產品設計的成熟度來決定其測試重點，以概念發展階段來說，主要重點會是了解產品的概念模型是否與使用者的心智模式相同，白話文即此產品的操作模式能否被使用者了解。
等產品開發規格確認下來後，便會進入EVT、DVT、PVT的開發階段到最後量產。這些階段主要都是針對“操作上”、"performance"的易用性做討論。在產品上市後的階段，則注重後續追蹤，我傾向在研究規劃裡增加了解整體的服務流程體驗（以OMB做討論的話）、用戶喜好等主觀性回饋的比例，收集更多使用者對於產品印象的資料，增加更多市調的成分。
測試模型的成熟度
在不同階段，所拿到的測試材料的成熟度都不同。在早期產品概念發想時，設計師可能一次提出多種設計方案希望研究人員可以幫忙了解該設計的易用性。這時的測試素材通常是3D printing，這個材質本身不是那麼堅固，當拿來做一些細部的小零件時，很容易斷裂。
因此在這個階段，關注的易用性測試重點是“理解度”。研究人員需要妥善地分析產品的特性，了解要評估的易用性項目是什麼、是否有定義好的設計重點、設計師又透過什麼樣的設計手段達成？這個方法有效嗎？如何設計一個分析架構去驗證？此時的測試的結果，是為了學習與發現，引領下一次兼容並蓄的設計優化，並不是為了單單從A/B test中選擇一個較佳方案。
以硬體的A/B測試的性質來說，與其說是決定要採用哪個設計提案，我認為更正確的心態應該是“探索與學習”，應把測試結果視為探索性的資料，是用來發現足與不足之處，引發更多的設計思考去探索更多的解決方案，而不是拘泥在眼前的A案或B案。
此外，3D列印的品質粗糙，無法比擬產品的真實樣貌，測試內容也不適合收集關於視覺美觀的資料。在早期的設計階段，3D列印的模型也很難驗證到一些跟機構上有關的操作，如按鈕的回饋感、卡片插槽的使用等等。
到後期階段，易用性測試的目標會主要在於檢視performance，如使用上的效率、操作性、系統穩定度等等....。在EVT、DVT階段的working sample的模型成熟度也都不同，此時要再跟工程師與設計師，確認設計細節與預期的品質呈現。
結語：
介紹到這邊，希望大家對於硬體廠生態做研究所有大概的了解，，其實評估產品的易用性有非常多不同的方式，都有自己的優缺點 ，所以了解他們分別的特性並融會貫通的運用，是研究人員必備的能力之一。
針對初探此領域的研究員，如果不知道怎麼設計一個task analysis概念的測試計畫的話，可以先嘗試列出設想使用情境，如果還是很難想像的話，先把自己當為使用者，親自操作一遍。在過程中，一邊紀錄自己執行了哪些動作、有怎麼樣的思考、在過程中有哪些希望達成的目標，以user goal, task, sub task, action 的方式做層級分類。
希望關於如何判斷、釐清需求的介紹有幫助到大家，當然在執行中不是總是都那麼順利，因此最後來個精神勉勵。（下台一鞠躬）
“凡殺不死我的，必使我更強大。”
Comentarios