作為個把月沒産品實習的2018應屆生，想在寒假期間梳理自身産品知識更好地迎接年後的實習應聘。而本文是我歸納總結PRD文檔（采用Axure）結構和内容後輸出的文章。

目錄

1. 分析方法介紹
2. 具體分析
3. 結語

1.分析方法介紹

PRD（産品需求文檔）是産品新人日常工作中輸出最多的文檔類型，而不同公司不同團隊對于PRD的結果和内容要求都不盡相同，所以PRD文檔也可以被當作一個獨立的産品來對待，根據團隊不同的需求來輸出最合适的需求文檔。

産品因需求而生，需求轉化為産品過程中的依據即是産品邏輯，體驗分析産品本質上是對産品邏輯的探究。本文将PRD文檔視為獨立産品，分析文檔的結構（結構層、框架層）和内容（戰略層、範圍層、表現層）。

2.具體分析

設計一款産品首先應了解目标人群的特征，并分析其需求。

PRD文檔（含交互）一般交付給UI視覺設計和開發人員，所以UI和開發成了PRD的目标用戶。而産品并不是一蹴而就的，所以PRD也是産品同學不斷叠代産品的依據。對三類用戶進行分析可得出下圖

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、開發、産品的需求，需要具備

1. 産品總述
2. 版本記錄/需求管理
3. 信息架構圖
4. 功能流程圖
5. 頁面流程圖
6. 頁面交互

以上六大内容，為了方便閱讀理解，應根據内容的具體程度由全局到局部不斷細化進行排序，即下圖：

為了讓本文更加實用，我将對六大内容如何表達進行簡要介紹，具體的表達方式可以參考其他詳文。

産品總述

前文提到産品總述對于UI、開發、産品來說都是必看的一塊内容，扮演概括性的角色。所以在我的理解裡。産品總述應該點明該文檔的目的，并且明确産品核心需求和定位。

不拘于表達形式，隻需要把以上幾點表達清楚即可，以下内容同理。

版本記錄/需求管理

版本記錄和需求管理本可以分為兩塊獨立内容，但是之間又有所聯系，索性就拉到一塊了。

曆史版本的作用使得産品開發更加條理，有迹可循，算是一種記錄。當前版本雖然一定是最後一行，但也應該用不同字色以示區分。

而之後關于新版描述不在多說，需要注意的是序号的對應關系，還有當前版本的需求也應該用不同字色和其他需求區分開來。

信息架構圖/頁面流程圖/功能流程圖

這裡不做闡述，在各大論壇搜索框輸入“信息架構圖/頁面流程圖/功能流程圖”會有更全面的信息。

頁面交互

雖然網絡上有許多交互的表達方式，但我還是想分享一下自認為不錯的交互呈現形式（如下圖）

如果你是産品小白，從未做過完整的PRD文檔，當你寫多了頁面交互時會發現其中有許多重複性描述，所以這時候就又多了一個需求，能否把重複性又複雜的描述提取出來成為一塊獨立内容，要用到時隻需要簡單一句話作為“調用”。如同程序開發時的函數調用一般，更加快捷。

PRDV1.1

新版描述：新增“全局說明”功能

全局說明

上文提到全局說明是頁面交互裡重複性複雜的描述的集合。

所以全局說明裡的内容可以是1.toast/alert/dialog樣式 2.數據變化方式（刷新等） 3.異常情況處理（網絡異常、程序中斷等）4.文字/圖标/組件使用規範（當然大多數情況是由UI和産品一同進行定義）5.名詞說明（定義産品中特殊名詞）

增加“全局說明”功能後的PRD目錄如下圖

3.結語

相信原本不理解PRD文檔的同學在通讀全文後能明白PRD文檔是怎麼回事。但本文更希望傳遞的是産品思維，如何去系統地理解一件事物，小到生活裡的瑣事，都應該掌握梳理其脈絡發現本質的能力。

本文由 @石力.Lison 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部