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

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

一、產(chǎn)品文檔寫給誰看

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

1、給業(yè)務看

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

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

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

2、給UI/前端看

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

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

3、給后端開發(fā)看

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

4、給測試看

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

二、文檔形式

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

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

1、規(guī)范版：圖文結合的PRD文檔

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

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

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

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

1）版本記錄

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

2）規(guī)則說明

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

3）系統(tǒng)頁面

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

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

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

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

三、其他重要的點

1、不拘形式

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

2、心態(tài)要穩(wěn)

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