產品需求文檔的寫作(一) – 寫前準備(信息結構圖)

PRD： Product Requirement Document 產品需求文檔

PRD主要用于產品設計和開發(fā)使用闪盔，閱讀這份文檔的人大多是設計（更多依賴于原型進行交互設計）和技術人員（主要讀者雀瓢，主要關注界面陡舅、功能、交互叼旋、元素等內容）仇哆，PRD文檔是一份詳細的產品功能需求說明文檔，是產品文檔中最底層和最細致的文檔夫植。

PRD是一份直入主題的功能說明文檔讹剔，寫之前，根據BRD和MRD的相關需求規(guī)劃出產品的結構圖（思維導圖详民，用Xmind延欠、MindManager）。規(guī)劃產品的第一步是梳理出產品的信息結構（服務端技術人員創(chuàng)建數(shù)據庫的依據沈跨，是數(shù)據結構的輔助文件）由捎。信息結構的考慮有面向前端的，也有面向后端的饿凛。在完成PRD文檔需要向數(shù)據庫技術人員展示信息結構圖+講解產品原型和功能需求狞玛，便于他們做數(shù)據庫規(guī)劃時考慮到以后的擴展。

產品需求文檔的寫作(二) – 梳理需求(產品結構圖和用戶流程圖)

根據信息結構涧窒，規(guī)劃產品的功能需求心肪，繪制產品結構圖和用戶流程圖。

產品結構圖模板

概念解釋：

1纠吴、頻道：某一個同性質的功能或內容的共同載體硬鞍，也可稱為功能或內容的類別

2、子頻道：某頻道下細分的另一類別

3戴已、頁面：單個或附屬某個頻道或分類下的界面

4固该、模塊：頁面中多個元素組成的一個區(qū)域內容，可以有一個或多個糖儡，也可以循環(huán)出現(xiàn)(例如:文章列表)

5蹬音、模塊元素：模塊中的元素內容，以文章列表舉例：文章標題休玩、文章摘要著淆、文章發(fā)布時間，這些都是元素拴疤，都是組成模塊的內容永部，同時他們也是可以循環(huán)出現(xiàn)的。元素的類型可以是：文字呐矾、圖片苔埋、鏈接等等

前端面向瀏覽者的用戶流程：先規(guī)劃頻道，再從用戶視角一步步模擬操作蜒犯，完善產品的結構導圖组橄，即用戶流程圖荞膘。目的：梳理產品邏輯。比如登陸的流程圖（使用流程）玉工。

用戶登陸流程圖

但如果規(guī)劃的是CMS羽资、BBS之類的平臺產品，框架式開發(fā)遵班，功能與模板獨立屠升，從后臺入手模擬管理員的流程。

產品需求文檔的寫作(三) – 原型設計(手繪原型,灰模原型,交互原型)

用原型（線框圖）設計來具體考慮結構方案的可行性狭郑，預估項目要花多少人力物力腹暖。

原型設計的表現(xiàn)手法主要有三種：手繪原型（在初期驗證想法時非常高效，也方便討論和重構翰萨，適合敏捷開發(fā)時快速出原型）脏答、灰模原型（軟件：PhotoShop和FireWorks禀横，適用于宣講纵顾，常用于移動互聯(lián)網產品的設計厢钧，移動互聯(lián)網產品的設計通常是灰模原型加交互文檔組合成PRD文檔）衫仑、交互原型（Axure RP）也叫產品Demo版（一般交互原型是產品經理和交互設計師共同討論確定，然后由交互設計師制作固惯，但大多數(shù)公司沒有這個職位，或者把視覺設計師叫做交互設計師，所以最終還是產品經歷來畫產品原型）魄缚。網站產品可以考慮交互原型。

具體選擇哪種原型設計方法焚廊，取決于你的產品需求和團隊要求冶匹。只要對方能夠聽懂看懂，就可以咆瘟。

產品需求文檔的寫作(四) – 撰寫文檔(PRD文檔)

PRD文檔沒有標準的規(guī)范嚼隘，也沒有統(tǒng)一的模板，取決于個人習慣和團隊要求袒餐。雖然PRD文檔沒有標準的規(guī)范飞蛹，但文件標識和修改記錄是必不可少的。文檔正式發(fā)布或交給團隊其他成員后灸眼，一旦有了修改卧檐，為了文檔的同步，我們就需要標注出文檔的修改內容焰宣，備注修改記錄霉囚。關于文件標識和修改記錄，大家的格式都大同小異(如下圖)匕积。

文件標識和修改記錄

PRD文檔形式：Word盈罐、圖片榜跌、交互原型

一、Word（傳統(tǒng)上的）

主要有四個部分組成(具體視你的產品要求進行劃分)盅粪，分別是：結構圖钓葫、全局說明、頻道功能湾揽、效果圖瓤逼。（牢牢記得讀者是技術人員，不要講廢話）

1库物、結構圖：

1.1霸旗、信息結構圖：主要是輔助服務端技術人員創(chuàng)建或調整數(shù)據結構的參考文件

1.2、產品結構圖：主要是輔助設計和技術開發(fā)人員了解產品的全局結構戚揭，他和用戶流程圖不一樣诱告，產品結構圖只是羅列出產品的頻道和頁面。

2民晒、全局說明：主要講解產品的全局性功能的說明精居，例如網站產品的頁面編碼、用戶角色潜必，移動產品的緩存機制靴姿、下載機制，這類全局性功能的說明磁滚。這里我舉一個移動產品的“狀態(tài)維持與恢復”的例子佛吓，示例如下：

狀態(tài)的維持與恢復

當用戶退出產品時（誤操作、Home鍵垂攘、鎖屏维雇、自動關機），產品需要維持用戶操作前的狀態(tài)晒他，當用戶返回產品時仍可以恢復到之前狀態(tài)吱型，并繼續(xù)使用。

