起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品文檔（一）：“優秀”的文檔框架
需求文檔/產品文檔是每個產品經理的必經之路，優秀的產品文檔可以避免部分項目的重復溝通和編寫無效代碼，提高項目開發效率。
“這里是不是少了功能按鈕？”“這段話是什么意思？”“不行呀！你的文檔需要補充，不然怎么測試？”“口頭的需求文檔不算數，開發要見文字版文檔”。
關于產品文檔，我們總會遇到這樣的對話。那么如何避免呢，下文將仔細說到。
本文獻給0-1歲的產品經理，從需求文檔的目的、與用戶手冊的區別、需求文檔的構成的維度對需求文檔進行整體介紹，希望各位PM都可以輸出高效精簡、清晰明了的文檔。
一、目的
寫需求文檔前，首先要確定的是文檔的受眾群體和時間要求。受眾群體（誰去看）確定了文檔的框架架構和排版要求；時間要求限制了需求文檔的精細度和美觀度。
1.1 受眾群體
一般來說，需求文檔有三個受眾群體：
（1）開發團隊：包括產品團隊、UI、UX、技術和測試；這也是最常規的受眾群體，畢竟需求文檔是要闡述項目要實現的功能和實現的方法、規則。
（2）企業內部：如老板、商務團隊、運營團隊等；通常這部分群體不會在乎產品規則，他們只關心項目實現的功能和效果。
（3）其他：例如公司制度要求留檔、公司上市審計流程所需。我還見識過另一種過程：面試。如果在面試時提交的作品是需求文檔，那么請看“商用文檔”部分。
1.2 時間限制
如果只是開發團隊使用的需求文檔（以下簡稱開發用文檔），框架會比較簡單，排版也沒有非常嚴謹的要求，只需要做到邏輯閉環，場景盡善，表達清晰即可。如果是企業內部或其他用途的需求文檔（以下簡稱為商用文檔），除了開發用文檔的內容外，還需補充項目概述、需求分析等欄目，這部分將在下文“商用文檔”再詳細解釋。
在寫文檔前，PM心中必須要有期限和計劃，合理安排文檔的進度，不能在項目前期就發生延期的情況。
如果時間緊迫，首先要把關鍵的邏輯寫清楚，其他的細節可以在開發時或項目結束后補充，例如搜索功能、填寫字段的字符長度、頁面確定、關閉和返回等交互。特別是當項目團隊已有一定的合作經驗，建立了一定的工作默契時，這些細節在時間不允許情況下是可以省略，畢竟PM也有很多更值得做的事情。
但是，如果時間充?；蛘呤切碌拈_發團隊，個人還是建議需求文檔盡量精細，畢竟見過很多設計師、開發和測試吐槽需求文檔不清不楚，工作難以開展。再者，詳細的需求文檔，可以大大地減少開發團隊的理解誤區，一定程度上，既能避免無效設計和無效代碼，還能避免產品經理在投入下一個迭代工作時被開發“咨詢”過多。
二、題外話：使用手冊
有些-1到0.5歲的產品不是很清楚需求文檔和用戶手冊的區別。我曾經讓0歲的助理寫2B項目的用戶手冊，由于時間緊迫，加上他對項目還不算熟悉，我就把需求文檔的原文件發給了他，希望起幫助作用，結果最后交過來的作業卻是一個簡化版的需求文檔。
需求文檔描述的是項目的功能和產品邏輯、規則，偏向邏輯描述；而用戶手冊是描述項目的功能和使用流程，偏向操作流程說明。兩者間都需要告訴各自的讀者，功能是什么、有什么用；但出于目的不同，所以主題內容和詳細程度也會不一樣?？纯醇依锏碾娖魇褂谜f明書，就知道怎么寫使用手冊了。
三、PRD的構成
前文提及，因受眾群體不一樣，PRD可分為開發用文檔和商用文檔，除了在排版、美觀等有區別外，在內容上也有一定的區別。文終將會放上這兩個類型的文檔作為樣例給各位讀者參考。
3.1 開發用文檔
開發用的文檔只有一個宗旨：把需求說清楚說明白，大家知道要做什么功能，做到什么程度。
我個人也是寫開發用文檔比較多，慢慢形成了自己的框架規范。以后隨著經驗的積累，也會繼續優化這套方法論。
版本迭代記錄
主要是記錄一個項目各個產品版本的迭代情況，如V1.0，V1.1……V2.0……。這里強調的產品版本，主要是指產品功能的迭代。如果一個迭代只單純涉及到bug修復、交互優化、性能優化，記不記錄都可以，看個人意愿。
需要記錄的內容包括：版本號、更新日期（文檔定稿日期或者版本上線日期，個人更建議用版本上線日期）、主責產品經理、迭代的功能簡介（從業務場景出發，一句話描述一個功能模塊）。
版本修改記錄
主要是記錄單個版本（劃重點）的修改記錄。因為每個需求文檔都會經歷初稿、產品評審、技術評審、開發過程中N次細節調整、終稿這幾個過程，需要把每次修改的地方記錄下來，特別是當文檔已經對項目團隊公開后發生的修改。
需要記錄的內容包括：更新日期（每次文檔修改的日期）、產品經理（不等同該版本的主產品經理，特別是大項目有一個主產品經理，多個初中級產品經理）、修改說明（動了哪些邏輯，哪些頁面）。
版本迭代記錄是為了給以后的項目團隊使用，無論是產品還是開發，方便新成員或項目交接時快速了解項目的前世今生；版本修改記錄是給當前的開發團隊使用，方便快速了解產品又改了哪些邏輯，增加了哪些需求（溫馨提示：投入開發后真不要輕易加需求）。
流程圖
一般寫在文檔里的流程圖包括兩種：業務流程圖和邏輯流程圖，都是“非必填項”，視實際情況判斷是否需要用流程圖進行說明。因為在開發用文檔內，任何元素都是為了幫助產品經理清晰說明需求，如果業務很簡單，能用線框圖或者文字即可說明清楚，那么就沒必要費力氣去弄一個流程圖了。
業務流程圖：一般單個任務模塊從0-1的時候需要使用，幫助開發理解任務的每一個環節。通常會涉及到多個角色協作。例子見文末開發用需求文檔。
邏輯流程圖：單個任務或者單個環節涉及多重邏輯判斷時使用，幫助開發梳理if else后的操作行為。如果單純用文字描述這種邏輯判斷，開發還沒繞暈，產品自己可能就先繞暈了。
全局說明
在同一個系統內，在多個場景或者頁面內需要使用到相同的組件或者交互，把這類組件/交互的需求說明歸納到全局說明內，在正文內出現時做相關引用即可。
【舉個例子】
列表的排序規則，如果多個頁面的列表排序規則都是一樣，則在全局說明內新增一個版塊對其進行詳細說明，而在正文的相關頁面注明“排序規則請參照全局說明XXXX”即可。
又如系統管理后臺，編輯頁面的保存/取消功能，直接在全局說明內說明，點擊保存/取消時會出現XXX提示，確認后系統的執行結果；即使在實際頁面中，保存/取消屬于不同的內容編輯頁面，但其交互幾乎都是一致的，就沒有必要在多個頁面重復說明。如果遇到特例，與全局說明內的需求不一樣，在對應的頁面再另行說明。
建立全局說明板塊，不僅能在寫需求文檔是節省重復勞動的時間，而且在修改需求文檔過程中也能省掉很多繁瑣的事，就如Axure中“母版”一樣便捷，改一處即把相關的地方都完成修改。
正文
就是每個頁面的需求細節，包括線框圖/高保真，邏輯說明和交互說明。
關于交互說明，一般大公司才會有專職的交互設計師并撰寫交互文檔，其他公司通常由產品經理和UI設計師一起承擔交互設計。但無論是否有專職的交互設計師，我認為作為一名產品經理，在需求文檔內也要明確指出部分交互說明，提供一個大方向給設計師工作，特別是對于系統的空白頁或類空白頁。
【舉個例子】
前段時間在處理一個小功能：在非電話客服工作時間內，用戶點擊電話客服按鈕時，需彈出提示并引導用戶在線留言。
以下是第一版和第二版設計的效果：最終使用的是第二版。
由于當時需求內沒有詳細說明交互意圖，UI設計師被線框圖誤導，出了第一版本；我看了設計后不太滿意，與UI設計師溝通想法后，最終修改為第二版并投入開發。
兩個版本的信息內容是一樣的，但由于信息側重點相反，因此這兩個提示的功能也不一致。第一版側重于告訴用戶“當前客服不在線”；第二版側重于引導用戶在線留言。產品是要為用戶提供解決方案，而不是把問題拋回給用戶。
3.2 商用文檔
相對于開發用文檔，商用文檔幾乎是面面俱到，盡善盡美，能擺到桌面上的需求文檔，以下列出了二者的框架對比。
寫商用文檔無形中也會給產品經理增加非常大的工作量，因此可按公司要求和個人習慣結合去選擇即可。
封面
每一份商業化文檔，都會要求有一個封面，簡單羅列系統名稱、文檔名稱、文檔設計者（企業或者個人）、定稿時間即可。
目錄
目錄的粒度，需要細致到哪級標題，按需設置即可。
概述
包括項目背景、項目介紹，用一兩段話簡要說明。
使用人群
給誰看就列明誰，如系統開發團隊，相關行業設計師等。
需求分析
主要寫項目前期開展的調研和分析而得出的結論，包括產品定位——項目核心用戶群、市場競爭優勢，和用戶故事——用5W1H方法表明解決的痛點。
系統字典
對系統或者文檔內的一些專業用詞進行解釋，或對同一事物進行命名規范。系統字典不僅是一個項目內使用，甚至每個部門或每間公司都可以用相關概念，特別當團隊剛剛組建時，使用系統字典概念能夠解決很多溝通上的誤會。
【舉個例子】
就如上文的“全局說明”，這里用“全局”代指整個系統的概念。但實際，更多的公司/團隊用“全域”來指代整個系統。但由于公司是旅游行業，“全域”一詞是行業內的專有術語，并且也是公司的業務術語，如果用“全域”來表示整個系統，在溝通時常常會引起誤解，因此公司內部都習慣使用“全局”來指代整個項目系統。
結語
以上便是從大框架層面介紹優秀的產品文檔需要涵蓋的內容，后續將在系列（二）中，從需求文檔——正文的角度介紹本人寫產品文檔的小技巧和tips。整個系列均屬作者本人的見解，歡迎交流。
另附樣例作為參考：
開發用文檔：https://h82yzy.axshare.com/#g=1&p=%E7%89%88%E6%9C%AC%E8%AE%B0%E5%BD%95
商用文檔：（提取碼：rqff）
https://pan.baidu.com/s/12q-jRKPzqp_Qgt_2R0MJ2A
（備注：商用文檔為“當年”自學轉行產品時的作業，相對稚嫩，大家看看框架即可，不必較真哈）
本文由 @貓爪 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
請問產品文檔是在哪寫的啊？是畫完Axure截圖過去的嗎？還是直接在Axure那個軟件就可以寫?還是要去Axure cloud？你的好專業，我雖然當了一年產品助理，但是我們公司從來沒有規范的文檔，但是即時設計+說明就完了。但是現在有新產品了，很復雜，得用你那種文檔才能說清楚了。求回復
哈嘍想咨詢一下，文檔結構最后的第12項“正文”部分主要包括的內容是什么？上面的3-11不算正文嗎？
“正文”指的是每一個功能的產品規則或者交互說明，以觀看視頻為例，連了wifi且網絡快時，自動播放最優質畫面；連了wifi但網絡一般時，畫面質量自動降級；沒有wifi要用流量且網絡快時，詢問用戶播放哪種畫質……等等，列出各種情況?！吧厦娴?-11”更多的是幫助文檔讀者快速了解文檔內容。
寫競品分析、PRD等產品工作的相關文檔，看似普通又基礎，卻是產品經理在追蹤行業情況、將需求落地為產品的過程中必不可少的步驟，并且將貫穿產品經理的整個職業生涯。然而，0-2歲的產品新人普遍存在盲目套模板、文檔邏輯混亂等問題。
為了幫助產品新人快速掌握文檔撰寫基本功，這里推薦由起點學院聯合惠買集團產品總監@陳濱淋 老師打造的【15天掌握產品經理必備文檔】學習計劃。從實例出發，帶你高強度系統性學習11大類常用的產品工作文檔，快速幫你規范化日常文檔，提升工作效率>>>http://996.pm/71GE5
小白都算不上的產品，該怎么寫項目排期
太久沒登錄，現在回復好像來不及了~~~如果你說的項目排期指的是開發上線，那么你先要弄清楚需要排期的項目流程，包括但不限于需求分析、原型設計、UI設計、開發、測試、UI驗收、產品驗收、上線準備。各個環節除了產品外，涉及到哪些人，他們能花在這個項目的時間是怎么樣，專業能力是怎么樣，讓他們給你一個時間，然后為了避免意外，你的時間規劃至少在他們給你的時間上×1.2~~~PS，實際上，我自己做項目排期也沒有上述那么復雜喇，哈哈哈~~~培養了團隊默契，項目排期還是挺容易的。
貓爪是不是妹子
up主好呀，上面那個開發用的文檔打不開，請問你這邊可以發下rp文件嗎~ ?
不好意思，不太方便發rp原文件；開發用的文檔鏈接是直接托管在Axure，load得有點慢，見諒；以后要找找方法“優化”一下這個用戶體驗。 ??
謝推薦~~~ ??
Axure托管加載慢是因為服務器在國外，替代方案是使用產品大牛托管，你可以試試，訪問會快很多
厲害
謝謝夸賞 ??
舉個例子里，有兩個致命問題。
1.圖一需要自己計算是否在時間段內，圖二文字太多。
2.圖一圖二都沒有聯系方式或留言入口，我根本不知道怎么留言，還讓我點“我知道了”。
剛看到是點了客服電話按鈕后出現的彈窗，上面第2條，改為：圖一圖二都沒有留言入口，我根本不知道怎么留言，還讓我點“我知道了”。
哈哈哈，1.彈窗是否出現，已經由程序自動判斷了，在電話客服的工作時間內是直接撥打電話，不會出現這個彈框~~~2.由于是公司的上線項目，覺得不方便截全屏圖，所以留言的地方沒有在示例圖顯示；這個頁面的底層是對話頁面，點“我知道了”后，彈框會消失，用戶在對話頁面直接留言即可。
666
嗯嗯，了解了，可以適當把彈窗上的文字減少一些。
方案1：把按鈕文案改為【知道了，去留言】，會好一些。
方案2：或者直接進入留言頁面，在該頁面頂部橫幅解釋一下為什么沒有撥電話而是進入這樣一個頁面。能減少頁面，總感覺那個彈窗多余了。
哈，感謝你提供的方案（此處應有掌聲）
我也覺得彈框文字太多，彈框一般不適合承載過多的信息；
關于方案2，就是屬于交互體驗的討論：什么時候適合用什么提示方式。感覺又有可以寫文章的內容了耶~~~ ??
彈窗不多余，底部按鈕可以放兩個，一個取消，一個去留言。