以用戶體驗五要素的思路，如何編寫產品需求文檔（PRD）

1、PRD的用戶是誰？

首先，與你們先分享一句話：把需求文檔當成一個「互聯網產品」去管理，理解它的用戶，關注它的體驗，不停迭代，使其價值最大化。（引用）

既然把它視爲一個互聯網產品，那咱們須要思考PRD的用戶是誰，他們經過PRD要了解什麼內容？

根據用戶以及他們的訴求。

我把PRD分紅幾個階段：

1）MRD階段

這個時候，主要須要說服咱們的老闆、或者團隊內部評審，也會有需求方，讓你們認同你的方案，知道你要作什麼怎麼作。

因此這個時候相似於MRD，把整個方案路線說清楚就能夠，作一個較粗線條的DEMO圖。

切勿作細化的設計稿，更不要寫詳細的功能說明，由於這時候被拍的可能性很大。

2）PRD V1.0

若是經過了第一步評審，這時能夠作細化的內容，作一個相對細化的DEMO圖，這一步面向開發、交互，開發進行技術上的評估。

交互是下一步真正要作事兒的人，會關注一些頁面的細節，因此這個時候能夠作詳細的DEMO圖，並在DEMO圖右側配以一些說明，方便交互及UI進行工做。

不要寫詳細的界面操做說明，不過能夠在進行界面設計期間，先寫一些業務邏輯相關的內容。

3）PRD V2.0

這個就是全版了，這麼細化的內容，只有真正作這塊功能的開發同窗纔會細看，寫細寫全沒得說了。

瞭解了不一樣用戶的訴求，那咱們就具體說下PRD編寫的內容吧。

2、圍繞用戶體驗要素的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，大功告成了。

3、PRD的承載

最後說一點：PRD的存放。

我嘗試過幾種方式，以前就在axure中完成，在DEMO的右側進行說明，但這個很差的是：在進行更新後，還要發送給你們，各個版本的存放加上axure自己下載解壓就比較麻煩，因此並非最佳方案。

我如今通常是用wiki來完成，只要一個連接，更新後只要告知你們同步下信息就好，就是在寫功能時候，須要把DEMO對應圖貼上去，RD可以比較方便知道是對哪塊內容的描述。

對於上述內容，我通常分紅2個wiki頁記錄，一個記錄需求概述和產品規劃部份內容；一個記錄產品功能及以後的內容，這個是當前這期的事情。一個總分的結構。

以上是我我的寫PRD的一些經驗總結，但願對你們有幫助。不過，這個PRD的編寫並不適於全部公司，一份完善的PRD須要花費比較多的時間，對大公司來講，對接方比較多，頗有必要這樣一份文檔統一各方的認知；而對於創業公司，將產品快速落地投放市場進行驗證更爲重要，因此這個時候千萬不要把時間花費到PRD上面。