維持狀態(tài)包括流程操作陨仅、信息瀏覽津滞、文本輸入、文件下載灼伤。

鎖屏狀態(tài)時触徐，如果用戶在產品中有下載任務時，仍然保持下載饺蔑。

3锌介、頻道功能：以頻道為單位，頁面為子項，分別描述產品的頻道孔祸、頁面及頁面模塊元素的功能需求(格式如下)：

示例格式

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

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

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

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

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

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

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

4复斥、效果圖：效果圖是由設計師完成的產品圖营密，和實際開發(fā)完成的產品保真度一致。

二目锭、圖片

圖片形式的PRD文檔是基于效果圖的說明文件评汰，將傳統(tǒng)Word形式的功能需求說明標注在效果圖上，這種方式經常使用在移動互聯(lián)網領域侣集，實際上是圖文形式的交互需求文件键俱，只是在此基礎上更深入的描述出功能需求兰绣。
對于圖片形式的PRD文檔世分，我們只需要另外再描述一下全局說明，其他頻道頁面的需求直接以圖片形式展示缀辩，這種方式相對于Word文檔的純文字更加生動易讀并且直觀臭埋，因此有一些產品經理非常喜歡用這種方式代替Word形式的PRD文檔。

三臀玄、交互原型（Axure RP）

直接在原型上標注說明功能需求瓢阴。

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

產品需求文檔的寫作(五) – 用例文檔(UML用例圖叠穆、流程圖)

用例文檔是由多個用例組成的一份文檔少漆，主要用于技術開發(fā)與測試使用，他是PRD中的重要輔助文檔硼被，用于講解某個環(huán)節(jié)的功能邏輯示损，例如用戶注冊、活動報名等等功能都是需要用例輔助說明的嚷硫。用例文檔的寫作時間在原型設計之后检访，通常和PRD文檔同步撰寫。

用例文檔中有兩個關聯(lián)文件仔掸，分別是用例圖和流程圖脆贵。用例圖是UML的一種類圖表現(xiàn)方式，是從用戶角度描述產品功能起暮，并指出該用戶在產品各功能中的操作權限丹禀。流程圖是通過線框圖形的方式描述產品功能的處理過程，主要是描述功能的執(zhí)行順序鞋怀、分支和循環(huán)的邏輯双泪。

寫用戶文檔的常用軟件是Word，其中用例圖和流程圖的制作軟件常用的是Visio密似，當然也有用Axure RP軟件制作的焙矛，例如下面的第三步流程圖就是用Axure RP制作的。

一份完整的用例文檔分別是由以下三點內容組成残腌，其中第3點的“用例”是描述功能邏輯的部分村斟，根據功能的多少決定有多少個用例。

用例文檔的大概組成部分如下：

1抛猫、修改記錄：每次修改的備注記錄蟆盹，同PRD文檔。

2闺金、角色介紹：描述參與系統(tǒng)中的各個角色

3逾滥、用例：同下方步驟的第4步，其中第3步中的流程圖是直接插入到第4步的流程圖表格項中的败匹。

用例文檔的模板格式如同以上三點內容寨昙，通過Word文檔繪制表格，在表格中撰寫用例描述掀亩，表格的格式和樣式參考以下示例圖舔哪。

1、撰寫用例文檔的第一步是注明使用產品的各個角色(參與者)和角色說明(角色介紹)槽棍。（如下圖）

角色及其說明

2捉蚤、第二步是以用例圖的方式注明角色在前后端的用例關系抬驴。（如下圖）

用例圖

3、第三步是以流程圖的方式注明角色在各個功能環(huán)節(jié)的活動過程缆巧。（如下圖：以活動報名為示例）

活動報名流程圖

4怎爵、第四步則是以用例文檔的方式將以上三步整合到一起，并撰寫各個功能環(huán)節(jié)的用例描述盅蝗。（如下圖）

整合

表格說明：

4.1鳖链、用例名：此功能環(huán)節(jié)的名稱

4.2、用例編號：在此產品中該用例的編號

原型頁面編號規(guī)則

比如在2016年3月份修改了一個頁面功能墩莫，該頁面編號為：A03-3芙委，那么我就知道是A級導航的3級頁面的第3個頁面修改了，這樣可以快速定位到需要查找的頁面狂秦。

4.3灌侣、行為角色：參與或操作(執(zhí)行)該功能的角色

4.4、簡要說明：用最少的文字描述一下該用例的需求

4.5裂问、前置條件：參與或操作(執(zhí)行)此功能的前提條件

4.6侧啼、后置條件：執(zhí)行完畢后的結果條件

4.7、流程圖：該功能的角色活動過程(處理過程)圖（第三步中的圖）

上面示范的用例描述相對簡單堪簿，也是最常用和基本的用例描述內容痊乾，當然也有稍微復雜一點的用例文檔，文檔中會詳細描述使用場景椭更、事件流和信息字段哪审，也有一些用例文檔還會插入產品界面效果圖。

使用場景主要描述行為角色在不同情況下使用產品時虑瀑，根據情況或問題給出相應的系統(tǒng)反饋湿滓。事件流類似流程圖，只不過是通過文字的方式描述角色的活動過程舌狗。信息字段主要是描述用例中所用到的數(shù)據字段叽奥。

PRD文檔標題：XX產品V1.0PRD_V2。前面的V1.0是產品迭代的編號痛侍，后面的V2 PRD的版本號

產品需求文檔(PRD)的寫作方法

唐杰的個人博客

網站產品設計：【未看】

https://tangjie.me/blog/17.html

https://tangjie.me/blog/15.html

移動產品設計：【未看】

https://tangjie.me/blog/36.html

https://tangjie.me/blog/47.html