首先，產品經理主要需要輸出的文件有：信息結構圖（供產品經理自己進行信息梳理，以及與開發人員討論數據結構的依據），產品結構圖（供產品團隊內部更清晰的管理產品的功能），原型圖（線框圖，產品宣講時用到，設計，技術，老板更明確理解產品意圖），產品需求文檔（最終執行文檔，針對開發，設計人員）。
以下將對這些文檔的意義以及使用到的制作工具，進行說明。

產品需求文檔（PRD）

產品設計的最終表述的形式被稱為產品需求文檔，業界常常稱呼為PRD文檔，這是英文Product Requirement Document的縮寫。
PRD文檔是基于BRD、MRD的延續文檔，主要是一份給執行層面的工作人員閱讀的文檔，這部分人群絕大多數是設計與技術人員。在這類人群中，設計師更多依賴于產品原型進行交互或視覺的設計，因此看這份文檔的人主要是技術人員。相對于技術人員，他們不太關注產品的商業需求和市場愿景，因為在進行產品討論立項時，產品的定義就已經向參與設計和研發的人員宣講過，因此技術人員更多的是關注界面、功能、交互、元素等等內容，因此產品需求文檔是一份詳細的產品功能需求說明文檔，是產品文檔中最底層和最細致的文檔。主要是介紹功能說明。目的都是一樣的，必須能夠明確產品的功能需求，便執行人員理解任務要求。—產品經過規劃和設計之后的最終執行文檔。

1.羅列信息（信息結構圖）

在寫產品需求文檔之前，我們要先羅列出產品功能的信息內容，這一步是將想法逐漸清晰的第一步，也是幫助我們接下來設計功能的輔助信息，同時也可以輔助服務端技術人員創建數據庫。因為這是第一步，所以我們不需要羅列的很詳細，在之后的步驟里，我們會逐步改進和完善信息內容。

羅列信息內容的方式有很多種，文本形式、思維導圖形式等等都可以，最主要的是能夠清晰易懂，我最常用的方法就是使用思維導圖軟件(MindManager)羅列成結構圖，因此我稱這一步為“信息結構圖”。

image.png

上圖是一張以Blog系統為示例的信息結構圖。信息結構圖是一種接近數據庫結構的圖表，在羅列信息結構時，更多的是考慮信息數據，但是他并不是真正意義的數據庫結構。信息結構圖是提供給產品經理自己梳理信息內容的結構圖，也是方便產品經理和服務端技術人員溝通數據結構的參考圖，技術人員會根據這張圖表的內容再結合產品原型或需求文檔，然后規劃和設計出真正意義上的數據庫結構。

信息結構圖中關于友情鏈接功能的信息數據只有“名稱”和“鏈接”兩個內容，但是在實際功能需求中，友情鏈接還有兩個功能，分別是“顯示或隱藏”和“是否新窗口打開”，這兩個功能會在產品原型和需求文檔中詳細描述，但是在信息結構中是沒有體現的，因為從產品層面上來說，這兩個只是功能，并不是信息內容。但是在真正數據庫中，友情鏈接的這兩個功能分別也是有字段參數的，程序在讀取該參數后便知道友情鏈接的屬性，然后處理友情鏈接是顯示還是隱藏，是新窗口打開還是本窗口打開。通過友情鏈接這個例子，我們就知道了在實際中數據結構和信息結構是不一樣的，信息結構只是產品層面的數據內容。

無論是什么樣的產品類型，無論從哪里入手，我們第一步都是先要羅列信息結構，因為信息結構圖不僅是輔助技術人員創建數據庫的圖表，也是輔助產品人員進行產品功能規劃的參考，只有對信息或數據的結構了解了，我們才能更好的設計產品。信息結構圖是我們將概念想法形成結構化的第一步，也是我們接下來幾步工作的輔助文檔，同時在接下來的幾步工作中，我們還會不斷的完善信息的結構。

