超周全!關(guān)于用戶故事地圖的7種用法
金蝶云之家體驗中間交互設(shè)計師-方馨月:之前讀完 Jeff Patton 的《用戶故事地圖》覺得是一本好書,但是一向沒有機會去實踐。
最近在工作中使用了用戶體驗地圖進(jìn)行云之家工作匯報輕應(yīng)用的開發(fā)評審,發(fā)如今討論過程中,思路更加清晰、交流更加順暢了。
詳細(xì)體現(xiàn)在:
- 開發(fā)人員能夠很容易發(fā)現(xiàn)產(chǎn)品設(shè)計的題目。
- 小組成員的參與度更高。
- 決策更加敏捷,會議更加高效。
- 會議結(jié)束后,有寫意的討論效果產(chǎn)出。
會后,更加覺得用戶故事地圖是一個可以進(jìn)步協(xié)作服從的工具,所以,想寫一篇“讀書筆記&實行思考”,來記錄這段時間的收獲。
《用戶故事地圖》不僅僅是講述什么是用戶地圖、怎么使用用戶地圖,也講了許多團(tuán)隊協(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ù)以上三個方面,細(xì)致進(jìn)行說明。
兩點詮釋:
- 我很粗暴的根據(jù)「是否必要開發(fā)人員介入」這一條件,將產(chǎn)品發(fā)版前分為兩部分,即產(chǎn)品的「0,0.5」,產(chǎn)品的「0.5,1」。在開發(fā)人員介入前,更多的是產(chǎn)品經(jīng)理如何進(jìn)行產(chǎn)品設(shè)計,產(chǎn)品整個的基調(diào)和走向都是在這一部分定下來的。當(dāng)開發(fā)人員開始介入后,就詳細(xì)聚焦于功能的實現(xiàn)方面了。能否實現(xiàn)?如何更好的實現(xiàn)?是這一部分的重要題目。但是要解決這一部分的題目的一個大前提就是,開發(fā)人員如何周全的理解這個產(chǎn)品?讓大家腦海里的東西是同等的?這個是最艱難的題目。
- 上面三點的「產(chǎn)品」,其實不僅僅指的是一個完備的產(chǎn)品,也可以是一個組件、一個大型功能??傊潜匾M(jìn)行思考、設(shè)計、開發(fā)并之后會有維護(hù)升級的一個模塊。
一. 產(chǎn)品的「0 ,0.5」
當(dāng)產(chǎn)品或某一個大型模塊在進(jìn)行功能設(shè)計的時候,可以采取用戶故事地圖的體例來梳理所有的功能點,并進(jìn)行迭代周期的規(guī)劃。
新產(chǎn)品功能規(guī)劃之產(chǎn)品全景圖
1. 目的
建立產(chǎn)品/模塊的全局印象,有全局觀,進(jìn)而可以團(tuán)體規(guī)劃產(chǎn)品/模塊。
2.適用場景
產(chǎn)品經(jīng)理(可能搭配交互設(shè)計師)梳理產(chǎn)品框架。
3.所需資源
- 2-3名參與人員(需原諒產(chǎn)品設(shè)計者、產(chǎn)品決策者)。
- 卡片/便利貼,筆。
4.操作體例
- 一邊討論,一邊將想要的功能寫在卡片上。
- 一邊討論,一邊將將功能分類,按照x軸為模塊名稱,y軸為所屬模塊下的功能進(jìn)行排列。
- 一邊討論,一邊調(diào)整當(dāng)前的布局(可剔除/添加卡片、調(diào)整卡片位置)。
5.詮釋/說明/tips
1)為什么是2-3小我?
對于有的項目,產(chǎn)品設(shè)計人和產(chǎn)品決策人是一小我,為什么還必要2-3小我呢?由于在我看來,一小我的想法是無法做到完美的,但是假如是兩小我合作則可以避開90%以上的產(chǎn)品漏洞,所以在產(chǎn)品功能規(guī)劃的方面,更建議2人以上(當(dāng)然假如碰到牛人,思維無漏洞,一小我建立產(chǎn)品全景圖也是沒任何題目的)。不建議3人以上,則是由于對產(chǎn)品指手畫腳的人多了,只會越來越亂,產(chǎn)品設(shè)計層面,要少而精。
2)假如只是理個產(chǎn)品邏輯,為什么不用腦圖:
從操作體例也可以看出,這是一個必要團(tuán)隊合作的過程。腦圖更像是一小我的思維梳理,不利于多人的團(tuán)隊合作??ㄆ暮锰幵谟冢?/p>
- 所有人都有調(diào)整布局的權(quán)限。
- 沒有了屏幕的限定可以支持高復(fù)雜度的產(chǎn)品架構(gòu)。
- 可以更方便的刪減和備注。
- 為了后續(xù)的操作。
新產(chǎn)品功能規(guī)劃之大家來找茬(功能點設(shè)計)
1.目的
對于關(guān)鍵的功能點或有爭議的功能點,可以拿出來大家一路討論,進(jìn)而明確功能點的詳細(xì)操作流程,削減踩坑的可能性。
2.適用場景
確定某個有爭議的功能點的設(shè)計。
3.所需資源
- 3-4名參與人員(需原諒產(chǎn)品決策者、產(chǎn)品設(shè)計者、用戶體驗設(shè)計師)。
- 產(chǎn)品全景圖。
- persona卡片 及 scenario卡片。
- 不同顏色的卡片/便利貼,筆。
4.操作體例(以功能點A的設(shè)計為例)
- 圍繞A,各參與人員站在本身的角度,思考A在流程中可能出現(xiàn)的情況與題目,挑刺與找茬。
- 圍繞A,根據(jù)剛剛點意見,優(yōu)化流程或提出更好的體例。
- 將討論效果在不同顏色的卡片/便利貼上寫出,貼在功能點A的旁邊。
5.詮釋/說明/tips
- 肯定要圍繞A,跑題太可怕,降低會議服從且達(dá)不到目的。
- 肯定要得出效果,更好的方案/保持當(dāng)前方案不變。
發(fā)布規(guī)劃
1.目的
優(yōu)先級排序,劃分發(fā)布路線圖。
2.適用場景
產(chǎn)品經(jīng)理(可能搭配交互設(shè)計師)確定產(chǎn)品發(fā)布內(nèi)容。
3.所需資源
- 2-3名參與人員(需原諒產(chǎn)品設(shè)計者、產(chǎn)品決策者)
- 產(chǎn)品全景圖
4.操作體例
- 按照產(chǎn)品的長線目標(biāo),對功能排優(yōu)先級。
- 制訂產(chǎn)品發(fā)布計劃,確保每一次的發(fā)布內(nèi)容都是 MVP。
5.詮釋/說明/tips
- 如何排列優(yōu)先級?
我覺得書里面有一句話能夠很充分的回答這個題目:
聚焦于成果,即產(chǎn)品發(fā)布后用戶能使用和感知的東西,切分發(fā)布計劃應(yīng)該以成果為導(dǎo)向。 ——《用戶故事地圖》P56
- 怎么劃分發(fā)布周期?
同樣也是聚焦于成果,每一個發(fā)布的版本盼望能夠達(dá)到什么樣的結(jié)果,再就是,保證 每一個版本都是當(dāng)前情況下的 MVP。
二. 產(chǎn)品的「0.5 ,1」
當(dāng)產(chǎn)品形態(tài)及功能確定后,則進(jìn)入到需求確認(rèn)階段。這個階段是必要產(chǎn)品的所有參與者參與其中的,但是重要以開發(fā)人員為主,確認(rèn)產(chǎn)品功能的可實現(xiàn)性。
需求討論 —— 大家來找茬
1.目的
與開發(fā)人員正確、高效地確認(rèn)需求。
2.適用場景
產(chǎn)品的某一個迭代,必要確認(rèn)需求。
3.所需資源
- 7名以內(nèi)項目參與人員(需原諒產(chǎn)品設(shè)計者、用戶體驗設(shè)計師、開發(fā)人員),開發(fā)團(tuán)隊負(fù)責(zé)人必須參與,其他開發(fā)人員盡量參與(假如人數(shù)超過7人,可以采用金魚缸協(xié)作模式)。
- 產(chǎn)品全景圖。
- 迭代功能的較細(xì)致文檔(可能是word文檔、可能直接是設(shè)計稿、可能是更詳細(xì)的故事地圖)。
4.操作體例
- 各參與人員站在本身的角度,思考各功能點在流程中可能出現(xiàn)的情況與題目,挑刺與找茬。
- 根據(jù)剛剛點意見,優(yōu)化流程或提出更好的體例。
- 將討論效果在不同顏色的卡片/便利貼上寫出,貼在功能點的旁邊。
5.詮釋/說明/tips
1)為什么必要產(chǎn)品全景圖?如許做有什么益處?
產(chǎn)品全景圖可以幫助開發(fā)人員建立整個產(chǎn)品形態(tài),能夠完全清楚當(dāng)前的團(tuán)體的開發(fā)內(nèi)容,利于架構(gòu)的搭建,代碼模塊化/復(fù)用等等。
2)必要細(xì)致的一點:在此過程中必要控制住,盡量不要延長出新功能,也不要大范圍的修改功能。假如大范圍的修改了功能,也不建議直接以會議效果為最閉幕果。由于本來的方案是經(jīng)過深思熟慮的,而在會議上,人太過于愉快的狀況下容易沖動,岑寂下來再思考一下方案也會發(fā)現(xiàn)會議上的效果可能會存在許多漏洞。
需求拆解 —— story 下的 story 細(xì)分
1.目的
將當(dāng)前的 story 細(xì)分為開發(fā)人員可以接受、方便開發(fā)的 story。
2.適用場景
當(dāng)產(chǎn)品的 story 顆粒度過大時,開發(fā)人員必要將 story 進(jìn)一步細(xì)化。
3.所需資源(與需求討論的資源同等)
- 7名以內(nèi)項目參與人員(需原諒產(chǎn)品設(shè)計者、用戶體驗設(shè)計師、開發(fā)人員),開發(fā)團(tuán)隊負(fù)責(zé)人必須參與,其他開發(fā)人員盡量參與(假如人數(shù)超過7人,可以采用金魚缸協(xié)作模式)。
- 產(chǎn)品全景圖。
- 迭代功能的較細(xì)致文檔(可能是word文檔、可能直接是設(shè)計稿、可能是更詳細(xì)的故事地圖)。
4.操作體例
- 在多方討論下,將大的 story 按照開發(fā)必要進(jìn)行拆分。
- 將拆分好的 story 寫在卡片/便利貼上,貼在對應(yīng)大的 story 下方/旁邊。
5.詮釋/說明/tips
產(chǎn)品經(jīng)理不要太過于干涉技術(shù)人員的拆分,在不涉及原則的情況下,他們開發(fā)怎么恬逸就隨著他們來吧。
優(yōu)先級排序
1.目的
開發(fā)人員在一個迭代內(nèi),對開發(fā)內(nèi)容進(jìn)行排序。
2.適用場景
在「需求拆解」后,很天然的進(jìn)入到優(yōu)先級排序。
3.所需資源(與需求討論的資源同等)
- 7名以內(nèi)項目參與人員(需原諒產(chǎn)品設(shè)計者、用戶體驗設(shè)計師、開發(fā)人員),開發(fā)團(tuán)隊負(fù)責(zé)人必須參與,其他開發(fā)人員盡量參與(假如人數(shù)超過7人,可以采用金魚缸協(xié)作模式)
- 產(chǎn)品全景圖
- 迭代功能的較細(xì)致文檔(可能是word文檔、可能直接是設(shè)計稿、可能是更詳細(xì)的故事地圖)
4.操作體例
在多方討論下,將已經(jīng)拆分成顆粒度適宜的 story 進(jìn)行排序。
三. 產(chǎn)品的「1,+∞」
當(dāng)產(chǎn)品的出版發(fā)布后,后續(xù)的工作就是優(yōu)化和更新了。在此階段可能會進(jìn)行用戶調(diào)研,那么調(diào)研的數(shù)據(jù)如何進(jìn)行處理才能夠反映更多的題目呢?這里提供一種體例,在用戶故事地圖中被稱作 journey map (也就是 experience map ),但是在其基礎(chǔ)上做了一些些調(diào)整。在上面疊加了情緒版的使用方法。
旅行地圖
1.目的
用戶調(diào)研數(shù)據(jù)處理,確定產(chǎn)品的優(yōu)化點與優(yōu)化需求。
2.適用場景
用戶調(diào)研數(shù)據(jù)處理。
3.所需資源
- 目標(biāo)用戶的評價數(shù)據(jù)
- 3-7名參與人員(需原諒產(chǎn)品設(shè)計者、產(chǎn)品決策者、用戶體驗設(shè)計師)
- 不同顏色的便利貼/卡片
4.操作體例
- 用戶操作路徑,每一個觸點按步驟寫在便利貼上,在x軸排開。
- 評價數(shù)據(jù)寫在便利貼上,按照體驗良好程度,在y軸排開。
- 綜合每個觸點上的評價數(shù)據(jù),進(jìn)行打分。
- 根據(jù)得分,調(diào)整觸點卡片的y坐標(biāo)。
以上就是用戶故事地圖的 7 種用法,分別對應(yīng)于產(chǎn)品的「0 ,0.5」、「0.5 ,1」、「1,+∞」三個大的階段。盼望對大家能有所幫助。
迎接關(guān)注微信公眾號:「UXD-Cloudhub」
本文地址:http://pkvc.cn/tutorial/di3925.html