紙上談兵：使用者故事地圖（1）

摘要： 你也許是一名互動設計師，或者團隊中隨便某個角色，如何為產品輸出更高價值、進一步提升職業高度，都不要避免要面對專案管理。這裡不是“從事”，而是“懂得”。只有更深入、更高效的協作，才能把更多精力集中在產品，集中在提升賦能的效率上。 我們正在關注設計師在專案管理方面的積累和應...

你也許是一名互動設計師，或者團隊中隨便某個角色，如何為產品輸出更高價值、進一步提升職業高度，都不要避免要面對專案管理。這裡不是“從事”，而是“懂得”。只有更深入、更高效的協作，才能把更多精力集中在產品，集中在提升賦能的效率上。

我們正在關注設計師在專案管理方面的積累和應用，但如何在使用者體驗和專案管理之間架起一座橋樑？如何發掘主動提升專案管理能力（特別是尚未涉及到橫向管理的初級設計師）的動機？以此為契機，我開始學習《使用者故事地圖》，並借內部學習社群，進行了一次體驗使用者故事地圖的圓桌會議。

在接下來的內容中，我將介紹這次有趣的圓桌會議，並聊聊自己對使用者故事地圖的拙見。此外，後續還會用幾篇文章詳細拆解這本書。目前已應用了部分內容在自己的專案中，但尚未完全推廣，這也是這一系列文章冠以“紙上談兵”的原因。即是自嘲，也是敦促。

一、使用者故事圓桌沙龍

圓桌會議中，我們的任務是，遍歷所有人早晨做的事情，並將它們合而為一個人的早晨。藉此過程，感受使用者故事地圖的原理和作用。這些任務具體包括：

1. 將“早晨起床→開始上班”的所有事情分別寫在便籤紙上，總數大於15張；
2. 將所有人的標籤按時間順序從左→右排序，組成我的早晨。
3. 補充各時間段下，可能做的其他事情；
4. 為這些事情分類，並寫在不同顏色便籤紙上，將便籤紙粘在這一組事件的上方，它就是主幹；
5. 用分類和對應的事情，來講Ta的一天；
6. 假定我近期要考試，將這個任務寫在第三種顏色便籤紙上，將它放在地圖的左側，從便籤開始，從左向右劃一條線。將在考試期間可以不做的事情，放線上下方；

上述的每個任務均需控制時間，敦促大家在規定時間內完成任務。

在進行第一項任務時，問題集中於事情大小的範疇，這裡我們只提示說“事情最小粒度是，它有意義！”任務釋出後，得到很多諸如，“這不可能”、“15條？我幾條就可以寫完所有事情”這樣的反饋。此時大可不必理會，因為事實往往證明，每個人寫的便籤都一澮少於15個。從這一點上，我們似乎並不像相當然的那樣瞭解我們自己。

整個任務過程最有趣的過程莫過於發現彼此的不同，哪怕是每天見面的同事。而共同完成任務過程中的互動，也是一個非常好的共創過程，笑聲不斷。

整個圓桌曆經1.5小時。不難看出，首個任務中的事情，其實就是產品開發中的需求點。對它們的排序和分類，是提取產品的主幹，即核心操作流程——這些分類（產品中使用者的關鍵行為）自左向右依次發生；第三種顏色便籤，可以是某版本的目標，對照目標，將不符合的功能篩選出來。

最後，夥伴們分別就本次圓桌進行了分享和總結。這裡摘抄兩個版本做為這一小節的結束。

注：第二版本源自兩個小組的主人公被虛擬為情侶，過程中發生了很多有趣的事情

正經版：

• 對第二輪內容的梳理，印象比較深刻，解決問題的思路和以前不同
• 大家節奏不一樣，為完成任務需要統一；
• 生活中很多事情是可以捨棄的，一旦捨棄，就潛力無窮；
• 重要性、排序等，要根據自身情況，制定標準

戀愛版：

• 生活和或者還是不一樣；
• 談戀愛麻煩，成大事者可以拋棄兒女情長；
• 談戀愛挺好的...；

二、使用者故事地圖

《使用者故事地圖》是一本難讀的書，但它的價值遠超我的預期。本書的作者同時是使用者體驗設計師和敏捷教練，由此不難聯想到，它對設計師瞭解專案管理是不錯的切入點。當然，它對產品經理、產品負責人和專案管理者也同樣適用。接下來，讓我們先簡單介紹下使用者故事地圖。

內容與應用場景

使用者故事，是指使用者來描述使用者渴望獲篩的功能。它包括三個部分：角色、使用者需求、產品價值。我們常常使用一句話來描述使用者故事，某<角色>，通過完成<使用者需求>，實現<產品價值>。使用者故事地圖，則是通過組織寫有“使用者故事”的卡片，幫助版本開發內容遵循產品核心，並從產品整體視角監測開發開發內容和進度。它主要有三種使用方法，分別是：

1. 功能規劃和釋出計劃；
2. 敏捷流程下的，需求驗證與拆解，以符合MVP；
3. 為持續優化產品，跟蹤迭代提供可靠的方法和工具；

價值與作用

從設計賦能角度來講，使用者故事地圖可以幫助設計師：

1. 從產品計劃層面，提升產品使用者體驗，避免沉入細節之中；
2. 找到一種落地產品思維的方法，即平衡使用者價值、產品價值、開發成本三者的關係；
3. 關注專案和產品，設計出落地、有效的產品方案，避免理想化；

從專案管理角度，使用者故事地圖可以解決以下問題：

1. 只見樹木不見森林，重要內容埋沒在細節中，難以排列優先順序；
2. 無法看到版本貢獻功能的完整價值流；
3. 無法方便的使用迭代方法跟蹤、優化內容，確定版本計劃和目標；

從團隊協作角度，使用者故事可以降低溝通與達成共識的成本，將關注力更多的集中在產品上。

那麼，使用者故事的具體內容和注意事項是什麼？使用者故事地圖如何搭建？如何以“使用者故事”驅動專案開發流程？這些內容將會在後續文章詳細介紹。

最後，以一句話結束本篇內容。