寫 PRD 是為了找對問題並解決問題

本篇為 PRD到底该怎么写？更全面的文档范例来了 閱讀筆記

PRD 的功能與使用者

PRD 是產品項目由「概念化」階段進入到「圖紙化」階段的最重要的一個文檔。

PRD的主要使用對象有：研發、測試、交互設計師及其他業務人員。

《用戶體驗要素》作者在書中有一句很經典的話：「文檔不能解決問題，但定義可以」，PRD就是要定義需求。

寫 PRD 以前，先思考下面七個問題：

1. 解決什麼問題？

RTPA設計框架，是一種逆向思維假設分析，我們要使用這樣一種思考技巧：假設初始需求都是錯誤的，即問題並不存在，你需要重新發現問題。

不要需求方一提需求，就開始著手設計，多問幾個為什麼並著手調查，以瞭解真正的問題。

2. 怎麼衡量？

怎麼知道問題已經解決了？

3. 需要多少資源？

時間、人力的評估

4. 會不會太複雜？

會影響哪些層面或現有產品功能

5. 有風險嗎？

主要是相關政策，是否合法等等

6. 有創新嗎？

調查競爭對手怎麼做

7. 用戶怎麼說？

親身體驗場景與用戶需求

寫PRD的基本步驟

搭框架：先定義所有使用者角色，針對每個角色提供相應功能

定流程：把每個角色與功能串連，讓閱讀者可以瞭解產品全貌

扣細節：主要從輸入、處理、輸出三方面考慮

PRD 的內容

1. 修訂記錄：檔案更新時間、作者、修訂內容，以便追朔

2. 全局說明：名詞解釋、錯誤處理、數據規則列表

3. 項目背景：產品的現狀、方案、目標

4. 項目範圍：把功能圖列出來

5. 業務流程：使用上的功能流程吧，像是登入前後之類的

6. 功能需求：這裡佔的比例最大，主要是用 User Story 的方式描述

   完整的 User Story 包含：

   a. 描述（非必須）：功能簡介

   b. 前置條件：角色、權限，例如使用者登入前

   c. 後置條件：例如使用者登入後

   d. 界面交互：定義介面

   e. 業務流程：前後端處理

   f. 異常和分支流程：這裡做登入的錯誤處理

   g. 數據字典（非必須）：data base 的定義

7. 非功能需求：監控流量、性能等等

小結：找對問題比解決方案更重要