文檔分為兩輪
　　第一輪：
　　1，文檔使用方：UI設計師
　　2、內(nèi)容：
　　.根據(jù)戰(zhàn)略層定義出來產(chǎn)品功能范圍，
　　.說明此產(chǎn)品的目的，方便UI設計人員更好的理解產(chǎn)品
　　.產(chǎn)品基本流程
　　.詳細的設計框架圖，推薦用axure,簡單效率高
　　.詳細文案
　　3、格式：
　　html，visio，或word，如果PS用的不熟練，不推薦使用，會影響工作效率。
　　
　　上面是要UI設計人員出來高保真原型圖，
　　
　　第二輪：
　　文檔使用方：開發(fā)人員
　　用高保真原型圖來對開發(fā)人員寫技術需求說明
　　有了高保真原型圖，開發(fā)人員看的最明白，我們只需要寫好詳細的邏輯功能結構和詳細的流程圖
　　
　　PS：個人認為在工作流程中，特別是面向UI和工程師，沒有必要詳細的寫出來什么行業(yè)分析，開發(fā)背景之類的內(nèi)容，因為UI和工程師是在干活，不去關心這些問題，但一定要寫清楚功能范圍和此產(chǎn)品的目的，這樣有助于UI設計人員的理解。
　　
　　另外，上面說的是個人理想狀態(tài)，可能每個公司有自己的現(xiàn)實情況而有不同的流程。關鍵是提高效率減少不必要的扯皮溝通。

2.2 產(chǎn)品定義 Product Definition

2.2.1 What 做什么產(chǎn)品定義，即定義產(chǎn)品到底要做成什么。一般來說，比較正規(guī)的做法是撰寫一份稱之為 PRD（Product Requirements Document）的文檔，該文檔一般可以包括以下內(nèi)容：

該產(chǎn)品的遠景目標（vision）
目標市場和客戶（target market and customers）的描述
競爭對手分析（competitive summary）
對產(chǎn)品主要feature的比較詳細的描述
這些feature的優(yōu)先級
初步擬定的實現(xiàn)進度安排
用例（use cases），這可以是較粗略的大致描述，未必一定要UML Use Case圖。
產(chǎn)品的軟硬件需求
產(chǎn)品的性能要求
銷售方式上的思路、需求（直銷還是渠道？直銷怎么做？渠道怎么做？）
技術支持方式上的思路、需求（提供什么樣的技術服務？）
顯然，PRD文檔就是對產(chǎn)品的整體規(guī)劃，應該比上述Market Research階段的MRD文檔要細化一些：

MRD文檔主要側重于市場機會的分析，得出結論“就當前市場情況而言，我們可以做什么”
PRD側重于整個產(chǎn)品的規(guī)劃，以及business方面的需求。
PRD不同于SRS（System Requirement Specification），SRS是系統(tǒng)需求分析說明書，是以相當技術化的語言撰寫的，主要給研發(fā)人員看的。
2.2.2 Goal 目標是什么

產(chǎn)品定義是產(chǎn)品管理的核心工作。

通過產(chǎn)品定義：

使得公司內(nèi)部所有與業(yè)務相關的部門（高層領導、研發(fā)、銷售、支持等部門）都能基本清楚我們到底要做什么產(chǎn)品，從而統(tǒng)一大家的思想和行動。
產(chǎn)品定義的PRD文檔，為研發(fā)部需求分析組接下來出SRS文檔提供了基本依據(jù)。
2.2.3 How 怎么做

產(chǎn)品管理部門根據(jù)市場研究結果，和各個業(yè)務相關部門溝通，發(fā)揮自己的創(chuàng)造力來進行產(chǎn)品定義工作。

2.2.4 Who 誰來做

產(chǎn)品經(jīng)理負責牽頭，主要由產(chǎn)品管理部門進行具體工作實施。

2.2.5 Deliverable 有無輸出

比較正規(guī)的做法是輸出上述PRD文檔。對小公司或者小團隊而言，有時可以把MRD和PRD合并在一個文檔里描述。

延伸閱讀：

做好產(chǎn)品需求文檔的10步

如何正確的寫產(chǎn)品需求文檔（PRD）附常用工具

MRD&PRD MRD和PRD有什么區(qū)別呢？