工作了也有一段時間,總算對PRD這玩意兒有個懵懵懂懂的認識,市面上教我們寫PRD的文章大多是含糊其辭遮遮掩掩過于流程化和理論化,現(xiàn)在我大概了解到撰寫的套路,結合我自己的案列在此給大家分享一篇實踐干貨型PRD.
首先來介紹下說明文檔的生成流程:
1.需求確認
2.梳理邏輯,確認產(chǎn)品所需功能
3.繪畫原型,添加說明
需求確認
需求就是做產(chǎn)品的動機缘厢、目的,其核心是為什么人解決了什么問題.
這句話牢記于心,邏輯大方向的梳理就很難出錯,用句裝逼的話說那就是"勿忘初心,方得始終".
我們要學會如何辨別偽需求和真需求,如同那個在業(yè)內說爛了的段子一樣"用戶需要一匹馬,但實際上他只想更快地到達目的地",很多時候用戶是不知道自己想要什么的,他們只會表達想要的結果(功能),而我們需要從中抽絲剝繭,找出真實需求.
需求來源方式:
1.版本的長期規(guī)劃
現(xiàn)在都流行MVP,先上線基礎功能的一期初版,后面在根據(jù)已有市場的反饋和版本規(guī)劃慢慢進行二期三期的需求確認.
這種需求一般都是真實需求、強需求,且優(yōu)先級強烈.
2.運營部門蜈缤、同事的需求.這種需求通常與活動、KPI一并到來
"哎,你看Uber有這個邀請碼,我們也搞一個唄,拉新肯定有效"
"我們的商城價格怎么沒有小數(shù)呢?這有小數(shù)多好啊"
第2種需求來源,當時就要問清楚,為什么突然要做這個功能,目的是什么?
先確認需求的必要性,不需要那就拋棄,需要那就先思考,能否用當前可用的模塊或功能去完成需求,如果不能,那就添加到需求池并加以排序.
3.用戶的反饋 or 數(shù)據(jù)分析得出的結論
需求來源3就比較有意思,"用戶的反饋"類似與來源2類似,要進行分析歸納.
"數(shù)據(jù)分析得出的結論"與來源1類似,通過百度指數(shù)、GA、GrowingIO等數(shù)據(jù)支持和已有的市場反饋進行分析,從而得來需求.
4.PM的滴水不漏和天馬行空.大部分需求都是對已有產(chǎn)品細節(jié)的完善.
前者靠經(jīng)驗凭涂、產(chǎn)品的體驗測試:
"這個搜索算法要優(yōu)化一下,特定關鍵詞增加特定商品展示幾率"
"個人中心顯示邏輯不對啊,怎么一打開就是修改地址"
后者靠思考、學習贴妻、類比:
網(wǎng)易云音樂的云盤切油、微信的搖一搖、微交互的崛起.
這次我的需求來源方式是1,即——版本規(guī)劃.
此次的需求是增加"賬戶明細"模塊,為用戶和財務雙方提供便捷的對賬功能.
梳理邏輯
做這個模塊是由于To B業(yè)務的特殊性,我們60%的客戶是選擇線下付款的,貨物直接送到用戶手中而不收錢款,在月末統(tǒng)一結賬,所以金額是有賬期的.為了避免用戶和銷售人員無意義的扯皮(財務對賬依據(jù)ERP,不以web為標準),因此推出賬戶明細功能.
梳理邏輯從需求出發(fā),先不要畫原型,先不要畫原型,先不要畫原型!
梳理邏輯就要考慮需求的使用場景(為什么用這個功能名惩、什么時候用這個功能)澎胡、使用方法(怎么用這個功能、要用那些功能)、字段數(shù)據(jù)(需要提供什么信息).
拿這次我要做的需求舉例子:為用戶和財務雙方提供便捷的對賬功能.
具體的功能就是:
1.用戶下訂單選擇支付方式,選擇支付寶微信交易,用戶的授信額度不變,使用線下付款,即貨到月結,授信額度對應的減少.
2.然后生成每一筆的交易流水,方便客戶和銷售人員對賬.
3.同時可以支持運營的活動,變相的實現(xiàn)訂單改價攻谁、返現(xiàn)稚伍、充值等功能.
那如何對賬(梳理邏輯)?
1.分析用戶使用狀態(tài)
? ?對于用戶而言,他要看到每一筆的收支金額、收支類型戚宦、購買時間等關鍵信息.
? ?對后臺而言,在對賬這一模塊,是不需要添加什么功能的,搜索用戶加篩選時間就OK,因為對賬的信息本質就是訂 ? ? ?單列表中的一些核心字段,所以后臺直接篩選訂單就可以查看用戶的所有交易流水.
? ?在運營功能性這一模塊,要添加返現(xiàn)个曙、充值、退款受楼、提現(xiàn)等操作.(其核心是對余額這一字段做增減變化).
2.有哪些核心字段?(該步驟推薦使用MindManager等工具枚舉字段信息,避免遺漏)
?3.明細信息生成規(guī)則
? ? 由于業(yè)務的特殊性,所以交易流水生成規(guī)則不像C端,以支付狀態(tài)為準,用戶付款,交易流水生成.
? ? 一開始的打算是準備以提交訂單為準,用戶一提交訂單,就生成一條新的交易流水,根據(jù)交易流水中的支付信息對 ? ? 余額進行操作.后來發(fā)現(xiàn)這種判斷方式太過草率毛躁,有很多的問題,比如:
? ? "用戶訂單提交錯了但是他自己不取消去提交新的訂單怎么辦?"——后果:交易流水會有過多的無效信息
? ? "如果采用這種方法,后臺如何判斷用戶流水?"——后果:無法判斷,不知道這條流水用戶到底要沒要
? ? 最終我使用的是:通過訂單狀態(tài)來生成交易流水,即:用戶提交訂單后臺發(fā)貨,用戶的賬戶明細才會生成新的交易 ? ? ? 流水,如此一來以上的問題便通通都解決了.
繪畫原型
關于如何繪畫原型這里就不展開篇幅一一敘述了,下次另開文章詳細講解,這次就簡要的說說繪畫原型的要點:
1.對齊對齊對齊,整體設計語言一致
對齊我認為是原型的第一要素,可能很多人都嗤之以鼻,一個原型而已,表達我想要的就行了,低保真足矣,對齊何用?
但我的理解是一個對齊的原型有助于UI的快速開發(fā),不用在UI上浪費太多的口舌,其次審美好點的PM(比如我,我就是這么不要臉~~~)直接上色高保真分分鐘的事好嗎?然后直接交付給開發(fā),UI都省去了(也就想想別當真,畢竟難度太高)
整體設計語言和對齊一樣,整個原型的通用要素一致,如按鈕都是矩形的垦搬、頂欄都是藍色的、間距都是一致的等.這樣方便UI制圖,原型一給,跟他說照著圖片上色,畢竟他不是我小棉襖,不懂我的心,我也不用過多操心,后期的毛病較少,省時間.
2.追求完美的心態(tài)
有的時候你認為原型很完美了,但是在你Boss的眼里,呵呵,呵呵呵.
畢竟這是人的缺點,對自己做的東西總是趨向于正面評價,看不到缺點.也別說一秒變小白這么高端的事情了,原型制作完畢,等個1艳汽、2個小時,時間充裕的話明天在看,你可以發(fā)現(xiàn)有很多可以優(yōu)化的地方.
從一個原型初稿到最終版經(jīng)歷個8猴贰、9次是很正常的.
3.多上上設計的網(wǎng)站,多看看潮流設計
沒有審美,那就培養(yǎng)審美.這里推薦幾個網(wǎng)站:
不會設計原型那就借鑒競品、同行,這是上手的最快方式,別不好意思.
撰寫文檔
最最重點的部分,撰寫文檔,下面我就先說說它的要點:
1.邏輯清晰,條理分明
PM最重要一項能力就是邏輯,而寫需求文檔則完美的體現(xiàn)了一個PM的邏輯層次.
說一個故事簡單,但是說一個起承轉合跌宕起伏的故事那就難了,而寫需求文檔也是如此.
先寫前端河狐、再寫后臺.
先寫模塊糟趾、再寫功能.
先定義字段、再說明生成邏輯.
這三句話是核心中的核心(如有不對,歡迎指正)
2.格式一致甚牲、還有對齊
雖然我是雙子,但是寫文檔的時候我就秒變處女(不是處男嗎,廢話當然不是).
格式體現(xiàn)了你的工作態(tài)度义郑、你的專業(yè)程度,甚至是你的工作能力.
就算你是瞎BB,開發(fā)哥哥看到這么美麗的文檔也不會說啥了(反正我是不信)
3.語言直白、通俗易懂
不要自己制造些云里霧里讓人看不懂或者有誤會的詞組詞語,多用大白話.
這方面別學蘋果,動不動就bigger than bigger,你要真這么寫了,開發(fā)會拿著他的mbp讓你知道什么叫pain than pain.
格式一致邏輯清晰語言直白,只需要注意這些,撰寫一份優(yōu)美直觀的說明文檔不再是問題.
寫了這么多,估計你們還是迷糊的,啥也不說了,冒死上工作圖.
被Boss看見我就炸了.
還是王炸.
這是word版本的,也是我所使用所熱愛的(瞎說,明明是Boss要求的).
word版本更集中于邏輯的說明,語言簡練,描述集中.
Axure版由于原型的存在,所以直觀易懂,畢竟一圖勝千言.
Axure的PRD模板如下(由@臻龍 ?PRD文檔刪減而來),歡迎關注私聊索取
說了這么多,不準備點個贊嗎,少年
未經(jīng)允許,謝絕轉載,更拒絕抄襲.
