不同于C端產品對于體驗的關注，中后臺產品更注重邏輯的嚴謹、流程的完整、使用的穩定性等底層邏輯，因此在撰寫中后臺產品原型時，需要先明確，產品文檔是寫給誰的，再參照業務流程、系統規則（正常/異常）、頁面結構（頁面間/頁面內）、交互形式、字段說明、數據結構這幾個關鍵點，進行產出，這樣在形式上就不會有太大的遺漏。來看看作者是怎么做的吧。

不同于C端產品對于體驗的關注，中后臺產品更注重邏輯的嚴謹、流程的完整、使用的穩定性等底層邏輯，因此中后臺產品原型的設計需要關注的點更復雜，今天我們來聊一聊如何寫好一套中后臺產品文檔。

一、產品文檔寫給誰看

作為產品，撰寫產品文檔是工作職責內的本分，但是我們是否考慮過，除了寫出來感動自己、證明工作量以外，這套文檔是給誰看的？只有明確了給誰看，才能進一步明確文檔要呈現的內容范圍。

1、給業務看

產品文檔是業務需求實現的藍圖，好的產品一定是充分滿足了業務需求，為了保證產品設計與業務需求準確匹配，產品文檔應該在設計過程中與業務方頻繁的確認，保證在與技術評審之前得到業務方的確認。

業務所關注的是業務邏輯的正確性和頁面內容的完整性，所以文檔設計的時候要考慮到業務流程圖的示意和頁面字段的解釋。

這里要注意的是，業務方包括但不限于需求方，還可能包含系統功能鏈條上的其他業務方，比如一些需要限制權限的功能，可能還需要和系統管理員去溝通權限點的設計細節。

2、給UI/前端看

我們知道，產品的五層結構包括了：表現層（視覺設計）、架構層（界面布局和信息內容）、結構層（交互和信息結構）、范圍層（功能規范和內容需求）、戰略層（用戶需求和運營目標）。

在這五個層級里面，表現層和架構層是用戶看得到的，直接影響了用戶對產品的理解和體驗感受，這兩層在實際的項目中屬于UI/前端（有時還有用戶體驗這樣的職位）人員負責的范圍，所以在進行產品文檔撰寫的時候，要注意明確頁面結構和交互呈現形式的說明。

3、給后端開發看

產品的五層結構中，結構層和范圍層是用戶看不到的層面，這是后端開發的工作范圍。為了讓后端開發充分的理解系統結構和數據結構，產品文檔不能只“畫圖”，還應該對底層的數據、流程和邏輯做充分的說明。有些需要接口對接的需求，還需要明確對接的接口、字段和規則。

4、給測試看

測試是需求的第一個使用者，只有充分理解了產品設計規則，才能明確的撰寫測試用例并進行系統功能的驗證，測試需要考慮到一般場景和異常場景下系統的處理策略，所以產品應該提前預想到異常的場景，并在文檔中給出處理策略。

二、文檔形式

在分析了給誰看的問題以后，我們找到了產品文檔需要呈現出的幾個關鍵點：業務流程、系統規則（正常/異常）、頁面結構（頁面間/頁面內）、交互形式、字段說明、數據結構，有了這些關鍵點作為參照，產品文檔在形式上就不會有太大遺漏。

基于這些關鍵點撰寫產品文檔時，規范來講會產出PRD文檔，即以圖文的形式從各個角度去描述系統的功能，但是如果沒有特殊要求的情況下，筆者一般會用產品原型的形式產出產品文檔，當然無論文檔形式如何，都應該確保包含了上述關鍵點。

1、規范版：圖文結合的PRD文檔

下圖中，筆者整理了PRD文檔的一套目錄，需要的產品朋友按照這個目錄去整理需求文檔，就可以比較全面的包含需求的各個重點：

