關于產品需求文檔的幾個要點，希望對你的產品方案有幫助。

「 起 」

產品需求文檔（以下簡稱 PRD）作為產品設計過程的交付物，在一個需求的產生到實現過程中扮演著非常重要的角色。往往初級產品設計師的核心工作之一就是進行功能設計并產出靠譜的PRD。從實際的產出結果來看，一般產品設計師（以下簡稱PM）能夠很好地完成功能的主流程設計，但是總會在一些容易忽略但是又十分重要的細節上Miss掉，導致在技術評審或開發過程中被challenge比較多。

那么如果在做功能設計的過程中可以帶上一張半開卷考試用的Cheating Sheet，這張A4大小的紙上應該提供哪些信息才可以幫助到PM完成一份高質量的PRD呢？以下是我個人的一點總結，主要面向初級產品設計師。

「 邊界問題之空值、極大值、極小值 」

第一類問題我把它叫做邊界問題，顧名思義就是很多極端情況是否有仔細考慮過。最明顯的就是空值、極大值和極小值。一般空值是指某個字段或區域一般是有內容展示，但是針對新用戶或部分極端情況，該字段或區域為空，這個時候需要做一些小的設計方案。一般空態的設計是需要告知用戶當前該區域為空，同時引導用戶去做和這個場景相關的操作。比如購物車為空時，告知用戶購物車為空，同時下方推薦一些商品可以讓用戶加入購物車。

圖1 ?天貓購物車在“空值”下的效果

而極大和極小值經常在價格、標題等元素上需要考慮，比如價格最大支持幾位數，最小是1分錢還是免費。標題則經常會聽到“一行截斷”或“兩行截斷”的說法，意思就是為標題最大提供幾行展示，每行需要估算展現多少字符。一般來說，標題的最大展示字符盡量要小于標題設置時對標題的長度要求，這樣就不會有截斷的問題。而標題在展現一行或兩行時，標題下的內容是否要接上或者即使不超過一行也把第二行留出來，這些相關點的設計都是需要考量的。

「 邊界問題之版本控制、端控制 」

我們知道，現在的互聯網產品往往會在不同端呈現，比如PC客戶端、PC網頁端、移動網頁端、移動客戶端，移動客戶端還分iOS和android。那么如果你所參與的產品確實有多端情況時，則在設計一個功能時是需要考慮不同端的特點做差異化設計。

比如商品詳情頁在PC網頁端上的設計，由于PC的空間比較大，因此很多內容可以平鋪出來，但是在移動客戶端由于屏幕很小，需要通過Tab切換（商品、詳情、評價等）或者引導到二級頁面（領取優惠券）的方式，把一些次重要信息相對藏起來。這里的經驗和技巧很多，需要產品設計師多熟悉、多操練不同端的設計，一定沉淀后才能做到在不同端上自由切換而版本控制則是在移動客戶端上非常重要的一個議題。當一個新的版本上線的時候，往往需要考慮四種情況。把新用戶、老用戶和新版本、老版本做交叉匹配，剛好得出四種情況。

圖2 ?版本控制示意圖

往往新用戶、新版本是最容易的，反正都是新的，自然很多東西不用考慮之前的情況。但是老用戶在新版本上，就需要考慮很多情況。

一般來說，新增一個功能對于老用戶來說也是沒問題的，因為老用戶也沒接觸過，所以可以當新用戶處理。但修改一個功能時，則需要非常謹慎地去看待老用戶的兼容問題。比如某個健身應用需要用戶選擇自己的身份，學生、白領、老人等等。

如果某個需求是在新版本上刪除某個角色時，則需要考慮這些選擇了這個身份的老用戶該怎么處理，是映射到一個新的角色上，還是讓這部分用戶再選一次，這就需要有設計和考量。同樣，針對新用戶在老版本上，一般是需要保留老版本已有功能的正常運行，如果實在不能向下兼容或者因為某個重要新增功能，希望用戶盡快到新應用上，那么需要相對強的提醒引導用戶升級，直到老版本比例足夠低的時候，才可以考慮放棄老版本的服務提供。

「 邊界問題之異常處理、狀態處理 」

