一次裂變活動策劃分享
編輯導語:在進行產品或項目規劃時,我們需要先了解項目的具體需求、最終目的、當前背景等各方面,尤其作為產品新人,在進行產品功能設計時,更需要理清思路,做好規劃。本篇文章里,作者分享了他初次接手一個裂變活動時的策劃經歷,一起來看一下。
在需求評審的時候,我們都希望自己設計的功能能夠得到上司的表揚,能夠得到周圍同事的認可。但如果我們設計產品的時候思路不清晰,就有可能會說服力不強,被其他人的問題問住。這里我分享給大家我自身一次裂變活動功能策劃的經歷。
一、確定項目背景目標
當時我接到的入職后第一個項目是:設計一個公開課裂變功能。
拿到一個具體的項目之后,首先需要知道為什么要設定這樣的項目?項目背景、目標是什么?
這個項目背景是公司目前流量獲取成本非常高,產品增長出現瓶頸。為了降低公司流量獲取成本,本次產品版本迭代需要加入一個裂變小功能。項目目標是增加裂變名片數量。
二、目標拆解,使目標更加明確
對目標進行拆分,可以使不明確的任務變得的更加明確,做事會更加有思路和方向。
圖:項目目標拆解圖
從項目目標拆解之后的結果來看,分享著人數、分享頻率、被分享者人數、以及轉化率都可以作為設計出發點和決策因素,在梳理場景的過程中,就需要著重考慮到這些出發點。
三、裂變場景梳理,尋找機會點
梳理完真實業務現場中流量轉化過程中的細節之后,就要以調研事實為依據,開始腦暴梳理分享者對應的場景和需求,排列出需求優先級,選擇優先級最高的需求做深入設計。
這次還是主要以體驗課學員這類新用戶的裂變為出發點,理由有兩個:
- 公司目前這類用戶占比較多并且并沒有充分利用。
- 由于自己去售前現場調研過,還未調研過售后現場,對體驗課學員和正價課預報名學員稍有了解,而對正價課學員的上課流程還未有充分了解。
分享者場景梳理如下:
圖:裂變場景的梳理思維導
圖中,分支按照用戶-場景-需求機會點這樣去排序梳理,先去不斷發散思路,不要急于否定自己的前期想法,下一步才是整理匯聚。其中用紅色標出裂變場景機會點。
四、排列出優先級,選出這次優先做的場景
站在活動分享者的角度梳理完場景之后,開始排列具體的需求優先級,如何排列優先級,從這幾個維度出發:
- 需求頻率和分享人數量;
- 開發難度和效果;
- 分享意愿強度。
維度占比得分:1-5分,每種維度得分:1-5分。
總分=維度占比得分*每種維度得分。
最終參考結果去考慮先做哪種場景。
結果做出直觀的表格如下:
表格梳理完成后,就得出了一份還算比較客觀的評價依據。
其實這里列出嚴謹的表格的好處就是,在需求評審的時候你可以有理有據說出為什么先選擇這樣的需求去做,更加具有說服力。但是也不要完全參照表格之中的優先級排序,還是需要根據實際情況進行場景的篩選。
最終選擇第一個版本做買一贈一活動,也就是購買付費公開課的用戶可獲得一次免費贈送好友的機會??傮w來說這個活動場景面向的活動參與人數最多。先不用追求完美,快速上線一個活動測試效果,未來再逐漸將活動覆蓋至每種細分場景。
五、流程圖與原型圖
1. 流程圖
在選擇好具體要去設計的場景之后,接下來的流程圖的繪制是重中之重,一定不可以省略。因為只有流程圖梳理通了,后面的原型和需求評審才會比較容易。并且流程圖也能夠讓參與者明確知道業務是如何運作的。
畫流程圖前應該梳理清楚這幾個要素:
- 用戶:有多少種類的用戶會參與其中?系統也可作為參與者。
- 事項:這些用戶要完成的事情分別是什么?
- 數據:在這個過程中數據是怎么流轉的?
- 特殊狀態:萬一出現問題了,該怎么處理?
圖:流程圖
其實要展現哪些流程圖也沒有非常固定的規則,還是要根據實際項目去評判,就例如我目前做的裂變工具,裂變進來的流量如何入庫以及如何給售前跟進是流程中需要重點去考慮的。但如果是電商類的產品,則需要更多去考慮各種特殊狀態該怎么處理。
流程圖的最終目的還是為了能夠和開發更好的交流,只要達到這個目的就好。
2. 原型圖
當流程圖梳理的通順了,原型圖也就非常簡單了。在流程圖中具體數出來需要畫原型的有多少個頁面,與業務流程一致,頁面結構清晰,界面統一。
這里就不花過多的時間贅述原型設計的細節了,本文的重點還是在新人產品做功能設計的基本流程套路。
六、PRD文檔
當流程圖、原型圖都確定之后,就需要將這些撰寫成PRD文檔。
PRD文檔就是產品需求文檔,主要是一份供技術人員閱讀的文檔,他們需要參閱這份文檔進行產品的視覺設計與開發。所以PRD文檔中最核心的部分,就是功能部分的描述,需要考慮到各種異常情況與產品細節??紤]到的越多,開發的速度就越高,質量就高。
每個公司和團隊情況的不同,文檔也會有微小的差異。但總的來說一份完整的PRD文檔通常包含以下幾個部分:
- 需求簡介(需求背景、產品特點);
- 功能詳情(產品功能結構圖、業務流程圖、頁面流程圖、主要功能描述);
- 性能要求;
- 產品運營計劃。
之前說到過功能詳情部分的描述是PRD文檔的核心,是占大頭的地方。一個非常簡單的評判標準就是看字數。字數越多,考慮到的狀況就越多。這里我總結了在描述功能的時候,通常包括以下幾種類型:
- 取值規則:即產品前端的字段取的是對應的什么字段。
- 限制:包含顯示的范圍、極限值、格式、排序等。
- 狀態:默認狀態、常見狀態、特殊狀態。
- 操作:常見操作、特殊操作、誤操作。
- 反饋:包括提示、跳轉、交互等。
在剛開始寫需求文檔的時候,會發現自己總是會考慮的不全面,寫出的文檔經常被各方挑出毛病,這是非常正常的狀況。遇到這種情況千萬不要氣餒,因為這正是不斷試錯和快速成長的機會。多去聽聽各方意見,自己新建一份復盤文檔,把所有的問題及時寫進去,下次盡量避免。
可以看到我第一次寫的復盤文檔,真的問題很多~但也必須經歷這樣的過程,才能得到成長~
圖:我的復盤文檔
七、總結
作為一個新人,很能體會新人產品在最初拿到任務的時候,內心的不知所措。
這個時候千萬不要一上來就開始干,一定要捋清楚自己的思路,列出一步一步的規劃,在腦中形成做事的框架,并且不斷地反思、總結、優化這個框架,這樣才會效率越來越高。
本文由 @小貓雯 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
專欄作家
貓雯私域研究社,微信公眾號:貓雯私域研究社,人人都是產品經理專欄作家。專注于客戶關系管理研究,包括私域流量運營、社群運營、用戶運營等細分方向。
本文原創發布于人人都是產品經理,未經作者許可,禁止轉載
題圖來自 unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
同求流程圖,可以發一份清晰的學習嗎?謝謝
流程圖可以發一份清晰的嗎
贊一個??
感謝!??