撰寫產品需求文件 PRD 時的閱讀體驗七宗罪

我遇過的軟體業產品經理通常都會覺得撰寫 PRD 是一件很痛苦的事情，書寫的過程痛苦、用來解釋給別人聽的時候痛苦，其實就連幾個月後重新看自己寫的規格文件，也挺痛苦的。

​

仔細評估背後的狀況，其實「書寫原則」混亂，造成文件的閱讀體驗差，是最主要的元兇。

​

以下想與你分享人們閱讀 PRD 過程中常見的問題，包括了：

1. 缺乏敘事層級脈絡
2. 只見增刪查改缺乏使用者意圖
3. 混淆真人與系統角色
4. 突然發明嶄新的詞彙
5. 語意曖昧與廢話連篇
6. 混搭倒裝句與副詞子句
7. 描述機制需求時都在寫 UI 畫面

​

▋七宗罪之首：缺乏敘事層級脈絡 ▋

閱讀體驗糟糕的 PRD，第一條常見的狀況就是劈頭就進入細節，沒有告知閱讀的人這個細節從何而來。

例如第一行就寫了「開課三天前可退費。」

那麼閱讀的人就必須自己推理，有個概念叫做「開課」，然後看到了退費，那麼逆向思考一下，應該是先繳費了才能退費。

短短一行字就需要閱讀者自行推理、解壓縮兩個概念的脈絡，而這還是通俗易懂的產品服務領域，或許可以期待他人自行通靈成功。

如果這樣的描述發生在更專業的主題領域，例如「預審投單後七天內可臨時補單」，正常人都會放棄通靈，與其看文件不如開會講清楚。

書寫 PRD 的時候，需要安排一個順序進行「宣告」，讓每個抽象概念有層次的登場。

例如現在要寫關於「課程」的需求描述，那就先宣告如何建立課程、會有付費的概念，那麼才會寫到退費的業務邏輯。

​

▋七宗罪之二：只見增刪查改缺乏使用者意圖 ▋

第二種最常見的 PRD 書寫狀況，就是通篇描述都只有增刪查改，例如：

• 營運人員可以新增課程
• 營運人員可以瀏覽課程
• 營運人員可以查詢課程
• 營運人員可以編輯課程
• 營運人員可以下架課程

也不能說這有寫錯，而是如果只有這樣程度的訊息量，那幹嘛需要寫需求文件？

​

開發團隊需要明確的了解使用者意圖，才能評估開發出來的功能或流程，能不能解決問題。

​

比起「營運人員可以新增課程。」

如果寫：「營運人員為學員媒合老師，預約課程。」

​

閱讀者第一時間會理解整件事情的意義，接下來更細部描述「預約課程」時需要的相關資料時，整件事情也有了脈絡。

​

甚至更進一步，開發這個功能的人，還可以幫忙想怎麼樣的預約與媒合流程可以讓使用者更方便，或者系統的其他部分應該要開發某些輔助機制，讓媒合的判斷品質提昇。

​

▋七宗罪之三：混淆真人與系統角色 ▋

第三個常見問題，許多 PRD 文件中會混淆「真實人物」與「系統角色」這兩種認知。

​

例如說，可能 PM 在需求訪談中，聽到了「請假流程會需要老闆 John 做最後的審核」，轉頭就在 PRD 寫下「John 對請假單進行最後審核」。

​

在實際開發中，若工程師真的按照此描述完美實現，反而會是一場悲劇。

首先是，如果公司現在是 10 個人，都是同一個 John 在審核，看起來沒問題，但這個公司只會有 10 個人嗎？

John 會不會有一天請了別人當人事主管，讓別人來審核？

這個軟體產品的相關權限，難道要綁定「John」這個人嗎？

​

產品服務當然要參考實際情境，但不能完全照搬。

​

在需求訪談的過程所聽到的人事物，除了名字本身（例如 John），還要了解背後的抽象意義（例如管理者），然後在撰寫 PRD 的時候，根據情境與業務邏輯的脈絡，對這些人事物進行適當的命名。

​

命名時需維持抽象程度，不能綁定在特定具體人事物上。

命名還要能幫助觀看者容易理解，具備明確的指向性。

​

▋七宗罪之四：突然發明嶄新的詞彙 ▋

閱讀 PRD 過程另外一個可怕的困擾，就是「語言不統一」。

​

同樣一件事情，在口語描述時喜歡稱為「開直播」。

