編輯導語：寫PRD需求的時候，總會遇到各種坑。怎樣才能避免或者少踩一些坑？筆者從用戶的角度分享了一些精彩的問題和解決方法，希望對你有所幫助。

一、背景講述

接到公司任務，做了《避坑36計》分享PRD寫作思路。

避開了之前的G端需求調研和分享，讓我們公司幾百個人看看什麽是自殺自黑總結，說出各種奇葩問題和解決方案。這一次，我決定改變這種打臉方式。

畢竟公司的產品是被迫參與的，改變策略不談個人經曆。一波研發浪潮。d和設計收集起來，然後進行需求分析一起討論。這就決定了本期的主題《用戶視角的PRD撰寫》。

決定被記錄下來，一方麵是提煉總結，自我提醒；另一方麵是與同行分享避坑經驗，交流互助，碰撞出更好的解決方案。更好地滿足珠三角產品用戶的需求。

注：總結來自創業型公司，可能和大廠遇到的問題不一樣。如有不同看法，歡迎交流。

二、 現有聲音收集

為了收集現有的痛點和需求，我首先詢問了設計師和研發人員；d人一個小問題：你覺得產品的PRD怎麽樣？

問題的反饋又好氣又好笑，含蓄又直接，八分玩笑透露出極大的嚴肅性，但每一條反饋都值得認真對待。真的是一群有想法，有產出，能抗傷害的同事。

個人認為，PRD沒有必要實現所有的交互跳轉。從整個流程來看，在需求不明確的場景下，B端/G端產品的變更風險更大。交互不難實現，但是維護成本太高，有被遺漏的可能。

實際上，拆除R & ampd槽是現有的表達方式不清晰，不能很好的呈現頁麵的跳轉關係，造成團隊溝通困難。他認為交互隻是他作為用戶提出的解決方案。

所有的訴求可以歸納為兩點：

所以，我詢問了其他產品：你寫PRD擔心過什麽？.

還有一些我剛換產品時擔心的問題。看到這裏的讀者，不知道有沒有出現過類似的擔憂？

三、PRD的用戶視角分析

使用基本分析工具5W1H拆解下PRD的用戶需求。

1. what：PRD是什麽？

首先在定位上，PRD是產品經理的溝通工具。涉及最多的兩個表達是單詞Axure和Axure。兩者各有利弊。事實上，它們並不局限於一種形式。可以根據使用場景選擇合適的表現形式。

2. why：為什麽要寫PRD？

這裏引用其他地方的定義來解釋。

產品原型的目的是清晰地表達產品設計概念、功能交互和執行邏輯，提高產品、研發和生產之間的溝通效率。d、UI和業務部門，避免信息不對稱和信任。

具個人經驗，歸納為兩點：

說人話就是：減少扯皮，避免返工；能懶則懶，減少加班。

3. when：PRD在什麽階段寫？

理論上，PRD作為產品需求文檔，是繼BRD、MRD後，從產品規劃到產品設計的階段性產出物。在中小型公司中，常缺失在規劃階段的商業論證和市場驗證，需求來自領導對市場的敏感度，來決策做或不做，缺失的商業需求文檔、市場需求分析。

後果是，在PRD梳理過程中，影響決策。導致後期部分功能需求搖擺不定，因為缺少此類信息輸入，細化PRD後，才發現底層邏輯需求錯誤，導致大範圍返工。

而在實踐中，經常為了更快產出，會變成PRD通關全過程，缺少BRD、MRD的階段和產出。

BRD：Business Requirement Document，產品向上溝通立項的工具。

內容：說明產品賣給誰、成本和收入情況、為什麽能贏利等關鍵問題。闡述為什麽立項，為公司提供信息，從而決策該產品是否有投入資源的價值。

MRD：Market Requirement Document

定義：向上溝通要做什麽、怎麽做的工具。

內容：說明所處行業的市場情況、目標用戶、競品情況、自身策略等信息。闡述內外環境影響，向公司說明產品在市場中的定位和策略，核心是為該產品在同公司的眾多產品線中，爭取更多的研發、運營和市場資源傾斜。

where：PRD在哪兒寫？

此處可劃分為兩大階段，四個類型。兩大階段為需求評審、交互評審；四個類型為項目的大版本需求設計、項目的小迭代需求、新產品從0-1孵化、新產品迭代需求。在不同環節，的內容會有所不同。

4. who：分辨PRD用戶是誰

在B端、G端產品中，PRD的用戶在產品工作中的上下遊環節，可分為公司外部相關方、內部成員。

1）內部成員：內部用戶和C端基本一樣。

a）需求評審階段：主要麵向領導、研發負責人、產品負責人、項目經理。希望獲取的信息如下：

• 需求價值
• 目標
• 用戶故事（為誰在什麽場景下解決什麽問題）
• 方案可行性
• 成本（功能清單）
• 需求優先級
• 競爭力情況
• 產品架構（和其他模塊的關係）

b）交互評審階段：主要麵向前端、後端、設計、測試、項目經理、協同產品。希望獲取的信息如下：

• 需求價值
• 目標
• 用戶故事（為誰在什麽場景下解決什麽問題）
• 方案可行性
• 需求優先級
• 產品架構（和其他模塊的關係）
• 頁麵交互
• 性能要求

作為PRD文檔，交互評審階段為核心業務場景。詳細拆解該階段各類用戶的核心點，如下：

