如何通過場景需求做產品設計

需求場景是一種更接地氣的分析和描述用戶需求的方法（我個人偏愛「需求場景」這個詞）。它應該擁有這樣的結構：

「在某某時間（when），某某地點（where），周圍出現了某些事物時（with what），特定類型的用戶（who）萌發了某種慾望（desire），會想到通過某種手段（method）來滿足慾望。」

需求場景的意義
傳統的軟體開發流程中，產品經理/產品策劃首先會提供一份功能列表。這種功能列表所使用的描述方式往往是以程序為導向的，比如「商品列表支持按照價格從低到高排序」。
這種描述方式的弊端是：

產品經理得出該結論往往是因為競爭對手擁有了該功能，而非分析了用戶的真實需求。
合作夥伴（交互設計師/視覺設計師/開發工程師）不能直接體會到該功能是為了幫助用戶實現什麼目標的，也就不知道這個功能的價值，究竟能給真實的生活帶來何種變化。
而以需求場景的方式描述需求，就能夠有效避免這些弊端：

產品經理知道這個新開發的功能是為了幫助用戶解決什麼問題
交互設計師可以從中獲知這種需求場景的細節：「發生頻率，需求強度，用戶有什麼樣的能力和輔助工具」
其他合作夥伴更容易了解到這個功能的價值，更能夠及時表達意見，否決不靠譜的功能，並對有價值的功能產生更強烈的共鳴，幹勁兒十足。
2、如何判斷一個使用（需求）場景有價值？
依照以前所學習的心理學知識，當用戶具有某種需求時，會嘗試使用各種手段來滿足它。當環境中不存在轉為為之設計的解決方案時，用戶就會用各種儘可能能找到的東西來湊活（你們知道飛機杯、充氣娃娃之類的東東對吧）。
當實在是找不到任何解決方案時，用戶就只能憋著了。當很長時間裡都無法發現解決方案時，用戶就會絕望（學名叫習得性無助），並壓抑嘗試的行為（沒有網購前，正在上班的你無論多麼強烈地想給老婆買結婚紀念日的禮物，都不會去開網頁）。但是，一旦把這種解決方案拿到用戶面前，請他試用，他在體驗到成功的喜悅后就會對它愛不釋手（想想在12306上訂票成功時的心情吧，雖然確實爛）。
所以，就誕生了兩種衡量需求場景靠譜程度的方法：

調查現階段用戶是否在湊活著使用某種產品，心裡在罵娘，但還忍著用（又想到了12306對吧）。
用最低廉的成本做出一個基本能用的解決方案，請目標用戶試用，詢問體驗。
3、使用（需求）場景的描述方法和各部分必要性
前面提到，需求場景應該如此描述：
「在某某時間（when），某某地點（where），周圍出現了某些事物時（with what），特定類型的用戶（who）萌發了某種慾望（desire），會想到通過某種手段（method）來滿足慾望。」

各部分信息存在的意義如下：

when，where，with what
這幾點信息其實統一地描述了需求產生的環境。從這些環境信息可以分析出誘發需求的條件和需求產生時的環境條件。
例如，「在候機時，候機廳里，用戶看到手機電量過低時，會想要充電」。
基於此，可以分析出，用戶是在電量低的信息刺激下，想要充電。當時他所在的位置是候機廳，一個充滿電器，但是沒有插座開發給乘客的地方。

who
需求場景還需要分析是什麼樣類型的人有這種需求，他有什麼樣的能力可以潛在地幫他實現目標。
繼續前面的例子，坐飛機的手機用戶都可能會有這種需求，因為他們下了飛機一般都會聯繫家人報平安，聯繫別人來接機，等等。坐飛機的這些人一般都比較有錢，會帶著現金或者信用卡。

desire
對需求的描述有一些注意事項，那就是某種需求背後往往還有更深層次某種需求，它只是這種需求的解決方案。
比如想給手機充電是一種需求。但背後的需求可能是打發無聊、給家人保平安、看目的地城市地圖、聯繫旅行社等等。給手機充電只是這些背後需求用戶自己能想到的一種解決方案。
不斷一層一層分析需求可能幫助你更清楚地了解用戶到底想要什麼。那麼，一旦滿足某種需求實在太難，滿足它背後的需求也是可以的。比如，假設在候機大廳提供充電太難，還可以向用戶提供電視（打發無聊）、刷信用卡的公用電話（給家人保平安）、提供該航班目的地地圖（看目的地城市地圖）、代定酒店（聯繫旅行社）。

method
method是用戶現有的解決方案。把現有解決方案清晰地描述出來可以幫助產品團隊判斷競爭對手是誰。這種競品往往不局限於同行業，只要目標需求一樣，就是競爭對手。
例如，針對獲取地理信息這個需求，衛星地圖的競爭對手可能是紙質地圖，指南針和指路大媽。
有了對競爭對手的了解，就可以更明確地知道這種用戶需求是否存在，強度如何，我們的新方案有何優勢，對方是否弱爆了。