起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品需求文檔的寫作(四) – 撰寫文檔(PRD文檔)
前三篇文章我們逐步梳理了產品的信息結構、框架結構、界面結構(原型)，這一步我們就要根據之前完成的工作，開始正式撰寫產品需求文檔了(PRD文檔)。 通過之前的準備工作，我們更加清楚了產品的需求，并細致的考慮了方案的可行性，從而減少與避免了撰寫文檔時容易忽略的細節黑洞。 PRD文檔沒有標準的規范，也沒有統一的模板，每個公司都不一樣，并且每個人也不一樣，這個取決于個人習慣和團隊要求。雖然PRD文檔沒有標準的規范，但是有兩項是必不可少的，那就是文件標識和修改記錄。文檔在撰寫過程中，我們可以自行不斷的修改完善，但是如果正式發布或交給團隊其他成員后，一旦有了修改，為了文檔的同步，我們就需要標注出文檔的修改內容，備注修改記錄。關于文件標識和修改記錄，大家的格式都大同小異(如下圖)。 PRD文檔的形式常見的有以下三種：Word、圖片、交互原型 這是傳統意義上的PRD文檔，主要有四個部分組成(具體視你的產品要求進行劃分)，分別是：結構圖、全局說明、頻道功能、效果圖。（在第一篇文章里我有講過，PRD文檔的閱讀者更多是偏向于技術人員，因此PRD文檔目的性很明確，就是要描述產品的功能需求，所有PRD文檔是沒有關于市場方面的描述，同時我也建議大家盡量減少不必要的文字，在能夠讓閱讀者看懂并且了解產品意圖的情況下，文字越少越好。這主要是因為絕大多數人是沒有足夠耐心認真看完PRD文檔的，因此我們要盡量減化文檔內容。） 1、結構圖： 2、全局說明：主要講解產品的全局性功能的說明，例如網站產品的頁面編碼、用戶角色，移動產品的緩存機制、下載機制，這類全局性功能的說明。這里我舉一個移動產品的“狀態維持與恢復”的例子，示例如下。 狀態的維持與恢復 產品需求文檔 示例： 3、頻道功能：以頻道為單位，頁面為子項，分別描述產品的頻道、頁面及頁面模塊元素的功能需求(格式如下)。 示例格式 在撰寫功能需求時，我們需要考慮用戶的流程，例如一個“完成”按鈕，我們需要描述他完成后，系統要不要給出反饋提示(反饋提示是什么樣的形式反饋，內容顯示成什么，有沒有內容需要調取數據庫)，或者要不要跳轉頁面(跳轉到哪個頁面，這個頁面是其他頻道頁面，還是這個功能的子頁面，如果是子頁面就需要再描述這個子頁面的模塊及元素內容)。 4、效果圖：效果圖是由設計師完成的產品圖，和實際開發完成的產品保真度一致。 圖片形式的PRD文檔是基于效果圖的說明文件，將傳統Word形式的功能需求說明標注在效果圖上，這種方式經常使用在移動互聯網領域，實際上是圖文形式的交互需求文件，只是在此基礎上更深入的描述出功能需求。 對于圖片形式的PRD文檔，我們只需要另外再描述一下全局說明，其他頻道頁面的需求直接以圖片形式展示，這種方式相對于Word文檔的純文字更加生動易讀并且直觀，因此有一些產品經理非常喜歡用這種方式代替Word形式的PRD文檔。 這里指的交互原型就是上一篇文章講的原型設計，使用Axure PR之類的交互原型設計軟件制作出來的產品原型非常真實和直觀，并且原型軟件還支持元素標注和導出Word文檔，因此很多產品經理都喜歡使用Axure PR來代替Word完成PRD文檔。 當我們通過Axure PR制作出產品原型后，實際上他已經是很完善的產品Demo了，因此我們只需要加上元素的標注，在標注中說明功能需求，這樣導出的HTML文件相比Word文檔更直觀易懂，是非常高效的產品需求說明方式。 ——— 無論你采用哪種方式產出需求文檔，最終的目的都是為了方便團隊成員理解產品的意圖，因此哪種方法能夠避免細節黑洞，高效完成產品的設計和研發，那么這種方法就是最有效的方法。 好了，關于《產品需求文檔(PRD)的寫作》的介紹寫完了，一共四篇文章，希望能夠幫助到你，如果覺得文章中有什么錯誤或者有疑問，歡迎評論留言。 產品需求文檔(PRD)的寫作：
一、Word
1.1、信息結構圖：主要是輔助服務端技術人員創建或調整數據結構的參考文件
1.2、產品結構圖：主要是輔助設計和技術開發人員了解產品的全局結構，他和用戶流程圖不一樣，產品結構圖只是羅列出產品的頻道和頁面。
當用戶退出產品時（誤操作、Home鍵、鎖屏、自動關機），產品需要維持用戶操作前的狀態，當用戶返回產品時仍可以恢復到之前狀態，并繼續使用。
維持狀態包括流程操作、信息瀏覽、文本輸入、文件下載。
鎖屏狀態時，如果用戶在產品中有下載任務時，仍然保持下載。
1、頻道名：頻道介紹及需求說明
2、頁面1：頁面介紹及需求說明
2.1、頁面模塊1：模塊功能需求說明
2.1.1、頁面模塊1-元素1：功能說明
2.1.2、頁面模塊1-元素2：功能說明
2.2、頁面模塊2：模塊功能需求說明二、圖片
三、交互原型
產品需求文檔(PRD)的寫作方法（文章的摘要介紹）
產品需求文檔的寫作(一) – 寫前準備(信息結構圖)
產品需求文檔的寫作(二) – 梳理需求(產品結構圖和用戶流程圖)
產品需求文檔的寫作(三) – 原型設計(手繪原型,灰模原型,交互原型)
產品需求文檔的寫作(四) – 撰寫文檔(PRD文檔)
產品需求文檔的寫作(五) – 用例文檔(UML用例圖、流程圖)
本文出自 產品經理 唐杰
感謝！
感謝
一個小白想問個白癡的問題，產品需求文檔現實生活中也是這么多嗎
到現在沒寫過完整的需求文檔，因為來不及也用不著= -=，基本上都是直接畫原型了；但是項目進入空檔期需要補寫一下，既是一種回顧補充，也是一種很好的記錄；
鏈接失效了ε(┬┬﹏┬┬)3，求鏈接文檔，希望大神能發一份或補個下載鏈接…ivin_992@163.com，非常感謝！
大神！求鏈接文檔！求求求
??
745203822@qq.com，希望大神發一份，雖然有伸手黨的感覺，不過真心的想從大神這里學習到干貨。。。謝謝大神
大神欣賞你很久了 可否發一份文件 353029690@qq.com 謝謝
也給我轉一份吧 lijing_world@163.com 謝啦
下載地址失效，跪求源文件 。郵箱337677131@qq.com
文檔示例的干貨啊，我們不想不勞而獲，主要是想從您的文檔結構中看到您寫文檔時的思維邏輯，一個產品需求文檔是怎么分解產品的。
下載地址真的失效了,請您再發個鏈接吧，我的郵箱1210601732@qq.com
下載地址真的失效了,請您再發個鏈接吧
下載地址已失效,求文檔 710082596@qq.com
不錯
這句話很贊同：
無論你采用哪種方式產出需求文檔，最終的目的都是為了方便團隊成員理解產品的意圖，因此哪種方法能夠避免細節黑洞，高效完成產品的設計和研發，那么這種方法就是最有效的方法。
看不到文檔例子了 ??
產品需求文檔示例分享沒了~~~ ??
有那我大神知道，此文表格中的“文件標識”為ipad 是什么意思啊 ？？
下載地址沒了 ?? ?? ?? 求好心人分享啊
，下載地址已失效，求分享文檔案例
文檔分享鏈接失效了，求好心人分享啊
文檔示例不見了 ?? ?? 哪位大神能否共享一下，讓小妹多學習一下 ?? ??
文檔示例不見了……… ??
??
新人挖墳。。。難道沒有人發現AxurePR有問題嗎，是RP好嗎＝ ＝。。。
產品需求文檔示例分享沒了~~~
謝謝唐老師的分享，很有收獲。
整理的不錯
閱過留痕
不錯，mark
mark