為什麼「描述需求」如此困難？
身在產品開發團隊的我們，是不是遇過以下狀況呢？
- 每天面對超多產品回饋、需求申請，花很多時間釐清、溝通？
- 參加無數的會議，冒出各種需求，發散的無邊無際？
- 終於提出產品路線圖，面對各方質疑，結果改到四不像？
這些「蒐集、整理、協商需求」的過程，是不是很令人頭痛，又消耗我們寶貴的時間？不僅難取得共識，我們最怕的更是「產出無法推動成效」？
究竟卡在哪裡？歸納出這幾種狀況：
- 1) 描述需求時「語意不清」，沒有釐清的過程，產生誤會
- 2) 針對相同的功能、介面、流程，因為每人代表「不同用戶」，或遇到「不同情境」，提出互相獨立的需求，產生衝突
- 3) 針對相同需求，因為負責「不同目標」，或站在「不同的解讀角度」，產生僵局
因為以上三種狀況，導致我們必須反覆溝通，消耗很多時間，也難以確立目標、推動成效。
舉例：營電商網站的團隊，討論「如何優化商品詳細資訊頁」
大家七嘴八舌提出想法…
行銷 Abby：「我們要提供更多商品照片，我逛電商的時候最愛看照片了。」
狀況 (1)，語意不清：「商品照片」是指主商品的照片，還是相關商品的照片？為什麼需要照片，能達成什麼效果？
工程師 Bob：「放大圖片的介面也很難用，點擊圖片還另開分頁，又不能切換圖片。」
設計師 Cindy：「但我覺得是排版有問題，很難找到資訊，令人生氣，我朋友因此乾脆不買了。」
客服 David：「可是，顧客說『商品評價』最重要，又說我們的評價功能很難用，不能篩選評價。」
狀況 (2)，情境差異：同樣針對商品資訊頁，在「什麼情境」，覺得放大照片、或產品資訊、或商品評價，很難用？
行銷 Eddie：「我覺得最重要的是降低跳出率，因為這是站上流量最高的頁面。」
工程師 Fiona：「我們不是有首購優惠嗎？可以在商品頁上強調，吸引顧客購買！」
業務 Greg：「對對對，賣家一直跟我講『優惠卷功能』很重要，希望顯示各種優惠，在商品旁邊。」
工程師 Henry：「如果可以讓顧客分享優惠給朋友，說不定還能帶進更多流量！」
行銷 Iris：「說到分享優惠，購物季要到了，可以完成『分享優惠』和『贈送購物金』的功能嗎？」
狀況 (3)，目標或角度差異：同樣針對商業需求有關的「優惠」顯示，但各自期待達成什麼目標？這些目標分別遇到什麼挑戰、哪些限制？
如何改進？
知道這些狀況後，我們該如何努力，朝什麼方向改進呢？
- 面對狀況 (1)，我們希望：降低「描述需求」時「語意不清的情況」
- 面對狀況 (2)，我們希望：降低「溝通需求」時「被自身立場、情境侷限的情況」
- 面對狀況 (3)，我們希望：降低「提出需求」時「遺失或誤會個別目標的情況」
如果有一套「語言結構」，除了讓我們朝以上方向改進，還能額外產生以下效果：
- (1) 減少「建立方法」時「花費的時間」或「遭遇的排斥」，融入現有方法，相輔相成
- (2) 減少「敘述需求」時「花費的時間」，口頭溝通時可濃縮成 3 句話，文字溝通時可濃縮成 1 頁 A4 文件
- (3) 減少「依情境重置溝通素材」所「花費的時間」，可以有彈性的重組、合併、拆分
那是不是很令人期待呢？
為了介紹這個語言結構，我們先回顧一下「需求」的本質。
「需求」與「設計」的本質
引用【設計思考怎麼改變世界?】的這段話：
設計就是「現況」到「目標」的過程。在這裡我為了好記，簡單的說，設計就是 A→B
如果我們認同以上這段話，那麼反過來說：
因為「使用者處於一個情境」，進而「希望達成某個目標」，所以產生了「需求」
先有「產生需求的過程」，我們才能「捕捉需求」，並依據需求來設計。符合「需求驅動設計」的「用途理論」，基於一個重要的假設：
人是「目標導向」的行為者，而「情境」會影響目標，但「手段」並不會
為了捕捉、描述需求，我們基於以上假設，產生了各式各樣的工具，都為了達成以下子目標：
- (A) 降低團隊「理解顧客情境」所「花費的時間」或「認知門檻」
- (B) 減少團隊「描述目標」所「花費的時間」或「誤解的情況」
- (C) 降低團隊「溝通產品方案」所「花費的時間」或「誤解的情況」
- (D) 降低團隊「驗證方案」所「花費的時間」或「經濟成本」
舉例來說： Customer Journey Map、Persona、Storyboards、Empathy Maps、Value Proposition Canvas、等等等，多少都希望能達成以上子目標 (A)、(B)。而輔助產品設計與開發的工具中，PRD、User Story、User Flow、Wireframe、Wire Flow、等等等，都希望能達成子目標 (C)。
若我們野心更大，希望達成子目標 (D)，則需要眾人通力合作，進一步導入 Prototyping、Usability Testing、AB Testing 等方法。
然後我們就發現，這也是一個「工具氾濫」的時代。
我們有「上千種工具」，協助我們釐清「上萬種需求」，聽起仍然讓人無奈？在工具氾濫的時代，我們如何抓取「團隊有限的注意力」，傳達最重要的訊息？如何給一個有效的摘要，快速複習上次的階段成果？有沒有通用的框架，可以串連眾多工具？
終於，我認識了「用途理論」，以及一套精簡的「結構化語言」工具。
三個「結構化語言工具」
分別是：
- 工具一：用途規格 Job Spec
- 工具二：用途故事 Job Story
- 工具三：渴望成果 Desired Outcome
簡單的來說，我們可以這樣運用三個工具：
- 口頭溝通時，先傳達 Desired Outcome，再用 Job Story 補充，釐清目標和顧客需求
- 短文溝通時，以 Desired Outcome 和 Job Story 開頭，放在 PRD 或產品/功能提案中
- 長文溝通時，把 Desired Outcome 和 Job Spec 融入現有的研究報告中，搭配 UX 工具箱中「濃縮研究成果的圖表」，圖文並茂、相輔相成
- 在 Desired Outcome、Job Story、Job Spec 中替換相同內容，善用三者類似的結構，快速重組、合併、拆分
接下來，我們將用 2 篇文章，分別介紹這三個工具，並進一步說明它們的神奇之處。準備好了嗎？
如果你對用途理論也感興趣，或者想繼續看到系列文章，歡迎 [留言] 或 [鼓掌] ，藉此督促我不得拖稿囉！