本文來自《現代企業應用設計指南》一書的試讀章節：第三章《理解，分析和表達用戶需求》。

歡迎閱讀并提供改進意見，在知乎上關注我。作者郵箱 phil.ren@mingdao.com

文/明道創始人任向暉

3.3 產品需求文檔

3.3.1 開始撰寫產品需求文檔前的準備

在軟件產品設計領域，PRD（產品需求文檔）是最重要的文書。很多產品設計人員在接到設計任務后會急于開始撰寫，同時非常在意PRD形式的完整性。在互聯網上，也有大量的公開PRD模版可以獲得，感覺可以按照填表格的方式來完成它。但是，不要過于著急。在開始撰寫PRD之前，我們需要通過和需求方的溝通和確認，事先對以下內容達成了共識：

1）明確了產品設計的目標是為了解決哪些用戶的哪些問題，它對企業的商業目的實現起到了什么作用？（要做什么）

2）開發項目的投入資源怎樣？可以有多少產品研發人員？給出了多長的時間窗口？（能有多少資源）

3）我們要交付的最小化產品要達到什么標準？是否有對標的競爭對手或者其他產品可以幫助衡量？（要做到怎么樣）

3.3.2 PRD的常見誤區

1）混合而不分層次地陳述需求，缺失由總到分，由高到低，由粗到細的層次結構。這個問題通常是因為在PRD起草之前的討論和總結不夠有條理造成。結構化腦圖可以幫助團隊在動筆之前先建立好這個層次結構，將該腦圖作為PRD文檔的一部分也可以。

2）缺乏經驗的設計者因為擔心遺漏，追求一個過度完整的PRD，不僅事無巨細，而且把遠期和非必要的需求羅列得過多，從而模糊了交付標準的界限。實際上，沒有軟件產品是依靠第一個版本的PRD管得太久的。要么PRD需要持續迭代，要么需要建立后續升級版本的PRD，設計者無需追求PRD的絕對完整。

3）設計者越俎代庖，不是描述需求，而是描述了解決方案。這個看似是全面能力的體現，但卻對高產出的協作帶來障礙。按照專業分工的要求，產品設計者應該著眼于需求和實現目標的描述，而不是替代架構師和工程師來設計具體的數據表結構和邏輯實現方法。

4）過度使用視覺輔助，而忽略對需求實質的描述。產品設計人員喜歡大量使用腦圖等圖表來表達邏輯結構，卻對需求的實質缺乏自然的描寫。雖說一圖勝千言，但在需求文檔中，除了參數和標準等具體的表格信息，其他視覺內容起到的主要是輔助表達作用。當然，另外一個極端也是PRD文檔容易出現的問題，那就是對于復雜的需求缺失視覺輔助呈現，導致管理層和開發人員需要花很長的時間來閱讀和理解。在義、文、圖之間，產品設計者需要按照實際表達的需要組合使用。

3.3.3 PRD的基本構成和擴展

我們做了大量的討論、分析和總結，接下來就是真的要動手寫出第一份產品需求文檔了。優秀的PRD絕對不是來自它的模版結構，也不依賴它的篇幅長短，而是用最小的篇幅讓開發者準確理解了產品開發意圖。一份相對規范的PRD總會包含一些不可或缺的內容，根據應用產品的性質，它可能還需要更加豐富的擴展內容，完整和詳簡程度取決于設計開發團隊的成熟度、應用產品本身的重要度和質量風險等多個因素。

以下列出了一份完整的PRD可能包含的所有模塊，其中有一部分是根據需要可選擴展的。為了讓你更清晰地理解每部分內容的性質和作用，我們全程使用了一個慈善業募款管理軟件的例子。

1）開發目的

用最自然通俗的語言說明為什么要開發這個企業應用，它能夠給用戶企業帶來什么價值。這是看似簡單，但很容易被忽略的部分。我們在之前介紹了“三層次需求分析”的方法，那么在“開發目的”的章節就是要將其中的“整體商業目標”通俗易懂地準確表達出來。

如果你要為本企業開發一個定制應用，那么你需要闡述對本公司的商業意義；如果你是一家軟件公司，要開發一個軟件產品，要描述它對目標服務客戶企業的價值。對于軟件產品開發企業，說明開發一款產品的目的是為了進入某某市場，獲得客戶和收入不是PRD應該描寫的開發目的。

我們舉一個軟件產品開發目的的例子。比如一款面向慈善組織的募款管理軟件，它可以用以下簡明扼要的文字闡明開發目的。

