一、PRD的使用者是誰？
首先，與大家先分享一句話：把需求文件當成一個“網際網路產品”去管理，理解它的使用者，關注它的體驗，不停迭代，使其價值最大化。（引用）
既然把它視為一個網際網路產品，那我們需要思考PRD的使用者是誰，他們通過PRD要了解什麼內容？
根據使用者以及他們的訴求。
我把PRD分成幾個階段：
1）MRD階段
這個時候，主要需要說服我們的老闆、或者團隊內部評審，也會有需求方，讓大家認同你的方案，知道你要做什麼怎麼做。
所以這個時候類似於MRD，把整個方案路線說清楚就可以，做一個較粗線條的DEMO圖。
切勿做細化的設計稿，更不要寫詳細的功能說明，因為這時候被拍的可能性很大。
2）PRD V1.0
如果通過了第一步評審，這時可以做細化的內容，做一個相對細化的DEMO圖，這一步面向開發、互動，開發進行技術上的評估。
互動是下一步真正要做事兒的人，會關注一些頁面的細節，所以這個時候可以做詳細的DEMO圖，並在DEMO圖右側配以一些說明，方便互動及UI進行工作。
不要寫詳細的介面操作說明，不過可以在進行介面設計期間，先寫一些業務邏輯相關的內容。
3）PRD V2.0
這個就是全版了，這麼細化的內容，只有真正做這塊功能的開發同學才會細看，寫細寫全沒得說了。
瞭解了不同使用者的訴求，那我們就具體說下PRD編寫的內容吧。
二、圍繞使用者體驗要素的PRD編寫
為什麼要說圍繞使用者體驗要素來編寫PRD，因為產品的設計是圍繞著這個經典的框架來的，那寫PRD的任務當然是要把這個內容向大家表述清楚。
使用者體驗要素
下面就具體說下PRD如何圍繞這個內容編寫。
第一部分：需求概述
其實不僅僅是做產品，任何事情，第一步肯定是要想清楚要做什麼，為什麼要做，也就是把戰略層描述清楚，PRD的第一部分就是要把這塊內容說清楚，回答出下面的問題。
1）使用者要獲得什麼？—— 使用者痛點、需求
建議這塊內容，說清楚整體的問題痛點，同時也要舉具體case，列舉數字，如使用者的使用頻次，現在的花費等等。
2）使用者是誰？—— 使用者細分、使用者數量、畫像
使用者是誰，並不是如“商家使用者”這種粗線條的描述，要說清楚對於當前的功能，是哪類使用者在什麼場景下的需求，使用者的量級是怎樣的，有一個相對具體的畫像。
3）使用者能通過這個得到什麼？ —— 使用者收益
這裡面補充個內容，俞軍老師曾說過，使用者淨收益=新體驗-舊體驗-替換成本，替換成本可能是獲取成本、認知成本、資金等等， 雖然這些內容並不是真正可衡量的，但在做一款新產品評估其價值時，可以從這幾個角度進行思考。
4）我們能得到什麼？—— 對企業能帶來什麼收益
這點很重要，做任何產品，給使用者賦能，給使用者帶來價值，其主要目的還是企業自身能夠盈利，這點想清楚才能說服老闆提供資源呀。
第二部分：產品規劃
最抽象的戰略層說清楚了，下一步就要大體說下為了實現上面列舉的各種想法目標，要一步一步怎麼做了，也就是說清範圍層的內容。
1）功能&資訊結構圖
範圍層，就是要說清楚，為了實現戰略做什麼事情，什麼功能，提供什麼內容。這塊一般會通過腦圖或者框架圖來展現，說清楚我們需要哪些資料，做哪些功能，各個功能與功能之間的關係。
要注意，這部分需要在長遠角度，解決這個問題地整條路線進行思考。舉個例子吧，比如要做個評論功能，讓使用者對產品更瞭解，並帶來更多銷量。那第一步先增加評論功能，之後可以對評論進行分析，為使用者推薦高質量的產品，發現問題產品保證平臺產品質量等等。類似這樣，出一個整體的規劃藍圖。
2）路線規劃
藍圖出來了，還是要落地的。所以這一步要把剛才地藍圖，切成一塊一塊，每一步要做什麼，多長時間，這個階段解決怎麼的問題，為後面提供什麼鋪墊。有些內容，也可以出一個簡易的DEMO圖，能描述清楚即可。
第三部分：功能概述
這一部分是對當前這一期要做的內容的詳細描述了。這部分面向的主要使用者是UI、互動、開發、測試同學，具體到做事情上，就是把大家的認知拉齊。
1）產品流程圖
通過圖的方式，可以快速、方便地告知PRD的每個使用者這個功能的思路流程。這裡最開始放的是比較粗線條的流程圖，比如買家購買商品，加入購物車->付款->商家發貨->確認收貨。而一些細節，比如買家超時未付款，或者賣家修改價錢等等，可以到具體寫到這個功能點地時候再出一個細化的流程圖。
2）DEMO，原型製作，這個就不用多說。
3）UI稿，這塊是UI同學完成後，放上來，統一相關資料的獲取入口。
4）產品功能點，後面來細說。
補充兩塊，流程圖和產品功能點：
產品流程圖——UML（統一建模語言）
Unified Modeling Language (UML)又稱統一建模語言，為軟體開發的所有階段提供模型化和視覺化支援，簡而言之，就是用圖的方式把事情描述清楚。在這裡有兩個概念，類和物件。類是把一類事物的抽象，而物件是類的例項。比如汽車是一個類，某輛車就是個物件了。對於產品經理，這兩個詞其實含義基本等同了。
下面我以員工提交許可權審批這件事為例，對應地類（或者說是物件）有員工、老闆、還是審批單，給大家主要介紹4個圖。
1）活動圖
我們也經常叫流程圖，就是要描述清楚各個角色之間的工作流程。
矩形框內描述當前活動，菱形塊列出分叉路線。如果有多個角色，如下面的例子，則將每個角色出一個泳道，對應哪個角色的活動即放到哪個泳道下。
2）序列圖
這個圖是各個物件之間的一個描述，與活動圖略有相似，可以看下面的例子，我們在日常工作中，選取其中某一個把事情說清楚就OK了。
這裡每個物件會有一個生命線，我把系統本身單出來，做了一條生命線，員工、老闆在進行某些操作後，需要系統這面進行儲存或者修改狀態，那右側即對應與資料庫的互動，後端同學根據這個，大體就瞭解自己在什麼時候要做什麼事情了。
3）狀態圖
狀態圖的樣式，雖說和活動圖樣式差不多，但其實內容差別還挺大的，狀態圖是對一個物件的不同狀態切換進行描述。比如許可權審批這個事情，審批單有“審批中”、“未批准”、“批准”這3種狀態，通過這個圖可以很清晰地瞭解各個狀態的轉換方式。
4）類圖
描述類的內部結構和類之間的關係，這個用得不多，可以簡單瞭解下。
還是這個功能，我們有員工、審批單、老闆這3個類，他們有些屬性，對於員工和老闆還有一些操作，可以通過這個類圖來表述出來。其中有個+-號，+號是public，即其他類可見，-號是private，其他類不可見。比如員工的姓名，其他類無法獲知，但可以通過一些物件操作獲得。這個就有些偏開發的內容了，不是特殊需要開發同學知道資訊，可以不對這塊進行標註。
產品功能細化說明
這塊就是要把功能說得足夠細，但也是有一些技巧。
1）更新說明
首先，我一般會在功能最上方，列出更新的清單，一般記錄有：調整時間、調整功能塊、詳細說明。
2）全域性說明
每期功能可能會有多個頁面多個功能塊，但有一些想通的地方，比如對於資料產品，數字的展現形式，保留2位小數，增加三分位符號等；對於移動端產品，一些操作方式等。這個適用於各個塊，不用分別在每個中單獨說明，而且後續做其他功能都是可以複用的，可以先列出來說清楚。
3）具體每個塊的功能說明
- 前置條件：有些功能可能會有這個內容，在什麼情況觸發這個功能，比如在使用者購買什麼商品後提供某個功能；
- 主體功能說明
- 流程描述：主流程、分支流程，這個就可以使用上面介紹的UML圖，把主線條描述清楚；
- 介面描述：操作、文案，文案建議其他顏色標註出來，防止和描述弄混；
- 業務規則：這個是在介面看不到的，比如限制條件、表格的排序規則、需要記錄的資料、還有一些數字的計算公式等等；
- 異常描述：這個不能忽略，尤其是C端產品，考慮需要更為全面，因為很可能就是一個小異常，就導致使用者使用不爽而流失，比如上傳檔案沒有考慮超出大小怎麼辦，使用者上傳後一直沒反應，就會認為這個產品不好用，轉而使用其他產品，所以，異常地考慮很重要。列幾個常見的異常：如未輸入、輸入錯誤、無資料，無網路，長時間未操作，異常退出等等。
最後說下寫這塊內容的原則
- 完整：足夠細，考慮足夠周全；
- 無歧義：RD同學是拿著這個文件真真切切寫程式碼，所以說得內容，要能夠落到程式碼上，比如使用者一段時間未操作則提示。。。，等待多長時間，要寫清楚；
- 有條理：這文件是有人看的，所以序號、符號都適當的用上，讓你的文件容易閱讀；
- 及時更新：功能、DEMO的調整，都需要落到PRD上。
第四部分：資料需求
因為我本人是資料產品的產品經理，所以這一部分對於我們很重要，需要哪些維度、哪些指標，指標的來源庫表欄位、計算口徑是什麼，這些都要清晰地記錄下來。
除此之後，有個內容可能經常會被忽略，就是資料的整理。以某寶的搜尋結果頁為例，一般會展示圖片、標題、價格、銷量、賣家名稱、包郵會標記出來，這些RD通過UI稿可能會檢視到，但有一些比如滑鼠移入顯示資訊，點選操作、是否購買過，都在商品展示時體現出來。
這些內容，我們可不能指望RD同學從UI稿中一點點發現。所以列出這樣的表格，把你認為需要的類及其屬性列清楚，有點類似我們上面類圖中物件屬性要描述的內容，目的是讓開發同學對照這個來進行庫表設計，不要遺漏某些點。
第五部分：資料埋點
包括按鈕的埋點&內容的埋點，可以通過截圖+表格說明的方式，截圖示明需要埋點哪些控制元件，表格說明對應控制元件的什麼資訊，如操作PV、UV、輸入內容等。
第六部分：效果評估方案及上線安排
對於C端產品，這塊內容會更加重要，一般會有個灰度釋出過程，因此需要說清楚灰度釋出的方式，放量安排、節奏，需要關注的指標，這個指標如何進行評估，達到什麼樣程度可以全部上線。
第七部分：人員排期
OK，大功告成了。
三、PRD的承載
最後說一點：PRD的存放。
我嘗試過幾種方式，之前就在axure中完成，在DEMO的右側進行說明，但這個不好的是：在進行更新後，還要傳送給大家，各個版本的存放加上axure本身下載解壓就比較麻煩，所以並不是最佳方案。
我現在一般是用wiki來完成，只要一個連結，更新後只要告知大家同步下資訊就好，就是在寫功能時候，需要把DEMO對應圖貼上去，RD能夠比較方便知道是對哪塊內容的描述。
對於上述內容，我一般分成2個wiki頁記錄，一個記錄需求概述和產品規劃部分內容；一個記錄產品功能及之後的內容，這個是當前這期的事情。一個總分的結構。
以上是我個人寫PRD的一些經驗總結，希望對大家有幫助。不過，這個PRD的編寫並不適於所有公司，一份完善的PRD需要花費比較多的時間，對大公司來說，對接方比較多，很有必要這樣一份文件統一各方的認知；而對於創業公司，將產品快速落地投放市場進行驗證更為重要，所以這個時候千萬不要把時間花費到PRD上面。