2.梳理需求（產品結構圖）

當我們對產品的信息結構了解后，我們就需要規整腦海中的產品需求，讓想法更加結構化，因此這一步就要梳理產品的需求。在設計產品原型之前，我們首先要羅列出產品的功能結構，包括頻道、頁面、模塊及元素。這一步依然使用思維導圖軟件，像繪制樓盤鳥瞰圖一樣將產品的結構繪制成結構圖，因此我稱這一步為“產品結構圖”。

產品結構圖是一種將產品原型以結構化的方式展現的圖表，結構內容也如同產品原型一樣，從頻道到頁面，再細化頁面功能模塊和元素。所以產品結構圖是產品經理在設計原型之前的一種思路梳理的方式，并不是給其他工作人員查看的文檔，通過類似鳥瞰式的結構圖可以讓產品經理對產品結構一目了然，也方便思考。

image.png

如上圖示例，“活動大全”的產品結構依次是：產品 -> 頻道 -> 頁面 -> 頁面元素 -> 操作 ->元素我們換一個角度觀看示例，產品結構圖實際上就是一種結構化的產品原型。這樣做的目的就是梳理產品結構邏輯，讓我們清楚的知道產品有幾個頻道，頻道下面有沒有子頻道或者有多少個頁面，這些頁面里又有哪些功能模塊，這些功能模塊里又有哪些元素。
以我們第一步的“信息結構圖”為基礎繪制的“產品結構圖”，有了這份結構導圖，我們可以對產品進行鳥瞰式考慮和完善，當有問題時，修改起來也比原型和文檔方便很多。比如在后續規劃中，我們發現文章的圖片等附件上傳后，管理不太方便，這時就可以在結構圖中增加一個“附件管理”頻道。如果我們使用產品結構圖的方式，那么附件管理的功能增加和修改就會比原型工具更加便捷和效率。

產品結構圖的方法同樣適用于移動互聯網產品的設計，并且比起Web產品更加容易梳理產品結構。

產品結構圖是一種讓產品經理通過思維導圖的方式梳理思路的方法，通過這種方法可以明確產品有多少個頻道、有多少個頁面、頁面有多少個功能模塊、功能模塊有多少個元素，逐步的將腦海里的想法明確梳理成結構。雖然這種方法能夠明確產品的結構，但是這樣的思維導圖也就只有產品經理自己能夠看懂，因為對于設計和技術人員這是一個抽象的表述方式，如果沒有詳細的講解，是很難理解的。

產品結構圖是將產品原型具體化的一種方式，只是羅列了產品的頻道頁面和功能，但是沒有詳細的進行推演，關于細化方面是否符合產品邏輯，是否符合用戶體驗，這些都是沒有深思過的，因此我們接下來就要進行原型設計，開始具體的考慮可行性。

3.原型設計（界面線框圖）

當我們逐漸清晰了產品的需求后，并梳理了產品的各個頻道及頁面，那么這一步就要開始驗證這些想法的具體界面表現和方案的可行性了。

原型設計是幫助我們更細致的思考，并做各項需求的評估，同時也是將自己腦海里的想法進行輸出的一種方式。通過原型設計后，我們就可以進行產品宣講了，相比較于抽象的文字描述，原型則更加直觀的展現產品的需求，設計和技術人員或者老板也能夠更加直觀的了解到產品意圖。

原型設計是將結構化的需求進行框架化，因此原型也被稱為線框圖，具體的表現手法有很多種，相關的輔助軟件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。

當到了原型設計這一步時，已經不僅僅是構思了，我們需要更加深入的了解每個頁面上元素和這些元素的屬性。例如按鈕元素，我們就需要考慮這個按鈕的功能，并且這個功能操作后帶給后端和前端的反饋。例如注冊會員按鈕，用戶操作后，第一步邏輯是驗證用戶輸入的信息是否合法，不合法則給出前端反饋；合法則和后端通信驗證是否已經存在同樣信息，已經存在則給出前端反饋，不存在則進入下一步，注冊成功；注冊成功后的反饋是跳轉頁面，還是彈出層提示用戶完善資料，