幫助慈善組織管理好募款過程，捐款人資料和援助項目的預算和實際開支信息，從而為該慈善機構提高核心工作流程的準確度和效率，增加用款信息的透明度，提高捐款人的滿意度和忠誠度。

2）服務受眾

在這個章節，產品設計者要列出產品所服務的多層次角色。他們是誰，各自有什么樣的工作目標，這個產品將幫助到他們解決哪些問題。在列舉服務受眾的角色時，要窮舉所有的可能，而且不能含糊交叉，不要用“管理人員”、“普通用戶”這樣的概括性角色名稱。

繼續上面慈善行業軟件的例子，這個產品可能要服務的對象有：

公關市場經理：使用捐款人管理模塊管理捐款人信息，定向和按照自動規則發送營銷Email。

募資項目經理：通過捐款人和募款管理模塊記錄募款記錄，發放收款憑證。

慈善項目經理：通過善款項目管理模塊，管理支出，生成項目財務報表。

財務經理：復核和經辦善款支出，記錄和核對募款記錄，建立相關財務憑證。

負責人：通過統計模塊了解善款使用分布、捐款人分布和行為分析，完成項目開支審批。

管理員：配置產品使用必要的參數，創建用戶，分配權限。通常由負責人兼任。

通過服務對象的羅列，可以幫助我們繼續樹立產品需求，遍歷可能的用戶故事，設計必要的產品特性。同時，也對整個產品的開發規模有更加精確的預計。

3）命名約定

命名是所有的產品技術文檔的核心，它的質量甚至會影響到開發編碼的環節。缺少命名約定的文檔無論是書寫還是閱讀都會很困難。在PRD中，要對涉及的主要數據對象、參數、概念、功能和用戶動作進行規范命名和釋義。這個命名一旦確定后，就需要連貫使用，在PRD文檔全文、后期拓展的原型設計、研發溝通過程和未來的用戶幫助文檔撰寫中統一使用，不能隨意變更。

在企業軟件中，用戶引導和教育是一個非常艱巨的過程，而命名是維系和加強這個過程的重要基礎，否則在未來寫用戶幫助文檔的時候就會混亂不堪。

當然，PRD的命名不需要面面俱到，只要針對應用中獨特的對象進行命名約定即可。對于通用領域的一般概念，我們只需要在設計范式中約定即可。比如“募款”是產品PRD需要定義的功能模塊，但是“刪除”、“導出”這些概念是不需要在命名約定中出現的。

4）用戶故事

用戶故事，也可以稱為“用戶場景描述”，是產品PRD在進入功能需求描述之前，用非產品視角來表達用戶需求的一種方法。它完全站在用戶的角度，描述他們將來使用這個產品來完成一項重要工作的全過程。如果有必要，也可以對比說明不使用這個軟件產品的對應解決方案，從而讓產品設計者對這個軟件產品將要解決的問題有更加清晰的描述。

用戶故事也不需要覆蓋所有的用戶場景，只需要選擇那些比較核心的用戶問題，尤其是那些占用戶80%時間的20%用戶場景。

我們繼續舉一個募款管理軟件的用戶故事：

用戶故事：募款項目經理錄入一個批次的捐款信息

募款項目經理通過和公關市場部的協作獲得了數百位捐款人通過公眾號微信支付的5萬元善款。微信支付后臺導出了所有捐款人的訂單和付款信息。捐款人的個人資料和聯系方法已經合并到了一個Excel文件，每個獨立的捐款記錄一行，其中已經標記了付款完成狀況。

現在募款項目經理需要通過軟件直接導入這些捐款記錄。通過募款管理的導入募款記錄功能，他直接上傳Excel文件，系統會提示創建一個募款項目批次，上傳完成后顯示有多少條符合條件的記錄，Review一致后，所有的捐款記錄都被導入，新的捐款人（根據身份證號字段識別）被創建為新的捐款人記錄。在導入的捐款記錄中，已經被標記上對應的募款項目ID。導入完成后，系統提示總計成功導入條數、創建捐款人記錄數和捐款總金額。通過和原始數據的對比，募款項目經理確認完成了導入工作。

通過這個例子，我們會發現用戶故事的描述和產品功能描述有類似的地方，但著眼于不同的角度和細節。好用的功能特性設計來源其實就是這些用戶故事場景的還原。很多PRD容易忽略用戶故事的描述，而直接進入了功能特性的設計描述，就容易產生用戶體驗的重大斷層。比如上例中，為什么要創建募款項目批次，在批次下導入具體的捐款數據，這個和用戶在實際工作中的場景是密不可分的。如果設計者把這個功能設計為在線輸入單條的捐款記錄，或者無批次地直接導入多行的捐款記錄，就會讓未來用戶陷入使用的痛苦之中。

