您當前位置:圖趣網(Tuquu) >> 網頁設計教程 >> 設計理論 >> 瀏覽設計教程

超周全!關于用戶故事地圖的7種用法

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

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

詳細體現在:

  • 開發人員能夠很容易發現產品設計的題目。
  • 小組成員的參與度更高。
  • 決策更加敏捷,會議更加高效。
  • 會議結束后,有寫意的討論效果產出。

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

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

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

  • 產品的「0,0.5」:新產品功能規劃/發布規劃。
  • 產品的「0.5,1」:需求討論/需求拆解/優先級排序。
  • 產品的「1,+∞」:產品優化。

下面將根據以上三個方面,細致進行說明。

兩點詮釋:

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

一. 產品的「0 ,0.5」

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

新產品功能規劃之產品全景圖

1. 目的

建立產品/模塊的全局印象,有全局觀,進而可以團體規劃產品/模塊。

2.適用場景

產品經理(可能搭配交互設計師)梳理產品框架。

3.所需資源

  • 2-3名參與人員(需原諒產品設計者、產品決策者)。
  • 卡片/便利貼,筆。

4.操作體例

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

5.詮釋/說明/tips

1)為什么是2-3小我?

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

2)假如只是理個產品邏輯,為什么不用腦圖:

從操作體例也可以看出,這是一個必要團隊合作的過程。腦圖更像是一小我的思維梳理,不利于多人的團隊合作。卡片化的好處在于:

  • 所有人都有調整布局的權限。
  • 沒有了屏幕的限定可以支持高復雜度的產品架構。
  • 可以更方便的刪減和備注。
  • 為了后續的操作。
新產品功能規劃之大家來找茬(功能點設計)

1.目的

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

2.適用場景

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

3.所需資源

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

4.操作體例(以功能點A的設計為例)

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

5.詮釋/說明/tips

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

1.目的

優先級排序,劃分發布路線圖。

2.適用場景

產品經理(可能搭配交互設計師)確定產品發布內容。

3.所需資源

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

4.操作體例

  • 按照產品的長線目標,對功能排優先級。
  • 制訂產品發布計劃,確保每一次的發布內容都是 MVP。

5.詮釋/說明/tips

  • 如何排列優先級?

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

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

  • 怎么劃分發布周期?

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

二. 產品的「0.5 ,1」

當產品形態及功能確定后,則進入到需求確認階段。這個階段是必要產品的所有參與者參與其中的,但是重要以開發人員為主,確認產品功能的可實現性。

需求討論 —— 大家來找茬

1.目的

與開發人員正確、高效地確認需求。

2.適用場景

產品的某一個迭代,必要確認需求。

3.所需資源

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

4.操作體例

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

5.詮釋/說明/tips

1)為什么必要產品全景圖?如許做有什么益處?

產品全景圖可以幫助開發人員建立整個產品形態,能夠完全清楚當前的團體的開發內容,利于架構的搭建,代碼模塊化/復用等等。

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

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

1.目的

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

2.適用場景

當產品的 story 顆粒度過大時,開發人員必要將 story 進一步細化。

3.所需資源(與需求討論的資源同等)

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

4.操作體例

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

5.詮釋/說明/tips

產品經理不要太過于干涉技術人員的拆分,在不涉及原則的情況下,他們開發怎么恬逸就隨著他們來吧。

優先級排序

1.目的

開發人員在一個迭代內,對開發內容進行排序。

2.適用場景

在「需求拆解」后,很天然的進入到優先級排序。

3.所需資源(與需求討論的資源同等)

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

4.操作體例

在多方討論下,將已經拆分成顆粒度適宜的 story 進行排序。

三. 產品的「1,+∞」

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

旅行地圖

1.目的

用戶調研數據處理,確定產品的優化點與優化需求。

2.適用場景

用戶調研數據處理。

3.所需資源

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

4.操作體例

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

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

迎接關注微信公眾號:「UXD-Cloudhub」


[教程作者:互聯網]
免責聲明:本站文章系圖趣網整理發布,如需轉載,請注明出處,素材資料僅供個人學習與參考,請勿用于商業用途!
本文地址:http://www.77356051.com/Tutorial/di3925.html
UI UX設計師應該學習的用戶生理學原理
談產品的差異化思路進可攻退可守
圖趣網微信
建議反饋
内蒙古时时彩走势图