異常處理一般來說，PM還是會非常重視的。比如購物車商品減到零時是否要彈窗提示用戶把商品從購物車去掉，亦或者用戶輸入的密碼不合規范，需要提醒用戶調整。這些很多異常情況，PM是需要把自己放空，通過很多非正常交互流程去模擬和梳理的。比如完成一個不可逆的流程（購買流程），此時用戶想點返回了，哪一步是可以到上一步，哪一步到不了上一步，這些就是設計的細節。

而狀態處理也是PM經常會忽視的一個問題，比如一個商品在上架前、上架后、限時優惠、庫存充足、庫存緊張、售空等不同狀態下，該如何設計。又比如一門直播課，用戶有游客、登錄兩種狀態，對于課程有報名和非報名兩種情況，對于課程本身還有上課前、上課時和上課后三種狀態，那么這三類狀態的交叉組合就會出現很多情況需要去分析和設計。因此，這里的學問也是很大的，值得好好研究。

「 遺漏問題之數據統計 」

第二類問題我把它叫遺漏問題，最容易被忽視的是數據統計。數據統計的目標和需求滿足的方向是一致的，這個功能解決了什么問題，那么通過數據怎么證明PM提供的方案可以解決。

關于數據統計需要提取的指標及對比實驗，這里可以單寫一篇了，所以在此不做贅述。但比較核心的是幾個原則：

一是單一變量，盡量保證實驗不受其他因素影響；

二是足夠大的基數，基數不夠大，數據的可信度不高，受隨機行為的影響會比較大，一般建議實驗組和對照組各不少于2000人的訪問；

三是既要看短目標，也要兼顧長目標，短目標是指和這個實驗直接相關的指標，長目標是我們考量用戶健康度的核心指標。比如在教育領域，通過優化課程詳情頁去吸引用戶下單，從短目標來看是監控訂單轉化，而從長目標是去看“續費率”，單看訂單能保證當下數據OK，兼顧續費率才能保證未來半年甚至更長時間數據能夠健康合理增長。

「 遺漏問題之相關消息機制 」

初級PM很容易忘記自己有這項武器，這項武器要慎重使用，但用好了會省下不少麻煩，這就是消息機制。我把這里的消息定義為泛消息類型，包括引導圖、Push、短信、郵件等形式。那么怎么理解和使用不同類型的消息去幫助自己呢？

最常見的場景就是 “這個功能很重要，用戶不一定能注意到，做個引導圖，當用戶到達功能所在的入口或承載時提醒用戶訪問”，這就是我們在新版改版中經常使用的“武器”，擔心部分重要功能位置發生調整，需要針對老用戶進行提醒。這里，如果再結合版本控制，只針對升級用戶提示，新用戶則由于本身第一次接觸，不需要了解功能位置發生變化這件事。

除此之外，在一些重要節點觸發的時候，Push、短信和郵件也是我們常用的手段，比如信用卡的對賬單通過郵件發出來，直播課的到課提醒通過短信發出來，發布了某個帖子被人回復通過Push觸發?？梢钥吹?，不同的場景會選擇不同的形式。

圖3 ?京東訂單確認郵件

一般來說，信息較多的情況且正式的場合用郵件，比如對賬單、服務開通、活動通知等。而短信由于成本因素，適合信息較少且特別重要的場合，短信的到達效果在這三者中還是相對比較好的。而Push由于是零成本，適合信息較少且比較重要的場合，一般Push分為觸發式和運營式兩種，觸發式以和用戶密切相關的行為為準，可以相對忽略條數的限制，比如你發的微博被人評論了，你和某人聊天對方回復了等等。而運營式指的是運營推送給用戶的內容，這里更多是通過運營去理解用戶，推送他們感興趣的內容，但我們知道這樣的推送很多時候對于用戶來說可能是騷擾，他們并不覺得這個有用，因此這一類push是需要控制頻次和數量的。

「 基礎思維之高內聚、低耦合 」

高內聚、低耦合是軟件工程中非常經典的思想。主要是說在每個模塊的開發時，盡量獨立完成自己范圍內的功能，不依賴于模塊外部代碼，同時盡量減少模塊之間的聯系，避免牽一而動全身的情況出現。這樣的好處是使得模塊的可重用性、移植性大大提升。

