超周全！關(guān)于用戶故事地圖的7種用法

金蝶云之家體驗中間交互設計師-方馨月：之前讀完 Jeff Patton 的《用戶故事地圖》覺得是一本好書，但是一向沒有機會去實踐。

最近在工作中使用了用戶體驗地圖進行云之家工作匯報輕應用的開發(fā)評審，發(fā)如今討論過程中，思路更加清晰、交流更加順暢了。

詳細體現(xiàn)在：

• 開發(fā)人員能夠很容易發(fā)現(xiàn)產(chǎn)品設計的題目。
• 小組成員的參與度更高。
• 決策更加敏捷，會議更加高效。
• 會議結(jié)束后，有寫意的討論效果產(chǎn)出。

會后，更加覺得用戶故事地圖是一個可以進步協(xié)作服從的工具，所以，想寫一篇“讀書筆記&實行思考”，來記錄這段時間的收獲。

《用戶故事地圖》不僅僅是講述什么是用戶地圖、怎么使用用戶地圖，也講了許多團隊協(xié)作的Tips，并且給出了許多實例。我這里直接從這本書的其中一個角度——“怎么使用用戶地圖”為內(nèi)容，然后結(jié)合一些本身的想法，來寫這篇讀書筆記。

用戶故事地圖的使用，重要可以分為三個方面：

• 產(chǎn)品的「0，0.5」：新產(chǎn)品功能規(guī)劃／發(fā)布規(guī)劃。
• 產(chǎn)品的「0.5，1」：需求討論／需求拆解／優(yōu)先級排序。
• 產(chǎn)品的「1，＋∞」：產(chǎn)品優(yōu)化。

下面將根據(jù)以上三個方面，細致進行說明。

兩點詮釋：

• 我很粗暴的根據(jù)「是否必要開發(fā)人員介入」這一條件，將產(chǎn)品發(fā)版前分為兩部分，即產(chǎn)品的「0，0.5」，產(chǎn)品的「0.5，1」。在開發(fā)人員介入前，更多的是產(chǎn)品經(jīng)理如何進行產(chǎn)品設計，產(chǎn)品整個的基調(diào)和走向都是在這一部分定下來的。當開發(fā)人員開始介入后，就詳細聚焦于功能的實現(xiàn)方面了。能否實現(xiàn)？如何更好的實現(xiàn)？是這一部分的重要題目。但是要解決這一部分的題目的一個大前提就是，開發(fā)人員如何周全的理解這個產(chǎn)品？讓大家腦海里的東西是同等的？這個是最艱難的題目。
• 上面三點的「產(chǎn)品」，其實不僅僅指的是一個完備的產(chǎn)品，也可以是一個組件、一個大型功能。總之是必要進行思考、設計、開發(fā)并之后會有維護升級的一個模塊。

一. 產(chǎn)品的「0 ，0.5」

當產(chǎn)品或某一個大型模塊在進行功能設計的時候，可以采取用戶故事地圖的體例來梳理所有的功能點，并進行迭代周期的規(guī)劃。

新產(chǎn)品功能規(guī)劃之產(chǎn)品全景圖

1. 目的

建立產(chǎn)品／模塊的全局印象，有全局觀，進而可以團體規(guī)劃產(chǎn)品／模塊。

2.適用場景

產(chǎn)品經(jīng)理（可能搭配交互設計師）梳理產(chǎn)品框架。

3.所需資源

• 2-3名參與人員（需原諒產(chǎn)品設計者、產(chǎn)品決策者）。
• 卡片／便利貼，筆。

4.操作體例

• 一邊討論，一邊將想要的功能寫在卡片上。
• 一邊討論，一邊將將功能分類，按照x軸為模塊名稱，y軸為所屬模塊下的功能進行排列。
• 一邊討論，一邊調(diào)整當前的布局（可剔除／添加卡片、調(diào)整卡片位置）。

5.詮釋／說明／tips

1）為什么是2-3小我？

對于有的項目，產(chǎn)品設計人和產(chǎn)品決策人是一小我，為什么還必要2-3小我呢？由于在我看來，一小我的想法是無法做到完美的，但是假如是兩小我合作則可以避開90%以上的產(chǎn)品漏洞，所以在產(chǎn)品功能規(guī)劃的方面，更建議2人以上（當然假如碰到牛人，思維無漏洞，一小我建立產(chǎn)品全景圖也是沒任何題目的）。不建議3人以上，則是由于對產(chǎn)品指手畫腳的人多了，只會越來越亂，產(chǎn)品設計層面，要少而精。