撰寫出的用戶故事本身看起來并不復雜，相反，它可能是整個PRD文檔部分最富有人性的部分。如果拿著PRD文檔給普通用戶閱讀，這可能是他們最喜歡閱讀，也最容易理解的部分。但是，用戶故事的撰寫并不依賴好文筆，它來自細致入微的用戶觀察和調研。在上例中，如果不和多位慈善機構的募款項目經理交談，是不可能了解他們工作中的準確痛點的。而且，在實踐中，大多數企業用戶在主動描述自己需求的時候，并不會很完整，有些對他們未來使用很關鍵的細節特性，他們自己卻在需求表達時容易忽略。

有些產品設計者非常信賴自己的直覺，尤其是那些有消費者應用設計經驗的人。他們力圖跳過繁復冗長的用戶調研，直接進入設計階段，但是在企業軟件世界，這是絕對不可能允許發生的。如果你不調研醫院員工和管理層的工作，絕無可能設計出醫療服務管理應用；如果你不去拜訪工程項目經理，也絕對不可能設計出工程項目管理軟件。直覺在企業應用需求管理中的價值要遠比在其他領域低。

5）特性組合

特性組合是PRD文檔中的主體內容。在陳述清楚了開發目的、服務受眾，建立了命名約定，描述了用戶核心需求場景后，我們需要通過特性組合完整詳盡地列出產品開發需求。

在撰寫此部分之前，需要再次明確，產品需求的文檔的主要讀者是軟件開發人員，因此，一定要牢記通過特性組合陳述需求，而不是給出解決方案。過于簡單的特性描述沒有完整傳遞需求，但是過度詳細的特性描述也會容易制約開發者解決問題的靈活性。

用特性地圖（Feature Map）開始

為了有序地講述一個復雜企業產品的需求，首先需要通過一個綱要或者視覺列出所有特性的邏輯結構。表格和腦圖都是很好的表達工具，它從整體上先勾勒出特性組合的全局分布。這和我們之前講到的產品需求三層次是同一個道理。越是復雜的事物，越需要從簡單的大局開始。

結合上文提到的慈善項目管理軟件的例子，下圖給出了這個應用一個簡化的特性組合視覺表達。通過腦圖來繪制這樣的圖形會很有條理。腦圖還能夠表達出用戶在一個產品上的基本使用路徑、功能特性之間的聯系。

如果開發的是一個Web應用，這個特性地圖基本就等同于未來的站點地圖（sitemap）了。設計特性地圖并沒有絕對的格式要求，只要能夠表達清楚各個功能特性之間的邏輯包含關系即可，然后將其作為特性組合部分的指導目錄。開發人員將會很樂意將這個地圖打印出來貼在案頭，在產品開發的整個周期內頻繁使用它，無論是后端還是前端開發者都需要這么一個序列來評估開發工作的工時和進度，如果能夠將這個地圖條目編上1，2，2.1，2.2這樣的數字編號，溝通的有序性會進一步提高。

頁面要素?（Page Component）

因為現在的絕大多數企業應用都是基于Web的了，即使是移動應用，也可以被稱為頁面或者屏幕，所以我們可以用“頁面要素”來指軟件界面中的組成部分。

在特性組合部分，頁面要素是核心內容。它的性質可以用兩句話來概括：

1）用戶在頁面上能看到什么？

2）用戶在頁面上能夠做什么？

簡化的頁面要素表達可以用章節結構，把前面列出的特性地圖中的頁面詳細展開說明。例如例子中的募款管理頁面，需要包括以下內容：

現有募款項目列表，可以點擊進入募款項目詳情列出項目名稱，開始日期，負責人，累計募款額，完成比例，狀態

關鍵詞搜索募款項目

按照組合條件篩選募款項目

募款項目統計的儀表板列出當前募款項目數，累計項目數，累計募款額，本月募款額點擊任何一個數值，進入募款統計首頁

新建募款項目的按鈕

用戶使用流程?（User Flow）

對于復雜的軟件產品，僅僅依賴特性地圖和頁面要素可能還不夠。不同的用戶角色可能有多樣的任務要完成，如果只是羅列出有哪些頁面或者窗口依然不能說明清楚用戶的使用流程和期望。這時候，可以選擇加入“用戶使用流程”的專門章節，對于核心的用戶任務進行詳細說明。

用戶使用流程的表達有文本和圖形兩種方式，設計者可以根據需要選擇。文本模式的用戶使用流程用用戶任務的名稱開始，然后用1，2，3這樣順序的步驟說明用戶期望的交互路徑。

