第四章：產品設計(2.6)PRD寫作 – 需求文檔(PRD文檔)

阿航

2014-10-29

3 評論 92366 瀏覽 241 收藏

10 分鐘

2.6、需求文檔（PRD文檔）

前面的幾個步驟是為了幫助我們梳理需求、驗證可行性和明確細節，到了這一步的時候我們已經非常清晰的了解產品需求，此時撰寫產品需求文檔可以大大減少和避免了撰寫文檔時容易忽略的細節黑洞。

產品需求文檔是將產品規劃和設計的需求具體形象化表述出來的一種展現形式，主要用于產品界面設計和研發使用。因為每個人的習慣和團隊要求都是不一樣的，所以產品需求文檔沒有統一的行業規范標準，無論以什么樣的格式撰寫產品需求文檔，最終的目的都是讓執行人員能夠理解產品需求，根據需求完成產品。

產品需求文檔的表現形式有很多種，常見的有Word、圖片和交互原型這三種形式，文檔內容通常包含信息結構圖、界面線框圖、功能流程圖、功能說明文檔。雖然產品需求文檔沒有標準的規范，但是有兩項是必不可少的，那就是文件標識和修改記錄。文檔在撰寫過程中，我們可以自行不斷的修改完善，但是如果正式發布或交給團隊其他成員后，一旦有了修改，為了文檔的同步，我們就需要標注出文檔的修改內容，備注修改記錄，這樣可以方便大家查看和了解改動的內容。關于文件標識和修改記錄，格式都大同小異。

① Word

這是傳統意義上的產品需求文檔，主要有四個部分組成(具體根據產品要求進行劃分)，分別是：結構圖、全局說明、頻道功能、效果圖。

因為產品需求文檔的閱讀者主要是偏向于技術人員，因此文檔的目的性非常明確，就是要描述產品的功能需求，所有產品需求文檔沒有關于市場方面的描述。為了保證需求的執行效率，建議大家盡量減少不必要的文字，在能夠讓閱讀者看懂并且了解產品意圖的情況下，文字越少越好。這主要是因為絕大多數人是沒有足夠耐心認真看完產品需求文檔的，因此我們要盡量減化文檔內容。

①-1、結構圖：

①-1.1、信息結構圖：主要是輔助服務端技術人員創建或調整數據結構的參考文件

①-1.2、產品結構圖：主要是輔助設計和技術開發人員了解產品的全局結構。

①-2、全局說明：

主要講解產品的全局性功能的說明，例如網站產品的頁面編碼、用戶角色，移動產品的緩存機制、下載機制，這類全局性功能的說明。這里我舉一個移動產品的“狀態維持與恢復”的例子。示例如下：

狀態的維持與恢復

當用戶退出產品時（誤操作、Home鍵、鎖屏、自動關機），產品需要維持用戶操作前的狀態，當用戶返回產品時仍可以恢復到之前狀態，并繼續使用。

維持狀態包括流程操作、信息瀏覽、文本輸入、文件下載。

鎖屏狀態時，如果用戶在產品中有下載任務時，仍然保持下載。

①-3、頻道功能：

以頻道為單位，頁面為子項，分別描述產品的頻道、頁面及頁面模塊元素的功能需求。示例如下：

1、頻道名：頻道介紹及需求說明

2、頁面1：頁面介紹及需求說明

2.1、頁面模塊1：模塊功能需求說明

2.1.1、頁面模塊1-元素1：功能說明

2.1.2、頁面模塊1-元素2：功能說明

2.2、頁面模塊2：模塊功能需求說明

在撰寫功能需求時，我們需要考慮用戶的流程，例如一個“完成”按鈕，我們需要描述他完成后，系統要不要給出反饋提示(反饋提示是什么樣的形式反饋，內容顯示成什么，有沒有內容需要調取數據庫)，或者要不要跳轉頁面(跳轉到哪個頁面，這個頁面是其他頻道頁面，還是這個功能的子頁面，如果是子頁面就需要再描述這個子頁面的模塊及元素內容)。

①-4、效果圖：

效果圖是由設計師完成的產品圖，和實際開發完成的產品保真度一致。

這個示例是一個移動產品(iPad)需求文檔，其中部分隱私內容已過濾隱藏，并且只保留了首頁和地圖找房頻道的需求說明。由于工作環境沒有交互設計師，所以Word文檔中包含了部分交互說明。

② 圖片

圖片形式的產品需求文檔是基于效果圖的說明文件，將傳統Word形式的功能需求說明標注在效果圖上，這種方式經常使用在移動互聯網領域，實際上是圖文形式的交互需求文件，只是在此基礎上更深入的描述出功能需求。

對于圖片形式的產品需求文檔，我們只需要另外再描述一下全局說明，其他頻道頁面的需求直接以圖片形式展示，這種方式相對于Word文檔的純文字更加生動易讀并且直觀，因此有一些產品經理非常喜歡用這種方式代替Word形式的產品需求文檔。