B2B 企業研發團隊 - C 單位

專案背景

合作團隊是企業內部的研發單位，主要的客戶是企業 (2B Model)，因應企業用戶需求，開發給 End User 使用的產品。

合作團隊內部無使用者調研部門，過往缺乏接觸使用者、從使用者的角度重新認識問題的經驗。

預計展開為期四個月的合作專案，完成由假設釐清到產品驗證的設計思考流程。

團隊的挑戰

C 單位的產品即將進入下一個世代的開發階段，因此提出了合作的建議。以往在這個階段，常常以商業客戶的猜測或者業務的直覺當作開發基礎，再由研發團隊拍腦袋想出相應的功能。我們將此階段的目標重新定調為「我們如何認識終端使用者的真實需求，發想出過往未曾想過的新功能？」

為了打造能讓終端使用者真正喜愛的產品，本次希望透過將使用者調研的流程融入開發歷程，並改善下述問題：

客戶企業或業務對於「用戶需要什麼」，或許包含了真實需求以外的目的，造成產品開發完成後用戶使用率低或體驗不佳。

團隊只基於業務的「意見」進行發想，疏於理解使用者實際的情境和脈絡，因而在開發期間疊加了許多對使用者而言沒有意義的功能。

缺乏使用情境代表缺乏開發的細節，便加深了溝通的模糊性，拖慢開發時程。

產出

回應挑戰時，我們不只帶著合作對象經歷方法論和工具的操作，也會分攤使用者調研歷程中的麻煩事，確保客戶用最有效率的方式獲得使用者洞察。

建立三輪發散收斂，結合假設釐清、使用者調研及功能驗證的內部開發流程

三大主要使用情境及痛點（包含 Personas+Customer Journey Map）

兩個經過使用者測試的新功能（包含 Prototype 及完整測試流程）

一份整合專案經驗及學習，用於內部提案及教育訓練的結案報告

我們如何協助客戶

建立對使用情境的假設｜

企業內部的部門分工明確，在產品開發流程最前端的研發部門往往肩負打造出貼近使用者需求的產品這樣一個重責大任，卻又是離最終使用者最遙遠的角色，往往依靠「想像」進行產品開發。本案在實際進行使用者調研前，先帶領客戶進行了一輪內部的發散和收斂，釐清現有對目標族群的想像，幫助團隊建立「假設」，才能藉由後續的流程驗證。這是將「想像」變為「學習」的第一步——團隊對於使用情境的瞭解深度，會來自於假設與驗證結果之間迭代的次數。

經由使用者調研快速驗證假設｜

企業客戶往往會考量「規模」或「商業價值」而提出過於籠統的使用情境，本案也是如此。Ｃ單位一開始的預設是將最常發生、使用者數量最多的「通勤」作為最主要的商業機會。然而實際經由使用者驗證後，確認了「通勤」作為一個最常見的情境，用戶的主要目的通常已被現有的解決方案達成，「省時」、「安全到達目的」等基本需求非常強烈，以致於對於魅力型的產品功能的需求較弱，也未見極端使用者能提供開發洞察。

跳脫發想與評估同時進行的陷阱｜

Ｃ單位過去礙於時間及成本有限，往往急著找到方法解決問題，因此常進到「發想與評估同時進行」的狀態，大大降低了發想階段的效能與解方的品質，納入許多現階段其實不必考慮的限制和舊思維框架。我們在解方發想工作坊中，帶領對方認識「如何發想」並建立適合專案的發想框架，透過辨識 Point of View ( POV ) 及 How Might We 問句 (HMW)，一同展開專案問題切入點，拓展解方數量及多元性。

有系統地測試驗證｜

過往測試產品功能時，多半只是希望知道使用者喜不喜歡、想不想用。不過本次經完整的使用者調研歷程，有了清晰的情境和需求脈絡之後，在產品功能的驗證上可以有系統地從「需求情境的細節」、「辨別核心及次要功能」、「為用戶創造價值的關鍵因子」、「既有替代品的優劣」、「用戶的價值觀」等角度個別切入——花下的每一分測試時間，都能提升團隊對產品和用戶的理解，提高開發的效率。