例如：

流程1: 創建募款項目

首頁點擊募款管理

點擊“創建”，進入新募款項目創建頁面

完成填寫后提交

添加募款項目成員，指定更多管理員

選擇或添加對應的財務科目

提示是否需要導入募款記錄？

Yes- 進入募款記錄導入

No - 進入下一步

7. 提示項目創建成功

當然，文本的流程說明也很容易用對應的流程圖來表達。在這樣的用戶使用流程圖中，可以約定用矩形框表達對應的頁面或者窗口名稱，這樣用戶使用流程的描述就能夠和前面的特性地圖、頁面要素中的命名對應起來。

在復雜的企業軟件中，有時候完整的用戶使用流程是非常復雜和漫長的。這時候，就需要按照一定的階段將流程切分，分板塊來表達，否則讀者將很難使用。下圖的用戶使用流程來自一個復雜的企業工作流軟件，如此復雜的表達也僅僅呈現了整個使用路徑的一個局部。

原型設計（Prototype）

我們終于進入了原型設計部分，這是構成特性組合板塊的最后一部分。對于很多產品設計人員來說，這部分是特別熟悉的。不少軟件產品設計者終日都在Adobe的設計工具上，產出的大多數是原型設計圖稿。但是，我們在進入原型設計之前，居然花費這么多筆墨在視覺之外的內容上。

為什么企業應用不能直接從視覺化的原型設計開始呢？和消費者應用相比，企業應用很難依靠單純的視覺原型來說明清楚軟件開發需求，因為交互與視覺原型很難說明清楚背后的邏輯，因為不同的數據狀態要進行的容錯處理也要比個人應用復雜得多。更重要的是，企業應用質量的核心的確在于它的可靠性和精確性。界面的美觀和易用當然是我們追求的重要目標，但它如果離開了可靠和精確后，一文不值，因為它無法幫助用戶完成任務。

雖然我們不能僅僅依賴視覺原型來說明清楚需求，但是如果有直觀的原型設計，的確能夠幫助說明過程。有了它，也能夠幫助節省PRD的文字篇幅，開發團隊可以更加精準地理解設計意圖。

在這個行業中，產品架構師、界面設計師和交互設計師都可能需要進行原型繪制。而且，就連客戶和老板都會喜歡用原型來表達或確認需求，但他們提供視覺設計的完成度是完全不同的。在分工完整的團隊中，完整的原型和交互設計最好由專業的交互設計師來主導。在產品需求的邏輯面完整以后，專業的視覺設計師可以保證交互界面的勻稱、一致和加入情感元素。

現在，因為交互設計的范式庫建設（我們在后面的章節會專門介紹設計范式），交互設計工具的發展，更多的設計成員都可以更容易地提供高保真的設計原型。高保真原型不僅能夠用像素級標準來固化需求，還能夠提供用戶操作的模擬反饋，甚至包括動效。但是，對絕大多數的企業應用來說，高保真原型的主要價值并非去提供一個嚴絲密縫的需求規范，而是給客戶方提供一個可以預見和感知的效果。過于強調高保真的實現會限制開發者靈活運用解決方案，做出合理取舍的可能。從團隊協作產出最大化的角度而言，框線圖和高保真圖都是可以接受的原型繪制方案。

有些團隊還發展出把用戶使用流程和原型圖結合在一起的模式。通過原型中的UI元素之間的連接線或者索引編號，把用戶使用產品的流程直接疊加在原型圖上。只要團隊能夠溝通和磨合好，也不失為一種提高協作成效的方式。如下圖就是一個完成度比較高的視覺和文字結合的原型圖。

從特性地圖、界面要素、用戶使用流程到最終的原型圖，包括它們之間的組合使用方式都是為了清晰完整地表達一個軟件實現的具體需求。一個企業應用到底要用怎樣的表達方式組合則完全取決于項目內在的需要。一般而言，復雜和高風險的產品會要求更加完整的表達，產品和開發協作困難（比如是兩個企業之間）的也會要求高完成度的需求描述。反之，如果是比較小型的產品，非敏感和關鍵的系統，協作配合度很高的團隊則可以有選擇地使用這些表達工具，不必面面俱到。

但不管產品文檔有多完整，產品設計者永遠需要和開發者與客戶之間建立高頻度的面對面溝通。需求溝通得越完整，越準確，產品實現的質量就越高，這一點是毋庸置疑的。

接下來PRD還有兩個可選的模塊，可以幫助進一步說明應用開發需求，它們都是為了更清楚地說明我們要把產品做得有多好。

6）競爭標桿