那么為什么產品設計也需要遵從這樣的思想。產品是用戶和技術之間的橋梁，承前啟后，用戶在對復雜事物的認知過程一定是先拆解再研究，而技術實現也是，從兩頭來看都需要把復雜事物進行有邏輯的拆解后再去認知（實現），那么自然產品設計也需要遵從這樣的思想。

如何來運用這一思想呢？最簡單的例子比如一個電商應用最核心的頁面是商品詳情頁，這一塊是可以單獨拆出來設計，保證獨立性，不論從哪里都落地到這里；又或者購物車模塊不用太在意是誰的購物車，里面裝了什么商品，只需要梳理出一個獨立的購物車功能，那么自然它也能被復用到其他電商應用里。這樣就做到了購物車本身的模塊盡量“內聚”，然后購物車和商品詳情頁模塊之間“低耦合”。

「 基礎思維之場景思維 」

場景思維這個詞其實我比較希望能避免去使用，這個詞太政治正確了，也比較抽象，不適合用作功能設計的具體指導。但是又不得不用，因為這個詞里包含了很多圍繞這個中心思想的設計指導。

舉個例子，我們一般“把玩”一個應用時，最直接看到的就是底部的Tab導航，這里的每個Tab一般來說就是這個產品的一個場景，四到五個場景構建出了這個產品的主要功能和核心價值。那么結合“高內聚、低耦合”的思路，一個場景內的功能要盡量放在一起，比如淘寶的首頁是用戶找商品的一個定位，那么搜索、分類入口、主題商品、運營活動等等必不可少，且盡量在這個Tab下最大平衡地去排布功能。

當然，我們也能舉出反例，比如大眾點評會把你正在排隊的商家信息直接橫插到首頁，百度外賣也會把你正在進行的外賣訂單放置首頁，跟誰學會把用戶報了名且正在直播的課程在首頁上提供快捷入口。這其實也是一種場景思維，思維的角度是當用戶和應用正在發生強連接時，需要提供最方便的入口，因為這個時候，用戶不再那么需要看其他的商家、外賣店和直播課，只需要關注他選定的那個，因此在一個“找內容”的首頁上插入“消費內容”的入口也就可以理解了。

圖4 大眾點評首頁展示排號信息

所以場景思維能包含的東西很多，不代表所有通過場景思維得出的設計方案都是對的，因為有時候不同場景間由于在共同頁面的作用，會導致在頁面上做取舍，這個時候就需要結合你關注的核心目標去引導用戶的行為。這個過程對于PM來說也是一種以用戶為中心的思考，去感受用戶此刻的想法，模擬用戶此刻的操作，然后設計出與之匹配的功能。

「 基礎思維之可擴展 」

可擴展性主要是為了減少未來的大面積返工需要提前考慮的。比如某個模塊經常會變動，就需要提前考慮增加字段、刪除字段、修改字段等情況，甚至會影響在頁面的實現方式上是選擇原生頁還是H5頁。又比如說健身應用需要用戶選擇自己的身份，這里需要考慮未來角色的新增、刪除和修改可能，做好提前設計。這個和之前提到的“版本控制”是相輔相成的，版本控制是站在新版本向下兼容，可擴展性是站在當下版本前瞻未來。一前一后，保證無遺漏。

「總結?」

所以，總的來說如果保持對這三大類問題的關注和設計，相信你的產品方案會更加嚴謹，減少遺漏。以上皆為經驗之談，寫的比較快，部分細節沒做完整的數據論證，因此大家兼聽就好。也是蠻久沒寫東西了，一張口的感覺就是一股濃濃的學術風，希望大家不要覺得太boring。

關鍵詞

基礎思維：高內聚、低耦合、可擴展、場景思維

邊界問題：空值、極大值、極小值、版本控制、端控制、異常處理、狀態處理
遺漏問題：數據統計、相關消息機制

作者：小雨哥（訂閱號 ?小雨哥Rain），跟誰學產品經理，目前主要負責學生端產品，在用戶產品方面有些研究。

本文由 @小雨哥 ?原創發布于人人都是產品經理。未經許可，禁止轉載。