如果要在三分鐘內，甚至一分鐘內快速讓一群主管們理解「使用者是誰」，你會怎麼做？在專案開發過程中，有時候我們需要非常簡單扼要地說明使用者的需求與輪廓給利害關係人（Stakeholders）知道，例如 PM（產品經理或 Product Manager）在專案初期時，需要跟管理階層說明這個產品是為了滿足哪一種使用者的需求，以便於評估在商業上的策略調整、技術限制下的可行作法與影響，這時候使用者的需求就需要被描述的簡短清楚。
（商業、使用者、技術三者的交集通常稱之為創新或是使用者經驗）
等一下，不是有人物誌（Persona）嗎？而且也有做過使用者經驗地圖（User Experience Map），為何不拿來作為溝通的工具呢？當然這些工具非常完整，也具有專業說服力，如果是在一個 workshop 的場合中，有一小時以上的時間可以運用，人物誌跟使用者經驗地圖都可以提供深度的了解，並讓大家形成更完整的共識。但是如果 PM 在一個簡報場合，必須在三分鐘內讓各部門的主管們對使用者的輪廓有個概念，那麼帶他們認識一個叫做 Jimmy 的人物或是打開一個需要 zoom in 的龐大歷程地圖並不容易帶來好的效果與事後記憶。
所以，有什麼簡易方法？
使用者需求架構
如上圖，使用者需求的架構分成四個項目，是誰、行為、目的、問題。假設我們要描述一個「找美食餐廳」的使用者需求，就會以這四個項目分別帶出簡單的文字描述：
使用者是誰
描述這個產品的使用者輪廓，可以帶入性別、年齡區間、職業、刻板印象（例如輕熟女甜點控），如果可以的話，用量化的資料來幫助說明使用者輪廓。
使用者有什麼行為
行為模式著重在描述使用者平常有的行為、習慣。在這個例子中，會描述女性外食上班族在「外食」這個命題下有什麼既存的行為模式，盡量在兩句話之內講完，當然這些行為的描述都應該要根據真實的使用者訪談資料而來，而不是憑空想像或是用自身經驗來推敲，如果是既有產品且有做過 Persona，可以把其中的內容精簡後放進來。
使用者有什麼目的
「目的」也是圍繞在命題（找美食）上的，也就是回答一個問題：「這種使用者為什麼要找美食，為了什麼目的？」，通常是要回答更高層次的問題，為了滿足使用者心理層面的什麼需求，安全感、自尊、社交認同等等。產品的情感面設計或是想要滿足的較高層次需求應該是要朝著使用者的這個「目的」推進。這個項目能讓利害關係人較容易聯想到產品的願景，另一方面行銷人員也能從「目的」去發想產品在行銷時可以說故事的方向，例如強調這個產品是能更方便有效地讓大家開心聚餐。
在使用者研究的資料收集與分析過程，「目的」往往需要在訪談的後半段或是訪談結束後，使用者在充分放鬆的狀態下，問出他們心中最真實誠懇的想法。有時候並不是那麼容易做到，如果得到稍微「低層次」一點的答案也沒關係，例如「想跟朋友們開心聚餐」可能只有「想跟朋友們聚餐」的程度，仍然可以算是有效的「目的」。
另外如果 PM 有 User Stories 的話，也可以從句型中「As a …., I want to …., So that …...」的 So That 那段來設定為「目的」。
使用者有什麼問題
「問題」指的就是使用者的痛點（Pain Points），是我們透過使用者訪談歸納而來的重要痛點，同時也是產品要解決的最主要問題。這裡的「問題」若能透過量化的數字說明問題的嚴重程度或規模會更具體。
到目前為止四個使用者需求的架構應該可以在三分鐘內快速讓人理解，並且可以透過一頁的簡報來呈現：
當你說明到這時，你的利害關係人應該對使用者以及使用者痛點有一個大致的理解。這時候可能會開始討論產品要做的方向，也就是該如何解決我們定義出來的「問題」，你也許會需要更深入的說明「問題」是什麼，背後有什麼原因。
五個 WHY
如果只從前面的字面上來看，這個「問題」的解決方案可能會被認為是「那麼就幫使用者推薦幾間精選餐廳，減少他們閱讀時間吧」，或是「幫使用者做出文章的摘要，節省做選擇的時間」。但是這些解決方案未必有觸及到問題的本質，在事前我們可以用一直反覆追問WHY 來分析問題的本質，例如：
如果我們能夠呈現給利害關係人這個分析過程，就能讓大家比較清楚的了解，使用者最終想要解決的問題在於想要做出最好的決策（選出最好的餐廳），而「最好」這個標準，即使是同一個人也會因不同情境而做出不同選擇，產品能夠做的是提供「充分資訊」來幫助使用者做出最好決策，而這些充分資訊中，需要被強調的應該是餐廳的優缺點，並且一定要是可以被信任的資訊。
另外在溝通設計風格時，也比較能理解為什麼這個產品要營造成快樂溫馨的聚會氣氛（為了要呼應「想要有一次美好的聚餐回憶」）。
修改成適合你的版本
除了用在與利害關係人的溝通上，這個使用者需求簡報頁也可以放在每一個設計提案簡報開頭或是每次迭代計畫會議的開場。用兩頁簡報描述出使用者需求看起來結構簡單，但是要花的時間、做的研究其實也少不到哪去。再次強調，這些內容都需要實際的研究訪談資料支撐，在還沒做使用者研究之前，可以暫時用我們（專案團隊成員們）目前的假設代入，並註明這是稍後需要透過使用者研究來確認跟調整的。
不管簡單快速的介紹或是完整深度的工具，都是為了協助每個人建立同理心，並了解現象的本質。所以在實際運用時，並非一定要遵守這個架構不可，只要能增加溝通的效率，根據每次現況做修改也是很合理的，比如說加上產品情境照或是人物誌的使用者頭像等等，希望大家能夠演化出一個適合自己的版本。
作者：Jeff
推薦其他 UX 實驗室文章：
留言列表
