PM 必備的 PRD 產品需求文件怎麼寫｜EP7

誰適合看這篇文章？

✔ 對於產品經理、產品企劃、產品專員求職有興趣的朋友

✔ 好奇 PRD（Product Requirement Document）產品需求文件、產品開發文件怎麼寫的朋友

一、為什麼需要寫 PRD 文件？

1. 視覺畫面：e.g. 按鈕要放在哪裡？有哪些頁面要放？
2. 用戶體驗：e.g. 點了會有什麼反應？click、hover 會有哪些狀態？
3. 功能應用：e.g. 按鈕用途是什麼？使用者點了會跳轉去哪裡？

二、PRD 文件的框架

1. 需求簡介：位置、類型、影響裝置、時程、協作人員
2. 需求起源：需求來源、需求目的、效益
3. 需求內容：相關檔案連結、需求畫面或預期功能

（一）需求簡介

PRD 文件最怕寫的不清不楚，寫完後若工程師開發到一半有疑問找不到人問，或是不確定功能要出現在哪，因此在文件的第一段我會簡述這份 PRD 文件的基本資訊，讓系統分析師、設計師、工程師可以一覽此文件，資訊像是：

1. 需求名稱：OOO 位置 — OO 功能
2. 需求位置：A 頁面 B 欄位 C 標籤
3. 需求類型：B 欄位新功能
4. 執行時程：2023/02/01–2023/03/01
5. 影響裝置：Web、Mobile Web、APP ios、APP android
6. 協作單位：工程部、設計部
7. 相關檔案：Figma、Axure、Doc、Excel
8. 聯繫人員：OO 部王大明，分機 #1001

💡補充說明：這些資訊也是一種保護機制，確保自己有把功能位置、套用裝置都寫清楚，避免工程師只做在 Web 上，漏掉 App 等情況。

（二）需求起源

第二段則是會簡述來源和目的，讓產品團隊相關人員都知道為什麼要做：

1. 需求來源：此需求從哪裡來的？使用者、上級、或產品團隊？
2. 需求目的：優化體驗？優化轉換率？

💡補充說明：設計師、工程師都是產品團隊的一份子，但有時 PM 規劃出來的功能，不一定會被所有人認同，可能有些人會覺得優先度不急、非開發必要、或功能情境很雞肋，因此「需求來源 & 需求目的」是幫助團隊內溝通的必要元素，提醒大家為什麼我們要花時間做它。

（三）需求內容

第三段就是整份文件的細節，說明功能畫面、怎麼運作等：

1. 需求文件：把跟這個功能有關的文件都放上去，e.g. Figma、Axure，基本上 Wireframe、Mockup、Prototype 我會放在 Figma，然後用超連結放在 PRD 文件，避免整份文件過於龐大，且 Figma 在展示畫面仍比 Doc 文件方便許多。
2. 功能畫面：通常我會放下面這幾種

• 原始畫面：還沒改動之前的畫面，避免我畫了一堆示意圖，結果設計師還要回去對照初始畫面是什麼。
• 新增畫面：預期修改後的畫面，讓設計師有初步想像，避免設計師畫出來跟 PM 想像的落差太大。
• 情境畫面：針對靜止狀態、空白狀態、錯誤狀態、局部資料狀態等各種情境的畫面，避免工程師把欄位做好，結果沒有限制輸入方式等。

💡補充說明：會把各情境畫面的列出來，一方面是讓 PM 自己可以檢查該功能的所有使用情境（極端值、防呆機制等），另一方面是避免開發完成又要一直請工程師補機制。

以「輸入框」為例，若一開始沒有把欄位要吃什麼資料、限制字元數講清楚，最後驗收時可能又要請工程師加上「只能輸入數字，不能有特殊字元」、「字元限制 2–30 個字」、「若欄位空白，點擊儲存時要在欄位旁邊顯示警示文字」等各種機制。

---

三、針對 PRD 的使用說明

四、總結

• 如何應徵產品企劃？面試心得及常見問題是？｜EP6
• 初期產品需求盤點時，我踩過的 3 個失誤｜EP5
• 產品開發的黃金圈理論 Why-How-What｜EP4