後端：數據從哪來，數據有什麽，哪些需要存，如何建表存，這些數據是否需要支持增、刪、改、查等功能，需要為產品提供哪些接口，評估方案可實施性。

前端：後端接口如何與前端界麵結合，調取後端哪個接口，並用怎樣的方式為後端收集入參，在收集入參時前端是否要做額外的限製，以及後端返回的出參如何轉化為前端的提示等，評估方案可實施性。

設計師：信息布局和交互的合理性、用戶體驗、產品的界麵調性。作為產品下遊，他們往往是最PRD中原型內容的人。

測試：產品的user story，因為QA需要模擬不同的使用場景設計測試case，大部分情況下QA會用Xmind等腦圖設計工具來設計、覆蓋可能出現的case，並進行遍曆測試。

協同產品：產品中有哪些通用概念，本次迭代與之前版本的功能迭代的關係，需求的緊急性和重要性。

2）外部相關方與C端不同在於，B端和G端的外部相關方，對產品有絕對性影響。可劃分為高、中、基層甲方領導。

• 甲方高層：很多不看，他們喜歡看PPT和上線係統，部分喜好摳“字眼”。
• 甲方中層：注重業務邏輯（解決了什麽問題）、功能價值（可達到的效果）、用戶場景（為誰在什麽場景下解決什麽問題）、使用體驗，部分喜好摳字段、交互和視覺呈現。
• 甲方基層：注重功能使用場景（功能是否滿足業務需求）、使用體驗、字段。

四、how：PRD的內容要素

PRD涉及的信息要素有版本記錄、需求分析、需求設計、全局說明、原型設計四大內容。在不同階段場景下，涉及的內容略有差別，具體內容如下圖。

此處進行總結羅列，不做內容拆解，等有時間精力梳理時，再進行總結分享。

五、PRD撰寫的避坑總結

1. 避坑一：無版本記錄、修訂記錄

版本記錄、修訂記錄不可少。在PRD裏直接記錄，每次修改時順手完成，成本遠遠小於事後追溯。

版本記錄：用於方便對應不同版本。內容包含係統名稱、文檔版本號、係統版本號、創建時間、產品經理、UI設計師、前端、後台人員信息。

修訂記錄：易於回溯和總結變更原因，保障下次的輸出。內容包含修訂日期、文檔版本、所在頁麵、變更內容、修訂情況、修訂人員。

在這過程中，不但要補充內容，也要思考需要修改的原因是什麽。是需求挖掘沒有到位？沒有找到關鍵的業務幹係人？業務流程存在疏漏？還是外部商務因素幹擾引發的需求反複？

要綜合衡量每次修改的成本差異、實現效果。思考修改變動是否能解決用戶核心問題，此次修改是不是項目中最需要堅持的核心功能流程，要注意把撕逼的機會留給守護核心功能流程上。

2. 避坑二：需求背景描述不全麵

需求背景需全麵，盡量還原業務場景。需求收集-分析的過程，是產品設計的輸入，讓產品經理能摸清問題的本源。溝通要在信息對等的前提下進行，需求場景表達越合理，越能讓團隊覺得自己所做事情是有價值的。

如果被質疑時，你隻能說出“老板/領導要這麽做”的話，說明你在需求調研和需求分析階段偷了懶，沒有負起責任，這也容易因為對需求理解不到位造成返工。

做功能隻是手段、不是目的。不要隻做傳話者，變成了自己討厭的人。

常見的需求來源有：

3. 避坑三：需求評審階段，未梳理係統依賴

B/G端係統，常依賴於其他係統數據，在需求評審階段，就需梳理清楚所有所需數據來源、係統依賴。

一方麵，是進行初步的可行性評估，明確所需條件是否具備；另一方麵，可提前協調相關資源，預留字段和接口。若交互設計階段，才進行相關梳理和確認，易造成決策返工，可能會發現前置條件並不滿足。

4. 避坑四：數據層分析缺失

交互評審中，數據分析梳理不可缺。B/G端係統設計中，數據是核心。其中數據清單列表、實體關係圖是每次需求都需梳理和更新的必要信息，數據流程圖可根據需求的複雜程度決定是否分析。

5. 避坑五：信息不清晰 布局不簡潔

信息結構盡量清晰，布局盡量簡潔。無論頁麵設計，還是PRD的排版布局，都要注意信息設計的合理性。並且內容越清晰，越能降低評審人員的理解門檻，提前討論疑問點，讓評審效率更高。形式的建議如下：

1) 圖文結構化布局

頁麵元素與注釋對應清晰，最好在元素邊上就是注釋。

2) 文字排版簡潔

描述簡潔精煉。避免大段文字，多分行。

信息要放得下。放不下又全要，就換個交互形式。

考慮信息主次。考慮信息的次序感，通過字體類型（粗細）和字號區分出信息層級和描述重點。

3) 色彩簡潔

避免豐富的顏色。用黑白灰 主題色 強調色。

6. 避坑六：忽略細節定義

注意細節定義。以下幾點，都是較為重要且易被忽略的。

• 定義數據
• 定義地圖交互
• 定義異常狀態反饋
• 定義排序規則
• 定義狀態機

最後，其實還需結果導向，不要拘泥於形式表達，最終是希望能和上下遊高效協同。

六、總結

本文到此結束，希望對大家有所幫助呢。