2）假如只是理個產(chǎn)品邏輯，為什么不用腦圖：

從操作體例也可以看出，這是一個必要團隊合作的過程。腦圖更像是一小我的思維梳理，不利于多人的團隊合作?？ㄆ暮锰幵谟冢?/p>

• 所有人都有調(diào)整布局的權(quán)限。
• 沒有了屏幕的限定可以支持高復雜度的產(chǎn)品架構(gòu)。
• 可以更方便的刪減和備注。
• 為了后續(xù)的操作。

新產(chǎn)品功能規(guī)劃之大家來找茬（功能點設計）

1.目的

對于關(guān)鍵的功能點或有爭議的功能點，可以拿出來大家一路討論，進而明確功能點的詳細操作流程，削減踩坑的可能性。

2.適用場景

確定某個有爭議的功能點的設計。

3.所需資源

• 3-4名參與人員（需原諒產(chǎn)品決策者、產(chǎn)品設計者、用戶體驗設計師）。
• 產(chǎn)品全景圖。
• persona卡片 及 scenario卡片。
• 不同顏色的卡片／便利貼，筆。

4.操作體例（以功能點A的設計為例）

• 圍繞A，各參與人員站在本身的角度，思考A在流程中可能出現(xiàn)的情況與題目，挑刺與找茬。
• 圍繞A，根據(jù)剛剛點意見，優(yōu)化流程或提出更好的體例。
• 將討論效果在不同顏色的卡片／便利貼上寫出，貼在功能點A的旁邊。

5.詮釋／說明／tips

• 肯定要圍繞A，跑題太可怕，降低會議服從且達不到目的。
• 肯定要得出效果，更好的方案／保持當前方案不變。

發(fā)布規(guī)劃

1.目的

優(yōu)先級排序，劃分發(fā)布路線圖。

2.適用場景

產(chǎn)品經(jīng)理（可能搭配交互設計師）確定產(chǎn)品發(fā)布內(nèi)容。

3.所需資源

• 2-3名參與人員（需原諒產(chǎn)品設計者、產(chǎn)品決策者）
• 產(chǎn)品全景圖

4.操作體例

• 按照產(chǎn)品的長線目標，對功能排優(yōu)先級。
• 制訂產(chǎn)品發(fā)布計劃，確保每一次的發(fā)布內(nèi)容都是 MVP。

5.詮釋／說明／tips

• 如何排列優(yōu)先級？

我覺得書里面有一句話能夠很充分的回答這個題目：

聚焦于成果，即產(chǎn)品發(fā)布后用戶能使用和感知的東西，切分發(fā)布計劃應該以成果為導向。 ——《用戶故事地圖》P56

• 怎么劃分發(fā)布周期？

同樣也是聚焦于成果，每一個發(fā)布的版本盼望能夠達到什么樣的結(jié)果，再就是，保證 每一個版本都是當前情況下的 MVP。

二. 產(chǎn)品的「0.5 ，1」

當產(chǎn)品形態(tài)及功能確定后，則進入到需求確認階段。這個階段是必要產(chǎn)品的所有參與者參與其中的，但是重要以開發(fā)人員為主，確認產(chǎn)品功能的可實現(xiàn)性。

需求討論 —— 大家來找茬

1.目的

與開發(fā)人員正確、高效地確認需求。

2.適用場景

產(chǎn)品的某一個迭代，必要確認需求。

3.所需資源

• 7名以內(nèi)項目參與人員（需原諒產(chǎn)品設計者、用戶體驗設計師、開發(fā)人員），開發(fā)團隊負責人必須參與，其他開發(fā)人員盡量參與（假如人數(shù)超過7人，可以采用金魚缸協(xié)作模式）。
• 產(chǎn)品全景圖。
• 迭代功能的較細致文檔（可能是word文檔、可能直接是設計稿、可能是更詳細的故事地圖）。

4.操作體例

• 各參與人員站在本身的角度，思考各功能點在流程中可能出現(xiàn)的情況與題目，挑刺與找茬。
• 根據(jù)剛剛點意見，優(yōu)化流程或提出更好的體例。
• 將討論效果在不同顏色的卡片／便利貼上寫出，貼在功能點的旁邊。

5.詮釋／說明／tips

1）為什么必要產(chǎn)品全景圖？如許做有什么益處？