1. 需求背景介紹，描述需求產生的背景以及需求方希望達到的效果，如果有關聯業務方也應該予以說明。如果是給外部需求的項目，還應該簡單的介紹外部需求方的情況，如公司現狀和業務模式等；
2. 核心規則說明，描述業務邏輯以及產品設計的基本規則，如果文檔中涉及到多套業務場景，應該首先解釋多個業務場景之間的關系和區別，然后再做逐個介紹，這里除了可以用文字和圖表的形式說明，還可以加入梳理好的業務流程圖方便讀者理解；
3. 特殊規則說明，這部分是對一些特殊場景或者特殊規則的說明，在說明的時候應該明確與一般規則之間的關聯，這部分不一定每個需求都需要，可以酌情刪減；
4. 數據源，說明底層數據的來源以及應用，包括內部來源和外部來源，內部來源是系統本身產生的數據，外部來源包括接口調取的數據和爬蟲獲取的數據等，為功能和頁面設計中的字段說明做準備；
5. 功能以及頁面設計，描述每個功能模塊的范圍，展示內含的產品設計頁面圖，并對頁面中的字段做字段性質說明、操作按鈕做交互說明，涉及到權限的還應該做可見/可用權限說明；
6. 在文檔結構只上，如果是同一個模塊下頻繁的在一個文檔中修改，則應該增加文檔的版本記錄，以記錄下每期需求變更的范圍。

2、草根版：五臟俱全的原型圖

下圖是筆者常用的產品文檔，以原型文檔為載體（不拘泥與墨刀或者RP），按照實際的模塊頁面結構去撰寫，在頁面結構之外再配合統一的版本記錄和規則說明。在此結構下可以完善的表達系統的表現層（視覺設計）、架構層（界面布局和信息內容）、結構層（交互和信息結構）、范圍層（功能規范和內容需求）、戰略層（用戶需求和運營目標）的產品邏輯：

1）版本記錄

因為中后臺模塊邏輯關聯性很強，所以建議一個模塊一套原型，在一套原型下去做不同版本的變更，當然如果遇到大的變更還是建議將歷史版本單獨備份。版本記錄這里就是記錄此模塊下每個版本變更的業務背景、業務目標、變更的系統規則和變更的系統頁面范圍；

2）規則說明

這里一般會包含業務流程的詳細描述和流程圖、核心的業務計算邏輯、數據源和數據邏輯、涉及到權限則需要說明權限范圍。這里不要只拘泥于文字的描述，要更多的使用表格和圖形，方便規則的解釋，另外，規則如果有變更的，應該說明變更前和變更后兩套邏輯分別是什么，方便讀者理背景和目標；

3）系統頁面

i 頁面的編號：按照實際要實現的頁面結構撰寫，每個頁面按照結構編號，這里做編號有兩個好處，一是在描述頁面之間關聯的時候可以準確的指定某個頁面，比如“跳轉到1.1”或“數據取自2.1中的XX字段”，二是在進行產研溝通的時候節省了解釋的成本，畢竟有些頁面的名稱比較近似。這里的編號不要隨版本變化修改，如果有新的頁面就給與新的編號，避免引起混亂；

ii 主頁面的描述：包含多個子頁面的主要頁面，一般單獨展示一個頁面，這樣能夠保證原型邏輯與實際頁面邏輯的一致性，方便前端的理解；在原型撰寫的時候，主頁面的描述中突出下屬每個子頁面的功能范圍；

iii 子頁面的描述：詳細的頁面中主要呈現頁面中所包含的內容以及操作，并解釋說明內容和操作的詳細規則。在進行說明的時候，首先要為頁面劃分大的區域，比如篩選區域、列表區域等，然后針對每個區域需要說明要素的名稱和類型（字段/按鈕/鏈接等），在對每個要素詳細說明。詳細說明要素的時候需要注意說明關聯的彈窗、操作，并說明交互和系統判斷的邏輯，注意要考慮到異常反饋的邏輯，涉及到計算的還應該說明數據的來源和計算規則。

下圖是筆者在實際業務中頁面的說明文檔：

三、其他重要的點

1、不拘形式

每個項目會有自己的特點、每個需求中的側重點也會不一樣，比如數據系統關注數據的來源和邏輯、工單系統關注業務流程、客戶系統關注用戶的信息和標簽，要根據實際的業務需求選擇產品文檔的撰寫形式，只要能做到讓所有讀者充分理解，就是好的產品文檔；

2、心態要穩

不要被完美主義心態牽制，自己覺得再完美的文檔，也總會有人想要來挑刺，自己對自己要有個認知和定位，必要被外界的評論過分影響，只要不斷進步就是好的；也不要怕變化，如果聽到不一樣的聲音發現那是對的，那就吸收它然后成長為自己的能力。