寫這篇文章的此時此刻，正在聽徐大樂的《一個人的朝圣》。它一度是我非常喜歡的歌，它的作者而今是一個互聯網人。有感于那句歌詞“世界太大，人會迷路，要么庸俗，要么孤獨”。世界總是太嘈雜，我只是想靜靜。坐在最常來的咖啡館，寫下這一章嚴肅的文。
當我們收集了大量用戶故事進入機會階段，并且根據3W方式篩選出“用于進一步討論”的部分后，我們將帶著這些用戶故事，進入“探索階段”。在這一階段，我們的任務是討論、明確這些用戶故事在技術和設計側的方向，最終形成待開發清單。
在探索階段，要詳細討論誰會用、為什么要用以及怎樣使用你的產品。團隊的目標是構思一個有價值、有用、可行的產品。這時要做許多碎石的工作。只需要將最少數量的故事推入發布待辦列表中，這些列表描述了一個最小可行產品版本。
——《用戶故事地圖》
第二階段：探索階段
這一階段的目的是將討論、明確“機會”的可行性方向，選擇其中合適的部分組成待開發清單。這一階段共有五個步驟。
1. 重新閱讀并理解“機會”信息
這里不再贅述，因此為了更好的進行機會探索，需要對“機會”進行復習?；仡櫵鼈兊?W信息。
2. 深入理解用戶
“人物畫像”是我們理解用戶的方法，而“用戶旅程圖”則幫助我們理解用戶行為，快速建立對用戶和遇到問題的共識。
提到“人物畫像”總感覺是很高深的內容。然而似乎并非如此，簡單的用戶畫像方法也可以幫助我們很好的接近用戶。你需要和團隊一起明確、完成以下幾個部分：
- 畫出簡單的人物素描（照片也行）；
- 基礎信息：包括“Ta是誰？”、“Ta為什么要使用我們的產品？”
- 關于Ta：特點、目標&痛苦點、活動；
- 啟示：“對Ta有什么價值？”、“這個方案能改變Ta的理由？”
“用戶旅程圖”可以做為腦暴解決方案的跳板，也可以通過它來驗證自己心儀的解決方案是否真的可以解決問題。在用戶原有行為路徑中，去看它的“事件”、“觀察”、“痛點”和“快樂”。此方法網絡上有大量資料，這里不再贅述。
3. 快速可視化方案，進行邏輯、技術可行性評估
在回顧機會、理解用戶及行為的過程中，解決方案會逐漸浮出水面。做為交互設計師，應該具體基礎的手繪能力，能在會議中將大家說出來的方案快速在白板（大家都能看到的地方）上還原——它將大大提升方案輸出的速度，并在共創中快速達成共識。除了界面草圖，用戶畫像、流程圖、照片和文字描述都是不錯的方案呈現方式，唯一重要的是（此處敲黑板），快速的、將它們呈現在所有人都可以輕易看到的地方。
將可視化呈現的方案草圖和故事地圖（為什么要加入地圖？后面會解釋）放在一起，與參會的技術人員、設計師進行溝通，將能夠快速獲得專業建議，發現技術風險。減少“先需求后評審”帶來的成本和時間浪費。在討論過程中，我們可以使用“如果……會（怎樣）”的語句來不斷推敲方案、填補漏洞。這一過程中，會談到硬件條件、數據情況、后臺服務等內容，請確保自己對所有事情都做了筆記。后面你就會知道它們有多重要。
也許有人會有疑惑，為什么要在這里加入機會所在的故事地圖？因為在開發過程中，我們易于關注有趣的功能而忘記在這期間的基本流程。然而機會所在的整個地圖幫忙我們補充和記憶這些細節和過程。通過地圖，能從全局角度發現技術限制。
4. 針對上述內容，重新校正用故事內容
在探索階段的討論過程中，具體應該討論什么？哪些是必要或重要的？下表做為一個清單，也許可以幫助我們盡可能做好探索階段的任務，試著讓探索階段討論的內容包括以下內容。
| 標題 | 說明 |
|---|---|
| 產品角色 | 1)討論不同類型的用戶：在產品中，這個功能的用戶包括哪些細分用戶； 2)有哪些其他干系人； 3)若為企業軟件，它的客戶是怎樣的； |
| 使用原因 | 為什么特定的用戶會關注這些功能 |
| 使用場景 | 1)用戶何時使用； 2)使用時的現實場景是什么； |
| 功能內容 | 1)用戶希望通過軟件來做的事情； 2)可將調用某不為人知的系統視為特殊用戶; |
| 方案實現 | 1)有品質的討論需要關注：為什么做、做成什么、怎么做； 2)沒有明確談到如何實現，就很難評估其實現成本； |
| 問題與假設 | 1)對技術假設發問：需要依賴的底層系統是什么；是否已了解這些系統的工作原理；還需關注的其他技術風險； 2)對產品假設發問：用戶會接受這個方案嗎？真的理解用戶嗎？它真是用戶需要的的嗎？是用戶痛點嗎？ |
| 異常情況 | 1)有哪些異常情況出現； 2)出現異常時，用戶是否有其他方式完成任務； |
| 開發周期 | 1)隨著討論的進行，逐漸主準確出開發時間（xx天）； 2)根據開發周期的結果，判斷是否中止開發或是繼續； |
| 其他方案 | 丟掉文案中的部分假設，回到解決問題上來，找到最小成本、更有效的解決方案 |
5. 去掉低優先級的內容，保留必要內容進入下一階段
當有多人參與討論的時候，為了讓每個人都滿意，往往會以得到一個巨大的解決方案。這顯示有違初衷。如果決定開發的故事數量最后大于“放棄開發的故事數量”，往往說明探索階段沒有做對。
寫在后面
在探索階段留下來的用戶故事，將會進行產品原型的設計和細節討論。探索階段是從產品和用戶層面來檢測、過濾用戶故事（我們在實際過程中一概稱“需求”），我們在這一階段的關注點優先順序是：優先關注“優先滿足的業務目標、用戶群體”，然后再關注他們的需求中“優先滿足的那部分”，最后再“根據需求，排列功能的優先級”。
探索階段之所以重要，是因為它實際解決了成本問題。例如需求方擔心會議效率低，不能快速輸出結果，自己就直接把需求寫完了。然而有時思考片面、知識結構受限，常會產出低質量、在需求會中被推翻的需求。若這個需求輸出的過程中邀請各崗位重要人員參加（人數要限制在5人以內），不僅可以在前期就得到專業的反饋，同時還能突破單一的視角，為方案帶來更多的可能性。
將早期的用戶故事（需求）確認環節分為“機會”、“探索”兩個階段，看似是增加了環節，實際上卻是有效控制流入后續階段的需求質量，從整體上降低了協作成本和需求風險。畢竟也不是每個階段，都需要所有人參加。
最后，以這段非常喜歡的歌詞結束這一章。
做夢的 醒來的
沉默著 躁動著
世界太大 人會迷路
要么庸俗 要么孤獨
……——《一個人的朝圣》徐大樂
—— end ——
全部內容鏈接：
用戶故事地圖（1）：體驗用戶故事
用戶故事地圖（2）：作用
用戶故事地圖（3）：故事與卡片
用戶故事地圖（4）：創建方法
用戶故事地圖（5）：開發流程之“機會”階段
用戶故事地圖（6）：開發流程之“探索”階段
用戶故事地圖（7）：開發流程之“設計”階段
用戶故事地圖（8）：開發流程之“故事工作坊”階段
用戶故事地圖（9）：開發流程之“研發-評估-交付”階段
用戶故事地圖（10）：開發流程之“回顧”階段
用戶故事地圖（11）：故事（需求）拆分
用戶故事地圖（12）：后記
