讓溝通變得友好的用戶故事地圖如何創建?
“用戶故事地圖”以直觀易變的方式進行項目的良好溝通,大多數人看重的是地圖的形式部分,橫向是講述大故事的部分,縱向是逐步的細化,但是最關鍵的是產品的構思框架,讓團隊成員對想要做出的產品一目了然,大大提高了團隊之間相互協作的默契度。
一、用戶故事地圖是什么?
1、瀑布模型
圖(1)
在進入正題前,讓我先來講講敏捷開發的誕生。在很早以前的軟件開發中,并沒有系統的流程管理方式,所以造成大量的人員、時間以及金錢的浪費。于是,在1970年,一個叫做溫斯頓·羅伊斯的人提出了針對于軟件開發的一種架構,叫做“瀑布模型”,他把大型軟件開發分為:分析與編程,像工廠流水線一樣把軟件開發過程分成各種工序,流程如上圖(1),之后,“瀑布模型”便沿用下去。但是隨著時代的進步,人們的需求越來越多,軟件迭代越來越快,“瀑布模型”的缺點暴露的也越來越明顯:因為這種“一去不復返”的流程中沒有迭代與反饋,應變能力差,所以對客戶需求非常不容易適應,只要有一處修改,就意味著前面的工作都白做了。所以“瀑布模型”逐漸被淘汰,一種叫“敏捷開發”的管理新模式應運而生。
2、敏捷開發的優勢
圖(2)
敏捷開發避免了傳統瀑布方式的弊端,主要是吸收了各種新型開發模式的“動態”特性,敏捷開發把關注點從文檔轉移到了開發者,管理方式也從工廠的流水線到團隊的自我放松式的組織。在這種模式下,客戶的需求可以隨著進程的推進和實際情況而改變,團隊輸出的產品也是“最小可行產品”(MVP),即可以產生預期成果的最小發布方案。這樣,就大大降低了成本,提高了靈活性,減小了風險,修改起產品也不需要全盤重做。所以,“敏捷開發”模式一直沿用至今。
3、用戶故事地圖的誕生
在以前,人們確定項目時總要寫厚厚的幾大本說明,好讓開發人員對要做的東西有統一認識,但很快,這種充滿條條框框的說明就被淘汰掉了,取而代之的是“敏捷開發”模式中的“用戶故事”。當然,這并不代表人們不用再寫那些惱人的文檔,“用戶故事”的創建依然要有文檔作為依據,只不過文檔的篇幅和格式已經大大優化。通過“用戶故事”這一步驟,避免了團隊成員的主觀影響,可以客觀的搜集整理大量用戶需求,形成一個個用戶問題、客戶問題、公司問題的解決方案。
但是問題又來了,因為對于大型產品的開發,用戶需求的內容會很多,像是一個龐大的地圖,而“用戶故事”擅長聚焦于構建小的特性,專注于小的細節就沒法掌握整體,所以會帶給人們困惑,不知何時才能完成開發和發布。不同的用戶故事塊也容易出現互不相匹配的產品部分,所以,為了避免這種管中窺豹的錯誤出現,人們改進了用戶故事的處理方法,這種新的方法就是“用戶故事地圖“。下面,就來介紹如何創建用戶故事地圖。
二、如何創建用戶故事地圖?
1、前期準備
召集3-5名產品核心人員,可以包括產品負責人、項目經理、業務分析師、架構師,因為這些人代表了項目中的主要角色的看法,所以創建出故事地圖后,在以后的全體計劃會上就可以避免出現許多不必要的辯論。準備一面空出的白板,或一面墻壁,若干顏色和數量的便利貼,一卷彩色膠帶。
2、整理創意框架
在正式開始創建用戶故事之前,大家要在一起重新明確產品的創意框架,如:
- 明確產品的目標是什么?
- 能為用戶解決哪些問題?
- 公司、用戶都能獲得哪些收益?
然后大家統一答案,把明確的目標寫在便利貼上,按照優先級排好順序。
3、刻畫用戶畫像
下面針對優先級最高的目標開始討論,開始頭腦風暴:
- 產品面向的主要用戶群是那些?
- 產品的潛在用戶群有哪些?
- 誰會為我們的產品付錢?
基于這些問題,羅列不同類型的用戶,討論他們能從中得到什么好處,使用的動機,需要的功能等。精煉出若干類用戶,制成“用戶畫像”卡片,卡片上的內容不用很詳細,可以描述出基本特征即可,給每個類型的人群起一個人的名字,張三李四隨意,目的是方便日后討論,以后這個名字就代表這一類人群,再對每個用戶做一下簡單的訴求描述。最后,把這些寫著用戶類型的卡片,按照優先級排好,重要的用戶放在上面,貼在白板上。
為了講解的更加清晰,我把之前參與過的一個項目當做例子,演示“用戶故事地圖”的產生過程:這是一款大學生的微電影服務平臺,我們的初衷是想要“大學生影視團隊”和“有拍微電影意愿的人”在平臺上對接起來,由于攝影團隊所駕馭的影片難度低,需要的資金少,所以我們的目標很可能包括這些:“學生拍畢業季微電影“”學校社團宣傳“”婚禮開場微電影烘托氣氛“等等(下面我所繪制的用戶故事地圖只是想讓大家看起來更直觀,如果有不嚴謹之處還望大家見諒)。
4、大故事
從最重要的用戶類型下手,這里依然使用頭腦風暴,可以按照時間順序挖掘,描述這個人在一天中使用產品的情景,“首先他會怎樣,然后怎樣,然后……“這些故事可以比較概括,如“用戶注冊”或“修改日程”,團隊中安排專門的人負責記錄把每一件事都寫到一張便利貼中,按照時間順序從左到右排好便利貼。當有遺漏的故事被挖掘出來時,可以隨時調整卡片順序。在這個過程中,做到了團隊成員對所要做的東西達成了一致,產品創意精彩的細節部分被所有人所消化。
下圖以其中的一個用戶類型為例,寫出大故事:
5、深挖細節
在完成第五步的“大故事”后,“用戶故事地圖”的框架已經結束,下面要做的是深挖細節。白板上的卡片已經出現了第一列,這些都是大故事,我們要在每一個大故事上深挖,寫出包括的細節:
- 用戶在這一步具體要做什么事情?
- 用戶在這一步還有其他選擇么?
- 如何做才能更符合用戶的習慣?
- 出現問題時如何解決?
在完成以上等等問題后,記錄員要把每一個小細節都寫在便利貼上,豎向排列在“大故事”卡片的下面,如果有與大故事無關的其他細節,可以放在“用戶卡片”的上方區域。到此為止,一個巨大的恐龍骨骼一樣的“用戶故事地圖”出現在白板上,甚至,它可以占滿一面墻。
6、劃分MVP發布計劃
在第五步我們所創建的“用戶故事地圖”涵蓋了多個用戶故事和敘事主線,包含了項目人員所有的愿景,但是它太龐大了,如果同時研發這些功能點,可能幾年時間都做不完,“敏捷開發”也不允許我們這么做。所以,為了縮短項目周期,我們要在“用戶故事地圖”上進行MVP的內容篩選,把最重要的內容放在前面。橫向移動用戶目標,縱向移動深挖出的細節,然后用膠帶做出分隔,如下面這個例子,在第一個版本中,我只開發標號為1的部分,隨著軟件的不斷迭代,用戶故事地圖也不斷向下推移。此時已經完成了這個產品的發布路線圖。
三、說在最后
“用戶故事地圖”以直觀易變的方式進行項目的良好溝通,大多數人看重的是地圖的形式部分,橫向是講述大故事的部分,縱向是逐步的細化,但是最關鍵的是產品的構思框架,讓團隊成員對想要做出的產品一目了然,大大提高了團隊之間相互協作的默契度,但是要注意的一點就是,功能的開拓要適度,否則這幅用戶地圖永遠都畫不完。正如《用戶故事地圖》的作者Jeff Patton所說:“如果不需要討論,就不必繪制用戶故事地圖?!?/p>
本文由 @孫昊 原創發布于人人都是產品經理。未經許可,禁止轉載。
- 目前還沒評論,等你發揮!