顧名思義，競爭標桿部分需要列出應用所對標的產品，指明它們可參照的產品特性和實現標準。對于產品型公司來說，這一點至關重要，因為我們不僅希望設計一款需求明確的產品，還希望設計能夠超越競爭對手的產品。

當然，每個企業都有自己的獨特優勢，所以競爭標桿也不是列出一堆競爭對手的產品名字，而是要指出每個特性所對標的產品。比如在“用戶管理”方面超越或達到A，在“活動管理”方面超越或達到B。競爭標桿的樹立也可以幫助我們在需求說明當中減少篇幅，因為有的時候，競品的存在事實上提供了可參照的原型。

但是，在每個特性上都建立一個標桿在商業上未必合理。任何一個軟件產品，首先都還是要有自己的獨特性，在某些優勢特性上出類拔萃。而對一般特性、支持性模塊或者難以差異化的部分，通過其他優秀產品的定標是完全應該的。尤其是企業應用產品如果能夠選擇好某個消費者應用產品的優異體驗作為標桿，對于提高用戶交互體驗度是很有幫助的。

7）發布標準和時間要求

在實踐中，設計階段很有可能對應用產品的最小交付標準還無法確定。同時，為了方便開發人員規劃完整的架構，需求說明可能會包含需要漸進實現的特性列表。所以，在PRD的最后或者使用獨立的文檔來規范應用發布時的最小化要求。如果規劃多個版本連續發布，也可以配套上對應的時間要求。

經常有團隊對一個產品的最小化交付標準爭執不下。有時候是需求方認為最小化標準過于簡單，需要增加功能特性，有時候是設計方認為我們不應該在第一個版本塞進這么多功能。這種爭執可能是企業應用設計過程中最廣泛存在的團隊分歧。

這些爭執似乎很難有一個客觀的標準，但是出現這些爭執的主要原因來自于團隊對本章開頭部分所要求明晰的產品目標未能達成足夠的共識。我們可以再回顧一下。在動手寫作PRD之前，團隊需要厘清：

1）明確了產品設計的目標是為了解決哪些用戶的哪些問題，它對企業的商業目的實現起到了什么作用？（要做什么）

2）開發項目的投入資源怎樣？可以有多少產品研發人員？給出了多長的時間窗口？（能有多少資源）

3）我們要交付的最小化產品要達到什么標準？是否有對標的競爭對手或者其他產品可以幫助衡量？（要做到怎么樣）

理想的工作方式要求我們在項目定義的時候就盡力達成一致，而不是在開發的晚期再去爭執這些問題。項目未展開之前，團隊成員和管理層尚能保持清醒的頭腦來溝通和決策這些目標和交付標準。一旦項目展開，需求開始被成更加具體的表達，就會有增加和變更需求的沖動。公說公有理，婆說婆有理的事情就多了。這就是為什么我們要早起確定和文檔化以上三點的原因。控制項目邊界的任務在很多情況下是落在產品設計人員身上的。

任何的交付標準都和配套的資源相關，對于軟件開發來說，資源就是指人力和時間。所以，設計人員需要對開發團隊的人力分布和資源情況有清晰的認知才能控制一個項目的邊界。

也有人認為軟件產品就是應該敏捷迭代，不要拘泥于項目定義。這個觀點混淆了新產品研發項目和產品長期改進的差別。對于任何一個企業，一個IT系統能否投入銷售或使用，直接影響到它對業務產出的影響，需要配合的營銷和銷售投入，運營系統的建立等協同事務，它初次交付的標準和時間要求是沒有太多寬容度的。但是，應用上線以后，基于初始版本和事實的使用反饋，不斷迭代改進則是完全另外一個邏輯，所謂的SCRUM敏捷開發模式主要指的是后者，而不是一個新軟件產品的初始打造過程。

3.4 有關產品需求設定的檢查清單

我們花了不少篇幅來專門講“需求”，它是制約一個企業應用開發和交付質量的源頭。大多數失敗的軟件開發都可以溯源到需求分析和表達階段的重要瑕疵。因此，作為本章的小結，我提供了一個9點的檢查清單，幫助設計者在最終評定需求階段工作質量的一個工具。

明確的目標服務的受眾是誰？

明確了要解決他們的哪些問題？

明確了應用給用戶企業的成本和收益帶來的影響？

明確了可以投入在應用開發上的人手？

明確了初次版本要交付的時間？

提供了導航性質的特性地圖？

提供了關鍵用戶流程的描述？

特性地圖上的每個特性提供了頁面列表、元素列表和視覺原型，并方便開發者找到？

項目資源滿足最小化的發布標準和時間要求？