產(chǎn)品全景圖可以幫助開發(fā)人員建立整個產(chǎn)品形態(tài)，能夠完全清楚當前的團體的開發(fā)內(nèi)容，利于架構(gòu)的搭建，代碼模塊化／復用等等。

2）必要細致的一點：在此過程中必要控制住，盡量不要延長出新功能，也不要大范圍的修改功能。假如大范圍的修改了功能，也不建議直接以會議效果為最閉幕果。由于本來的方案是經(jīng)過深思熟慮的，而在會議上，人太過于愉快的狀況下容易沖動，岑寂下來再思考一下方案也會發(fā)現(xiàn)會議上的效果可能會存在許多漏洞。

需求拆解 —— story 下的 story 細分

1.目的

將當前的 story 細分為開發(fā)人員可以接受、方便開發(fā)的 story。

2.適用場景

當產(chǎn)品的 story 顆粒度過大時，開發(fā)人員必要將 story 進一步細化。

3.所需資源（與需求討論的資源同等）

• 7名以內(nèi)項目參與人員（需原諒產(chǎn)品設計者、用戶體驗設計師、開發(fā)人員），開發(fā)團隊負責人必須參與，其他開發(fā)人員盡量參與（假如人數(shù)超過7人，可以采用金魚缸協(xié)作模式）。
• 產(chǎn)品全景圖。
• 迭代功能的較細致文檔（可能是word文檔、可能直接是設計稿、可能是更詳細的故事地圖）。

4.操作體例

• 在多方討論下，將大的 story 按照開發(fā)必要進行拆分。
• 將拆分好的 story 寫在卡片／便利貼上，貼在對應大的 story 下方／旁邊。

5.詮釋／說明／tips

產(chǎn)品經(jīng)理不要太過于干涉技術(shù)人員的拆分，在不涉及原則的情況下，他們開發(fā)怎么恬逸就隨著他們來吧。

優(yōu)先級排序

1.目的

開發(fā)人員在一個迭代內(nèi)，對開發(fā)內(nèi)容進行排序。

2.適用場景

在「需求拆解」后，很天然的進入到優(yōu)先級排序。

3.所需資源（與需求討論的資源同等）

• 7名以內(nèi)項目參與人員（需原諒產(chǎn)品設計者、用戶體驗設計師、開發(fā)人員），開發(fā)團隊負責人必須參與，其他開發(fā)人員盡量參與（假如人數(shù)超過7人，可以采用金魚缸協(xié)作模式）
• 產(chǎn)品全景圖
• 迭代功能的較細致文檔（可能是word文檔、可能直接是設計稿、可能是更詳細的故事地圖）

4.操作體例

在多方討論下，將已經(jīng)拆分成顆粒度適宜的 story 進行排序。

三. 產(chǎn)品的「1，＋∞」

當產(chǎn)品的出版發(fā)布后，后續(xù)的工作就是優(yōu)化和更新了。在此階段可能會進行用戶調(diào)研，那么調(diào)研的數(shù)據(jù)如何進行處理才能夠反映更多的題目呢？這里提供一種體例，在用戶故事地圖中被稱作 journey map （也就是 experience map ），但是在其基礎上做了一些些調(diào)整。在上面疊加了情緒版的使用方法。

旅行地圖

1.目的

用戶調(diào)研數(shù)據(jù)處理，確定產(chǎn)品的優(yōu)化點與優(yōu)化需求。

2.適用場景

用戶調(diào)研數(shù)據(jù)處理。

3.所需資源

• 目標用戶的評價數(shù)據(jù)
• 3-7名參與人員（需原諒產(chǎn)品設計者、產(chǎn)品決策者、用戶體驗設計師）
• 不同顏色的便利貼／卡片

4.操作體例

• 用戶操作路徑，每一個觸點按步驟寫在便利貼上，在x軸排開。
• 評價數(shù)據(jù)寫在便利貼上，按照體驗良好程度，在y軸排開。
• 綜合每個觸點上的評價數(shù)據(jù)，進行打分。
• 根據(jù)得分，調(diào)整觸點卡片的y坐標。

以上就是用戶故事地圖的 7 種用法，分別對應于產(chǎn)品的「0 ，0.5」、「0.5 ，1」、「1，＋∞」三個大的階段。盼望對大家能有所幫助。

迎接關(guān)注微信公眾號：「UXD-Cloudhub」