這些都是需要更詳情的考慮。當然這些更細致的思考是留在需求文檔撰寫時的，而此時我們需要做的就是把這些元素通過原型表現出來。

原型設計的表現手法主要有三種：手繪原型、灰模原型、交互原型。從工作效率的角度考慮，我非常建議先通過手繪的形式快速在草紙上繪制出產品的原型，推演和討論方案的可行性。當方案的可行性被驗證之后，我們再根據個人習慣或團隊要求，通過軟件工具進行更深入的設計。

①手繪原型—-方便討論和重構，第一時間先采用手繪

因為原型也被稱為線框圖，因此手繪是最簡單直接的方法，也是最快速的表現產品輪廓的手法。

image.png

手繪原型在初期驗證想法時非常高效，也方便討論和重構，同時也適合敏捷開發時快速出原型。

② 灰模原型

灰模原型是由圖形設計軟件制作而成，最常用的軟件是Photoshop和Fireworks，相對手繪原型，灰模更加清晰和整潔，也適用于正式場合的PPT形式宣講。

image.png

灰模原型也可以稱之為平面原型，所以如果不會使用圖形軟件也可以使用Axure RP設計，相比交互原型，灰模原型只是缺少交互效果，僅僅是將產品需求以線框結構的方式展示出來，讓產品需求更加規整的直觀展現。

image.png

③ 交互原型—-產品Demo版，耗時，逼真

交互原型是使用原型設計軟件完成的原型，常用軟件是AxureRP，通常情況交互原型的設計要早于產品需求文檔，是產品經理想法推演的重要一步。通過AxureRP之類的交互原型軟件制作出來的產品原型，在功能需求和交互需求的表現上，幾乎和正式產品是一致的，所以有時交互原型也被稱為產品Demo版。

通常情況下交互原型是產品經理與交互設計師共同討論確定，然后由交互設計師制作，但是絕大多數的公司是沒有交互設計師這個職位的，因此這類工作最終是由產品經理來負責的。

以上三種方法并不是漸進的流程，而是三種原型設計的方法，具體取決于你的產品需求和團隊要求。

對于產品經理來說，原型設計是為了幫助我們細致的考慮方案，并論證方案的可行性，同時也是為了產品宣講時讓聽眾能夠清晰直觀的了解產品，避免抽象的語言描述導致聽眾理解困難和理解偏差。產品原型也是為了確保產品在執行過程中，是按產品經理最初設想的需求和期望完成的，因此產品經理的原型是沒有很高的要求的，只要對方能夠聽懂看懂就可以了，所以使用手繪原型是最高效率的方法。

4.需求文檔（PRD文檔）—重點

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

image.png

① 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文檔中包含了部分交互說明。

<meta charset=”utf-8″>

② 圖片—-最佳的產品文檔表現形式

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

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

image.png

③ 交互原型 —–演示 原型，帶交互比較好的展現方式

這里指的交互原型就是前面篇章講到的原型設計，使用Axure PR之類的交互原型設計軟件制作出來的產品原型非常真實和直觀，并且原型軟件還支持元素標注和導出Word文檔，因此很多產品經理都喜歡使用Axure PR來代替Word完成產品需求文檔。

當我們通過Axure PR制作出產品原型后，實際上他已經是很完善的產品Demo了，因此我們只需要加上元素的標注，在標注中說明功能需求，這樣導出的HTML文件相比Word文檔更直觀易懂，是非常高效的產品需求說明方式。

image.png

無論你采用哪種方式撰寫需求文檔，最終的目的都是為了方便團隊成員理解產品的意圖，因此哪種方法能夠避免細節黑洞，高效完成產品的設計和研發，那么這種方法就是最有效的方法。