在另外一個地方叫「一對一」。

換了一個情境時又稱呼為「課程」。

​

這三個描述都指向同一件事，寫入 PRD 當中就成為災難，搞不好最後做成三套東西。

​

對於同一件事情的命名來說，「課程」比「開直播」、「一對一」還好，因為課程的抽象意義可以同時涵蓋「開直播」（上課形式）、「一對一」（參與規則）。

​

另外，動詞的使用也需要固定。

​

例如僅僅一個課程，可能就會衍生出「安排課程」、「預約課程」、「建立課程」、「新增課程」⋯⋯等等五花八門的描述。

這些不同的動詞，對於閱讀 PRD 的人來說會造成困擾。

​

因為閱讀的人會想很多細節，萬一「安排課程」跟「預約課程」需要不同的功能流程怎麼辦？

​

所以在 PRD 的撰寫中，對於同一件事情的名詞要固定，就連搭配的動詞也應該挑選合適的詞彙，從一而終，減少胡思亂想的空間。

​

▋七宗罪之五：語意曖昧與廢話連篇 ▋

有一種痛苦的 PRD 閱讀體驗，就是「聽君一席話，如聽一席話。」

我看了一大堆敘述，但我不知道我看了什麼。

​

例如：「課程預約成功後，課程就被預約。」

又或者：「符合規則的預約在預約時需要遵守規則。」

​

PRD 撰寫時，並不是寫越多文字量越好，更多的文字反而是消耗閱讀者的認知心力，造成負擔。

但寫 PRD 的人也經常備受指責，被批評沒有寫清楚。

此時產生的認知偏誤，就是「寫越多代表越仔細」（另外就是，PRD 文件常常是在加班腦袋不清楚的狀況下寫。）

​

PRD 上的每一段文字，指向要明確，例如宣告使用者意圖、定義理想結果、描述業務邏輯、補充邊緣情境等等。

比起寫下很多混亂的想法，PRD 的每一段文字應該是幫助閱讀者搞懂一些事情。

​

少即是多。

​

▋七宗罪之六：混搭倒裝句與副詞子句 ▋

還有一種不舒適的 PRD 閱讀體驗，就是每一段文字既冗長又充滿各種條件子句，要理解這樣的文字段落，閱讀者的腦袋要同時建立一個流程圖的想像。

如果要說明的東西就是這麼複雜，那為什麼不畫流程圖就好？？？

​

比起「可安排的老師，根據學員分級測驗結果挑選。」（倒裝句）

更適合的描述是「根據學員分級測驗結果，安排老師。」（直述句）

​

比起「預約課程時根據學員分級測驗提供教材，配合學員進修主題興趣與老師教學領域並以學生時段為主進行選擇。」

更適合的寫法是：

• 為學員安排老師進行線上一對一教學
• 根據學員分級測驗提供教材
• 根據學員進修主題，配對老師的教學領域
• 以學員可上課時段，媒合老師可排課班表

​

撰寫 PRD 時，建議用直述句進行說明，並將複雜的想法拆解為條列式，以一行一述為原則。

​

▋七宗罪最後一條：描述機制需求時都在寫 UI 畫面 ▋

有一種 PRD 的撰寫風格，像是在手把手教你怎麼操作軟體。

例如：

• 點擊帳號欄位，輸入 Email
• 點擊密碼欄位，輸入 8 - 16 字串長度，英數混合字元
• 按下確認
• 展開提示視窗

雖然看起來很認真有條理，但這種書寫體的問題更大。

首先是軟體的互動邏輯可能很複雜，沒辦法用這樣的列點描述方式釐清互動邏輯，還不如用流程圖來溝通。

其次是在沒有畫面的情況下描述 UI 介面，閱讀者的認知負擔也很大，要自行在腦海中想像，那還不如等你畫了 wireframe 再來討論。

​

▋結語

許多人覺得自己煞費苦心寫出精美的 PRD 沒人看，但閱讀者其實也很痛苦，因為看不懂。

文字的理解需要動用系統二的後設思考，會大量消耗認知心力，特別是像軟體需求溝通這麼困難的議題。

寫 PRD 不是在寫文學作品，重點在實用。

因此，簡單易懂、脈絡清晰、意圖明確的書寫原則，幫助閱讀者輕鬆理解，人家才看得下去。

以上都是我自己踩過的雷，分享給各位，希望能幫助釐清為什麼 PRD 沒人想看的痛苦。