作為個把月沒產品實習的2018應屆生， 想在寒假期間梳理自身產品知識更好地迎接年後的實習應聘。 而本文是我歸納總結PRD文檔（採用Axure）結構和內容後輸出的文章。
目錄
分析方法介紹具體分析結語1.分析方法介紹PRD（產品需求文檔）是產品新人日常工作中輸出最多的文檔類型， 而不同公司不同團隊對於PRD的結果和內容要求都不盡相同， 所以PRD文檔也可以被當作一個獨立的產品來對待， 根據團隊不同的需求來輸出最合適的需求文檔。
產品因需求而生， 需求轉化為產品過程中的依據即是產品邏輯， 體驗分析產品本質上是對產品邏輯的探究。 本文將PRD文檔視為獨立產品， 分析文檔的結構（結構層、框架層）和內容（戰略層、範圍層、表現層）。
2.具體分析設計一款產品首先應瞭解目標人群的特徵， 並分析其需求。
PRD文檔（含交互）一般交付給UI視覺設計和開發人員，
UI篇UI需求：UI由於要根據產品調性、功能特徵等因素來設計合理的視覺稿， 所以UI同學需要明白產品是什麼， 大到整個產品是做什麼的，
需求分析：PRD文檔需要對整個產品進行整體描述， 其次在對各個頁面進行描述， 做到以上兩點還是不夠的， 還需要把各個頁面都聯繫起來才算是完整的產品表達。
舉例說明：如果覺得以上描述過於模糊， 我想舉個例子來類比會好理解得多。 如果把一個產品看成一套住宅房（三室一廳一廚兩衛）， 那麼產品功能定位就是住宅， 從而解決人的居住需求。 其中各個房間猶如移動端產品的各個頁面， 各自承載著不同的功能， 而室內的傢俱可類比頁面裡的部件， 室內設計師需要瞭解以上內容結合房間的位置設計出合理的設計稿。
插一句：為了將需求轉化為功能（由於本文將PRD文檔定義為產品，
PRD功能：綜上， UI需要從PRD文檔上得到完整的產品表達（1.產品總述2.頁面描述3.頁面聯繫）， 所以PRD文檔需要有1.產品/功能模組總述（文字描述）2.頁面功能簡介（文字描述）3.頁面流程圖（流程圖）
開發篇開發需求：開發同學側重于理解怎麼做產品， 也就是產品邏輯是怎麼樣的。 當然也需要瞭解產品是做什麼的， 這有利於充分理解產品邏輯，
需求分析：PRD文檔對於邏輯的表達需要足夠充分， 體現在整個產品頁面之間的層級關係、跳轉關係， 頁面內各個部件作用， 各個功能邏輯、此外還應該與開發溝通未來反覆運算方向和內容， 以便於提升程式擴展性， 避免程式重構。
舉例說明：還是用住宅房為例， 在開發人員接手之前一切還都是空想， 只留於紙面（PRD文檔、視覺稿等）， 所以開發人員需要知道各個房間的位置如何設計、房間內的傢俱類型， 水電煤功能實現：進水出水口（水流通功能）、整個住宅房的電纜怎麼拉（通電功能）、天然氣口在哪（烹飪功能）， 有了以上這些才有可能實現產品從0到1。 至於傢俱選購、室內裝潢都由視覺稿來表達。
PRD功能：綜上，開發需要從PRD文檔上瞭解產品邏輯（1.頁面跳轉邏輯2.功能邏輯3.頁面交互邏輯）所以PRD文檔需要有1.頁面流程圖（流程圖）2.功能流程圖（流程圖）3.頁面交互（線框圖+文字描述）
產品篇產品需求：產品/功能模組需要不斷的反覆運算更新，所以產品同學需要根據上一版的PRD文檔進行下一版的反覆運算，避免功能遺漏或者戰略方向不明確。
需求分析：所以PRD文檔在產品總述時要準確地描述產品定位以防反覆運算時產品“變性”；而需求池裡也應該將需求排上優先順序；為了更直觀的管理(增刪改查)現有產品架構也應該附上資訊架構。
PRD功能：綜上，產品需要根據PRD文檔內容進行產品反覆運算，所以要求RPD具備：1.產品總述（文字描述）2.版本記錄/需求管理（表格+文字描述）3.資訊架構圖（腦圖）
整理：綜上所述，PRD由於UI、開發、產品的需求，需要具備
產品總述版本記錄/需求管理資訊架構圖功能流程圖頁面流程圖頁面交互以上六大內容，為了方便閱讀理解，應根據內容的具體程度由全域到局部不斷細化進行排序，即下圖：
為了讓本文更加實用，我將對六大內容如何表達進行簡要介紹，具體的表達方式可以參考其他詳文。
產品總述前文提到產品總述對於UI、開發、產品來說都是必看的一塊內容，扮演概括性的角色。所以在我的理解裡。產品總述應該點明該文檔的目的，並且明確產品核心需求和定位。
不拘於表達形式，只需要把以上幾點表達清楚即可，以下內容同理。
版本記錄/需求管理版本記錄和需求管理本可以分為兩塊獨立內容，但是之間又有所聯繫，索性就拉到一塊了。
歷史版本的作用使得產品開發更加條理，有跡可循，算是一種記錄。當前版本雖然一定是最後一行，但也應該用不同字色以示區分。
而之後關於新版描述不在多說，需要注意的是序號的對應關係，還有當前版本的需求也應該用不同字色和其他需求區分開來。
資訊架構圖/頁面流程圖/功能流程圖這裡不做闡述，在各大論壇搜索框輸入“資訊架構圖/頁面流程圖/功能流程圖”會有更全面的資訊。
頁面交互雖然網路上有許多交互的表達方式，但我還是想分享一下自認為不錯的交互呈現形式（如下圖）
如果你是產品小白，從未做過完整的PRD文檔，當你寫多了頁面交互時會發現其中有許多重複性描述，所以這時候就又多了一個需求，能否把重複性又複雜的描述提取出來成為一塊獨立內容，要用到時只需要簡單一句話作為“調用”。如同程式開發時的函式呼叫一般，更加快捷。
PRDV1.1新版描述：新增“全域說明”功能
全域說明上文提到全域說明是頁面交互裡重複性複雜的描述的集合。
所以全域說明裡的內容可以是1.toast/alert/dialog樣式 2.資料變化方式（刷新等） 3.異常情況處理（網路異常、程式中斷等）4.文字/圖示/元件使用規範（當然大多數情況是由UI和產品一同進行定義）5.名詞說明（定義產品中特殊名詞）
增加“全域說明”功能後的PRD目錄如下圖
3.結語相信原本不理解PRD文檔的同學在通讀全文後能明白PRD文檔是怎麼回事。但本文更希望傳遞的是產品思維，如何去系統地理解一件事物，小到生活裡的瑣事，都應該掌握梳理其脈絡發現本質的能力。
本文由 @石力.Lison 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議
PRD功能：綜上，開發需要從PRD文檔上瞭解產品邏輯（1.頁面跳轉邏輯2.功能邏輯3.頁面交互邏輯）所以PRD文檔需要有1.頁面流程圖（流程圖）2.功能流程圖（流程圖）3.頁面交互（線框圖+文字描述）
產品篇產品需求：產品/功能模組需要不斷的反覆運算更新，所以產品同學需要根據上一版的PRD文檔進行下一版的反覆運算，避免功能遺漏或者戰略方向不明確。
需求分析：所以PRD文檔在產品總述時要準確地描述產品定位以防反覆運算時產品“變性”；而需求池裡也應該將需求排上優先順序；為了更直觀的管理(增刪改查)現有產品架構也應該附上資訊架構。
PRD功能：綜上，產品需要根據PRD文檔內容進行產品反覆運算，所以要求RPD具備：1.產品總述（文字描述）2.版本記錄/需求管理（表格+文字描述）3.資訊架構圖（腦圖）
整理：綜上所述，PRD由於UI、開發、產品的需求，需要具備
產品總述版本記錄/需求管理資訊架構圖功能流程圖頁面流程圖頁面交互以上六大內容，為了方便閱讀理解，應根據內容的具體程度由全域到局部不斷細化進行排序，即下圖：
為了讓本文更加實用，我將對六大內容如何表達進行簡要介紹，具體的表達方式可以參考其他詳文。
產品總述前文提到產品總述對於UI、開發、產品來說都是必看的一塊內容，扮演概括性的角色。所以在我的理解裡。產品總述應該點明該文檔的目的，並且明確產品核心需求和定位。
不拘於表達形式，只需要把以上幾點表達清楚即可，以下內容同理。
版本記錄/需求管理版本記錄和需求管理本可以分為兩塊獨立內容，但是之間又有所聯繫，索性就拉到一塊了。
歷史版本的作用使得產品開發更加條理，有跡可循，算是一種記錄。當前版本雖然一定是最後一行，但也應該用不同字色以示區分。
而之後關於新版描述不在多說，需要注意的是序號的對應關係，還有當前版本的需求也應該用不同字色和其他需求區分開來。
資訊架構圖/頁面流程圖/功能流程圖這裡不做闡述，在各大論壇搜索框輸入“資訊架構圖/頁面流程圖/功能流程圖”會有更全面的資訊。
頁面交互雖然網路上有許多交互的表達方式，但我還是想分享一下自認為不錯的交互呈現形式（如下圖）
如果你是產品小白，從未做過完整的PRD文檔，當你寫多了頁面交互時會發現其中有許多重複性描述，所以這時候就又多了一個需求，能否把重複性又複雜的描述提取出來成為一塊獨立內容，要用到時只需要簡單一句話作為“調用”。如同程式開發時的函式呼叫一般，更加快捷。
PRDV1.1新版描述：新增“全域說明”功能
全域說明上文提到全域說明是頁面交互裡重複性複雜的描述的集合。
所以全域說明裡的內容可以是1.toast/alert/dialog樣式 2.資料變化方式（刷新等） 3.異常情況處理（網路異常、程式中斷等）4.文字/圖示/元件使用規範（當然大多數情況是由UI和產品一同進行定義）5.名詞說明（定義產品中特殊名詞）
增加“全域說明”功能後的PRD目錄如下圖
3.結語相信原本不理解PRD文檔的同學在通讀全文後能明白PRD文檔是怎麼回事。但本文更希望傳遞的是產品思維，如何去系統地理解一件事物，小到生活裡的瑣事，都應該掌握梳理其脈絡發現本質的能力。
本文由 @石力.Lison 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議