以用戶體驗五要素的思路，如何編寫產品需求文檔（PRD）
Baklib
關注
2022-04-21 16:25
606次閱讀
一份優秀的PRD能夠幫助你獲取資源，有效推進項目，獲得團隊成員的信任。 今天就和大家聊聊如何寫好一篇PRD，希望能夠提供給大家一些干貨。
PRD全稱Product Requirement Document，中文名產品需求文檔，歷史上第一份PRD據推測應該是誕生于寶潔這家公司，因為據史料記載，寶潔在二十世紀二三十年代第一次提出了產品經理的概念，并誕生了第一位產品經理，所以通過合理的邏輯推理，應該也誕生了第一份PRD，只是因時間久遠且沒有更多的細節資料而無從考證。
隨著互聯網行業的發展，產品經理崗位的發展成熟，產品經理的工作職責逐漸的清晰明了，PRD也終于在歷史長河的演變過程中，慢慢形成了產品工作流程當中不可缺少的一環，那么到底什么是PRD呢?
可以概括為，PRD是對產品需求以實際可落地方式進行細化描述的文檔。
這里面有個關鍵詞“實際可落地”，也就意味著閱讀者通過查看PRD能夠大致知道需求會最終以什么樣的實際形態或方式被呈現出來，而不是說看完了PRD以后，依然不知道需求會被做成什么樣或者說感覺需求還只是停留在一種概念性的層面。
那怎樣去實際落地，這里就涉及到另外一個問題，就是PRD是給誰看的。
一般來說，PRD是寫給以下幾種人看的：
1.產品同事
2.運營
3.設計師
4.開發工程師
5.其他需求方(相關業務部門等)
為什么要說圍繞用戶體驗要素來編寫PRD，因為產品的設計是圍繞著這個經典的框架來的，那寫PRD的任務當然是要把這個內容向大家表述清楚。
其實不僅僅是做產品，任何事情，第一步肯定是要想清楚要做什么，為什么要做，也就是把戰略層描述清楚，PRD的第一部分就是要把這塊內容說清楚，回答出下面的問題。
1）用戶要獲得什么？—— 用戶痛點、需求
建議這塊內容，說清楚整體的問題痛點，同時也要舉具體case，列舉數字，如用戶的使用頻次，現在的花費等等。
2）用戶是誰？—— 用戶細分、用戶數量、畫像
用戶是誰，并不是如“商家用戶”這種粗線條的描述，要說清楚對于當前的功能，是哪類用戶在什么場景下的需求，用戶的量級是怎樣的，有一個相對具體的畫像。
3）用戶能通過這個得到什么？ —— 用戶收益
這里面補充個內容，俞軍老師曾說過，用戶凈收益=新體驗-舊體驗-替換成本，替換成本可能是獲取成本、認知成本、資金等等， 雖然這些內容并不是真正可衡量的，但在做一款新產品評估其價值時，可以從這幾個角度進行思考。
4）我們能得到什么？—— 對企業能帶來什么收益
這點很重要，做任何產品，給用戶賦能，給用戶帶來價值，其主要目的還是企業自身能夠盈利，這點想清楚才能說服老板提供資源呀。
模板： 1.需求背景 描述目前存在的問題，業務痛點或用戶痛點（建議有具體數字、案例） 2.目標用戶（為誰解決問題，用戶畫像越具象，問題會描述地越清楚） 3.需求目標（要解決什么問題） 4.需求收益（解決問題后能產生什么收益，衡量標準）
最抽象的戰略層說清楚了，下一步就要大體說下為了實現上面列舉的各種想法目標，要一步一步怎么做了，也就是說清范圍層的內容。
1）功能&信息結構圖
范圍層，就是要說清楚，為了實現戰略做什么事情，什么功能，提供什么內容。這塊一般會通過腦圖或者框架圖來展現，說清楚我們需要哪些數據，做哪些功能，各個功能與功能之間的關系。
要注意，這部分需要在長遠角度，解決這個問題地整條路線進行思考。舉個例子吧，比如要做個評論功能，讓用戶對產品更了解，并帶來更多銷量。那第一步先增加評論功能，之后可以對評論進行分析，為用戶推薦高質量的產品，發現問題產品保證平臺產品質量等等。類似這樣，出一個整體的規劃藍圖。
2）路線規劃
藍圖出來了，還是要落地的。所以這一步要把剛才地藍圖，切成一塊一塊，每一步要做什么，多長時間，這個階段解決怎么的問題，為后面提供什么鋪墊。有些內容，也可以出一個簡易的DEMO圖，能描述清楚即可。
模板： 1.功能結構圖、信息結構圖（腦圖、框架圖） 要從長遠的考慮去思考產品的形態 2.路線規劃 沒一起完成的內容，解決的問題以及期望上線的時間
這一部分是對當前這一期要做的內容的詳細描述了。這部分面向的主要用戶是UI、交互、開發、測試同學，具體到做事情上，就是把大家的認知拉齊。
1）產品流程圖
通過圖的方式，可以快速、方便地告知PRD的每個用戶這個功能的思路流程。這里最開始放的是比較粗線條的流程圖，比如買家購買商品，加入購物車->付款->商家發貨->確認收貨。而一些細節，比如買家超時未付款，或者賣家修改價錢等等，可以到具體寫到這個功能點地時候再出一個細化的流程圖。
2）DEMO，原型制作，這個就不用多說。
3）UI稿，這塊是UI同學完成后，放上來，統一相關資料的獲取入口。
4）產品功能點，后面來細說。
這塊就是要把功能說得足夠細，但也是有一些技巧。
1）更新說明
首先，我一般會在功能最上方，列出更新的清單，一般記錄有：調整時間、調整功能塊、詳細說明。
2）全局說明
每期功能可能會有多個頁面多個功能塊，但有一些想通的地方，比如對于數據產品，數字的展現形式，保留2位小數，增加三分位符號等；對于移動端產品，一些操作方式等。這個適用于各個塊，不用分別在每個中單獨說明，而且后續做其他功能都是可以復用的，可以先列出來說清楚。
3）具體每個塊的功能說明
- 前置條件：有些功能可能會有這個內容，在什么情況觸發這個功能，比如在用戶購買什么商品后提供某個功能；
- 主體功能說明
- 流程描述：主流程、分支流程，這個就可以使用上面介紹的UML圖，把主線條描述清楚；
- 界面描述：操作、文案，文案建議其他顏色標注出來，防止和描述弄混；
- 業務規則：這個是在界面看不到的，比如限制條件、表格的排序規則、需要記錄的數據、還有一些數字的計算公式等等；
- 異常描述：這個不能忽略，尤其是C端產品，考慮需要更為全面，因為很可能就是一個小異常，就導致用戶使用不爽而流失，比如上傳文件沒有考慮超出大小怎么辦，用戶上傳后一直沒反應，就會認為這個產品不好用，轉而使用其他產品，所以，異常地考慮很重要。列幾個常見的異常：如未輸入、輸入錯誤、無數據，無網絡，長時間未操作，異常退出等等。
最后說下寫這塊內容的原則
- 完整：足夠細，考慮足夠周全；
- 無歧義：RD同學是拿著這個文檔真真切切寫代碼，所以說得內容，要能夠落到代碼上，比如用戶一段時間未操作則提示。。。，等待多長時間，要寫清楚；
- 有條理：這文檔是有人看的，所以序號、符號都適當的用上，讓你的文檔容易閱讀；
- 及時更新：功能、DEMO的調整，都需要落到PRD上。
因為我本人是數據產品的產品經理，所以這一部分對于我們很重要，需要哪些維度、哪些指標，指標的來源庫表字段、計算口徑是什么，這些都要清晰地記錄下來。
除此之后，有個內容可能經常會被忽略，就是數據的整理。以某寶的搜索結果頁為例，一般會展示圖片、標題、價格、銷量、賣家名稱、包郵會標記出來，這些RD通過UI稿可能會查看到，但有一些比如鼠標移入顯示信息，點擊操作、是否購買過，都在商品展示時體現出來。
這些內容，我們可不能指望RD同學從UI稿中一點點發現。所以列出這樣的表格，把你認為需要的類及其屬性列清楚，有點類似我們上面類圖中對象屬性要描述的內容，目的是讓開發同學對照這個來進行庫表設計，不要遺漏某些點。
包括按鈕的埋點&內容的埋點，可以通過截圖+表格說明的方式，截圖標明需要埋點哪些控件，表格說明對應控件的什么信息，如操作PV、UV、輸入內容等。
對于C端產品，這塊內容會更加重要，一般會有個灰度發布過程，因此需要說清楚灰度發布的方式，放量安排、節奏，需要關注的指標，這個指標如何進行評估，達到什么樣程度可以全部上線。
OK，大功告成了。
最后說一點：PRD的存放。
我嘗試過幾種方式，之前就在axure中完成，在DEMO的右側進行說明，但這個不好的是：在進行更新后，還要發送給大家，各個版本的存放加上axure本身下載解壓就比較麻煩，所以并不是最佳方案。
可以用知識庫來完成，這里推薦Baklib來搭建知識庫。只要一個鏈接，更新后只要告知大家同步下信息就好，就是在寫功能時候，需要把DEMO對應圖貼上去，RD能夠比較方便知道是對哪塊內容的描述。
對于上述內容，可以使用Baklib創建2個站點進行記錄，一個記錄需求概述和產品規劃部分內容；一個記錄產品功能及之后的內容，這個是當前這期的事情。一個總分的結構。
希望這篇寫PRD的一些經驗總結對大家有幫助。不過，這個PRD的編寫并不適于所有公司，一份完善的PRD需要花費比較多的時間，對大公司來說，對接方比較多，很有必要這樣一份文檔統一各方的認知；而對于創業公司，將產品快速落地投放市場進行驗證更為重要，所以這個時候千萬不要把時間花費到PRD上面。
Baklib
+
關注
0
