張家惟 Evan Chang的沙龍

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

張家惟 Evan Chang
張家惟 Evan Chang
發佈於思維的創意想像
2023/03/05閱讀時間約 5 分鐘
產品經理如何跟設計師、工程師說明產品開發需求？或是跟產品團隊的其他人說明你要開發什麼功能？一定都會用到 PRD 文件，本篇將從文件架構、文件內容來分享我在工作常使用的 PRD 範本框架。
誰適合看這篇文章？
✔ 對於產品經理、產品企劃、產品專員求職有興趣的朋友
✔ 好奇 PRD（Product Requirement Document）產品需求文件、產品開發文件怎麼寫的朋友

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

PM 提出一個功能規劃時，通常會包含 3 個重點，分別是視覺畫面（UI 設計）、用戶體驗（UX 流程）、功能應用（工程串接）：
  1. 視覺畫面：e.g. 按鈕要放在哪裡？有哪些頁面要放？
  2. 用戶體驗：e.g. 點了會有什麼反應？click、hover 會有哪些狀態？
  3. 功能應用：e.g. 按鈕用途是什麼？使用者點了會跳轉去哪裡？
為了避免上述內容都是私訊、或分散在各群組，多數產品團隊都會用 PRD 文件，將開發需求完整的說明清楚，優化開發流程。
每個團隊的文件架構都不太一樣，我習慣將上述的 3 點內容都先想一遍，並提供初版說明在文件內，避免設計師畫完頁面跟我想像落差太大，導致要不斷修改。
但也聽過有些公司的 PM 只要提產品框架，後續的 UI、UX 都有專門的 UIUX 設計師來執行。

二、PRD 文件的框架

以我經歷的產品團隊，目前我整理出比較常見的 3 段框架分別是：
  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 的使用說明

上述 3 個框架是我目前工作常用的文件範本，而我也有看過有些 PRD 文件會再多放「版本控管 Version（版本修訂紀錄）」。
也有些 PRD 會增加「驗收方式 Criteria」、「產品指標 Metrics」，讓工程師在執行時有個參考依據。
上述都可以增加，依據不同公司的習慣通常會有不同的 PRD 格式，

四、總結

這篇主要是記錄我的產品經歷，僅供參考，未來會再陸續整理我在產品工作的學習心得。
如對這系列有興趣，也可以觀看：
為什麼會看到廣告
張家惟 Evan Chang的沙龍思維的創意想像產品開發
張家惟 Evan Chang的沙龍
67會員
131內容數
前往沙龍
《思維的創意想像》是工作之餘發起的 Side Project，因為近期快速吸收各種資訊跟商業知識（Input），但一直沒有地方輸出（Output），因此想透過這系列記錄學到的內容，包含商業知識、產業洞見，或是職場分享等等，目前已有產品開發、客戶成功、社群行銷、思維增長、職場日記等系列文章。
前往沙龍
留言0
查看全部
發表第一個留言支持創作者！