產品經理如何跟設計師、工程師說明產品開發需求？或是跟產品團隊的其他人說明你要開發什麼功能？一定都會用到 PRD 產品需求文件，本篇將從文件架構、文件內容來分享我在工作常使用的 PRD 範本框架。
誰適合看這篇文章？
✔ 對於產品經理、產品企劃、產品專員求職有興趣的朋友
✔ 好奇 PRD（Product Requirement Document）產品需求文件、產品開發文件怎麼寫的朋友一、為什麼需要寫 PRD 文件？
PM 提出一個功能規劃時，通常會包含 3 個重點，分別是視覺畫面（UI 設計）、用戶體驗（UX 流程）、功能應用（工程串接）：
- 視覺畫面：e.g. 按鈕要放在哪裡？有哪些頁面要放？
- 用戶體驗：e.g. 點了會有什麼反應？click、hover 會有哪些狀態？
- 功能應用：e.g. 按鈕用途是什麼？使用者點了會跳轉去哪裡？
為了避免上述內容都是私訊、或分散在各群組，多數產品團隊都會用 PRD 文件，將開發需求完整的說明清楚，優化開發流程。
每個團隊的文件架構都不太一樣，我習慣將上述的 3 點內容都先想一遍，並提供初版說明在文件內，避免設計師畫完頁面跟我想像落差太大，導致要不斷修改。
但也聽過有些公司的 PM 只要提產品框架，後續的 UI、UX 都有專門的 UIUX 設計師來執行。
二、PRD 文件的框架
以我經歷的產品團隊，目前我整理出比較常見的 3 段框架分別是：
- 需求簡介：位置、類型、影響裝置、時程、協作人員
- 需求起源：需求來源、需求目的、效益
- 需求內容：相關檔案連結、需求畫面或預期功能
（一）需求簡介
PRD 文件最怕寫的不清不楚，寫完後若工程師開發到一半有疑問找不到人問，或是不確定功能要出現在哪，因此在文件的第一段我會簡述這份 PRD 文件的基本資訊，讓系統分析師、設計師、工程師可以一覽此文件，資訊像是：
- 需求名稱：OOO 位置 — OO 功能
- 需求位置：A 頁面 > B 欄位 > C 標籤
- 需求類型：B 欄位新功能
- 執行時程：2023/02/01–2023/03/01
- 影響裝置：Web、Mobile Web、APP ios、APP android
- 協作單位：工程部、設計部
- 相關檔案：Figma、Axure、Doc、Excel
- 聯繫人員：OO 部王大明，分機 #1001
💡補充說明：這些資訊也是一種保護機制，確保自己有把功能位置、套用裝置都寫清楚，避免工程師只做在 Web 上，漏掉 App 等情況。
（二）需求起源
第二段則是會簡述來源和目的，讓產品團隊相關人員都知道為什麼要做：
- 需求來源：此需求從哪裡來的？使用者、上級、或產品團隊？
- 需求目的：優化體驗？優化轉換率？
💡補充說明：設計師、工程師都是產品團隊的一份子，但有時 PM 規劃出來的功能，不一定會被所有人認同，可能有些人會覺得優先度不急、非開發必要、或功能情境很雞肋，因此「需求來源 & 需求目的」是幫助團隊內溝通的必要元素，提醒大家為什麼我們要花時間做它。
（三）需求內容
第三段就是整份文件的細節，說明功能畫面、怎麼運作等：
- 需求文件：把跟這個功能有關的文件都放上去，e.g. Figma、Axure，基本上 Wireframe、Mockup、Prototype 我會放在 Figma，然後用超連結放在 PRD 文件，避免整份文件過於龐大，且 Figma 在展示畫面仍比 Doc 文件方便許多。
- 功能畫面：通常我會放下面這幾種
- 原始畫面：還沒改動之前的畫面，避免我畫了一堆示意圖，結果設計師還要回去對照初始畫面是什麼。
- 新增畫面：預期修改後的畫面，讓設計師有初步想像，避免設計師畫出來跟 PM 想像的落差太大。
- 情境畫面：針對靜止狀態、空白狀態、錯誤狀態、局部資料狀態等各種情境的畫面，避免工程師把欄位做好，結果沒有限制輸入方式等。
💡補充說明：會把各情境畫面的列出來，一方面是讓 PM 自己可以檢查該功能的所有使用情境（極端值、防呆機制等），另一方面是避免開發完成又要一直請工程師補機制。
以「輸入框」為例，若一開始沒有把欄位要吃什麼資料、限制字元數講清楚，最後驗收時可能又要請工程師加上「只能輸入數字，不能有特殊字元」、「字元限制 2–30 個字」、「若欄位空白，點擊儲存時要在欄位旁邊顯示警示文字」等各種機制。
三、針對 PRD 的使用說明
上述 3 個框架是我目前工作常用的文件範本，而我也有看過有些 PRD 文件會再多放「版本控管 Version（版本修訂紀錄）」。
也有些 PRD 會增加「驗收方式 Criteria」、「產品指標 Metrics」，讓工程師在執行時有個參考依據。
上述都可以增加，依據不同公司的習慣通常會有不同的 PRD 格式，
四、總結
這篇主要是記錄我的產品經歷，僅供參考，未來會再陸續整理我在產品工作的學習心得。
如對這系列有興趣，也可以觀看：
