這堂課會學到什麼
恭喜你！前面幾堂課，你已經完成了一連串產品定位的腦力激盪，從市場分析、用戶需求到優先排序，像是一位雄心勃勃的建築師，畫好了設計圖。但僅有設計圖，還不足以讓建築工地的每個工人知道如何動手——這就是 PRD（產品需求文件） 登場的時刻！
PRD，就像是你的施工藍圖，清楚列出每一根鋼筋應該放在哪裡、牆體應該多厚、窗戶應該朝哪個方向開。這是一份不僅讓 PM 能對整體規劃瞭若指掌，也能讓設計、開發、測試、甚至市場行銷團隊都清楚接下來該如何落地執行的文件。
這堂課
- 我們就來聊聊如何打造一份周延專業的 PRD（產品需求文件）！讓你的產品概念能清楚傳達給開發團隊，從 概念設計 成功邁向 交付
- 探討 PRD 裡面包含的 UX 工作產出，從 資訊架構 (Information Architecture)、流程圖 (Flow Chart) 等到 精描圖 (UI Mockup)、原型(Prototype) 等設計產物文件，讓開發出來的東西與原本規劃設計的東西沒有落差 !
BRD、MRD、PRD 三種規格書的差別
在產品開發的世界裡，BRD、MRD 和 PRD 是三種經常提及的規格書，分別負責不同的層面和角度，構成了從需求探索到產品落地的完整鏈條。
若無法清楚看到圖片文字，請點擊下方連結預覽 or 下載查看清晰版本 :
1. BRD (Business Requirement Document) 是從商業角度出發的文件，負責回答「我們為什麼要做這個產品？」的問題。它聚焦於業務目標、商業價值以及市場機會，主要由業務部門或高層制定，用於說服利害關係人。
2. MRD (Market Requirement Document) 則站在市場角度，負責回答「市場需要什麼樣的產品？」的問題。它深入分析市場趨勢、競爭對手與目標用戶需求，通常由產品市場經理撰寫，為產品的市場定位提供依據。
3. PRD (Product Requirement Document) 是我們本文的主角，負責回答「我們應該如何打造這個產品？」的問題。PRD 不僅匯總了 BRD 和 MRD 的精華，還轉化為具體的功能需求、架構設計和用戶體驗細節。它是連接產品設計、開發和測試團隊的橋樑，由產品經理主導撰寫，確保產品開發的每個環節與最初的商業目標和用戶需求保持一致。
換句話說，BRD 是做產品的理由，MRD 是做什麼樣的產品，PRD 則是如何做出來。今天，我們就聚焦於 PRD，探索如何以精準清晰的規格書，讓產品開發更順暢、更高效，並最終交付符合期待的成果！
PRD 產品文件架構說明
一份完整的產品需求文件（PRD）應該清晰地描述產品目標、需求和設計細節，並包含以下幾個主要架構，確保跨部門溝通順暢：
若無法清楚看到圖片文字，請點擊下方連結預覽 or 下載查看清晰版本 :
一、文件基礎資訊
- 日期、檔案版本、修改人：清晰記錄文件的歷史變更與負責人。
- 改版內容：概述此次修訂的主要變更，便於追蹤更新。
- 如果這邊使用專案管理系統如 Gitlab、Jira 等，可以直接省去此麻煩，系統自動就會紀錄。
二、產品、專案概述
- 產品願景與設計目標：闡明產品、專案核心目標與所要解決的問題，以及達成的效益（例如：解決什麼重大痛點，節省多少工時等資訊）。
- 特色與使用情境：簡述產品的主要功能及目標用戶如何使用產品。
- 目標族群與 Persona：描述用戶特徵、關鍵需求，為後續設計和開發提供方向。
三、使用者需求與功能需求
- 使用者及其需求：背景資料與用戶痛點的來源分析。
- 功能需求與價值說明：每項功能的核心目標與對用戶的價值。
- 功能需求列表：詳細列出功能的實現方式與優先級，幫助團隊聚焦。
四、產品設計
- 靈活設計，按需求展現：根據項目需求選擇性地放入資訊，純屬後端機制的項目可以省略 Wireframe 、UI Mockup 有介面呈現等項目，若有最後接近更完成品的 UI Mock-up，就也不用放 Wireframe 等彈性變通，總之，就是放開發團隊此階段需要看到的設計！
- 例如：
- 功能架構與互動流程圖： Information Architecture、Functional Map、Flow Chart 等。
- 介面原型與頁面邏輯： Wireframe、Wireflows、UI Mockup、UI Flows 色彩系統與設計系統等。
這些項目為建議放入的內容，但文件細緻程度需與開發團隊討論，建立共識，並考量團隊規模與迭代速度。
Note 注意：如果是系統邏輯通則或是共用設計規範，可能會獨立於個別功能的 PRD 產品規格書，而是類似工程單位會抽成共用元件、做出一個 interface 的概念，產品經理也需要將通則類型的規格，放在上層的 PRD 產品規格書。如下面有功能會使用到通則，就可以用 Reference 的方式來引用。
五、技術與非功能需求
- 系統與技術架構：
包括系統運作方塊圖、資料流程設計、資料庫規劃等技術細節，用於協助開發團隊理解系統架構與運作方式。這部分通常由 Technical PM（技術型 PM） 或是 SA 系統架構師規劃與撰寫，若非技術型 PM 則可選擇省略，並將需求與技術細節交由技術開發團隊處理。
- 非功能需求：
涵蓋系統性要求，如效能（Performance）、穩定性（Stability）、可擴展性（Scalability）等，確保產品在運行中的技術品質與體驗達標。
六、風險與應對措施
- 潛在風險： 預判產品可能面臨的風險類型，如法規合規性、金融風險、資訊安全、或技術實作挑戰等。
- 應對之道： 制定風險管理計畫與應急方案，確保即使風險發生，也能迅速應對並將影響降至最低。
此部分屬於 Nice to Have，並非所有項目都需詳寫。有時風險與對策的記錄會被納入專案管理工具的相關區塊，而非產品規格文件內。如果時間或專案特性不允許，這部分可根據需求靈活處理。
七、驗收標準
- 功能驗收與成功標準：驗收標準應明確具體，例如功能是否符合需求描述、是否達到性能指標或用戶體驗標準。
- 功能測試：檢查所有核心功能是否按照需求文檔執行。
- 用戶反饋：測試功能是否滿足用戶需求，達到預期價值。
- 技術指標：如響應時間、穩定性等是否符合規範。
定義清晰的驗收標準，確保每個功能在開發完成後都能獲得一致的評估，並與團隊討論形成共識。
PRD 文件管理與敏捷開發小技巧
1️⃣ 需求拆解與協作管理
Epic 拆 User Story，聚焦 User Story 個別需求，有需要回顧 Epic 時善用 Reference 不讓內容重覆
例如：Epic 大的任務「購物車功能」拆成個別小任務 User Story「加入購物車」、「檢視購物車」、「結帳」這三個。個別小任務 User Story 如果需要回顧 Epic 的使用者需求與功能需求，可以附上 Epic 的 Reference 連結內容即可，不用重複寫。
- 推薦工具：Jira、GitLab
- 小撇步：用 Reference 連結 Epic，標籤標示開發團隊，讓協作更順暢！
2️⃣ 文件管理與版控同步
版本不同步，專案就可能變「災難片」。
- 建議工具：KM 知識管理工具、GitLab
- 重點：確保所有成員隨時掌握最新文件！
3️⃣ 變動記錄與透明溝通
需求變更很常見，但記錄沒跟上就 GG。
- 方法：用專案工具的 Comment 記錄變動細節，確保資訊不流失。
- 優勢：完整溝通紀錄 = 降低資訊錯誤風險。
4️⃣ 文件內容的靈活性
PRD 文件沒必要「一視同仁」，依專案需求調整內容。
- 例如：純後端機制的專案因為沒有前台介面可省略 UI Mockup。
- 關鍵：團隊默契是靈活文件的核心！
5️⃣ 團隊一致性與工具應用
文件規範要統一，管理工具用對，效率更高！
- 推薦工具：Jira、GitLab
- 重點：標準化格式減少跨部門協作摩擦。
6️⃣ 確保文件與系統功能一致
PRD 不能只是「紙上談兵」，要與實際系統同步！
- 核對方式：定期確認文件 vs. 產品功能，避免落差。或是規範上線前，最新版文件規格也要跟著 Commit !
- 更新文件：功能變更，PRD 也要跟著修正，並記錄影響範圍。
- 好處：確保產品交付品質，團隊更信任彼此！
🚀 小結：PRD 不是寫完就丟一邊，拆解需求、同步版本、記錄變動、靈活應用，才能讓專案跑得又快又穩！
小結
一份完整的產品需求文件（PRD）是產品開發過程中的關鍵指南，能有效促進跨部門協作、確保需求一致與開發效率。在實際執行中，應靈活調整文件的深度與範圍，根據專案特性與團隊需求進行適配，確保資訊透明、管理高效，並通過版本控制工具實現文件的同步更新。此外，定期對比 PRD 與實際系統功能，持續優化與保持一致，能避免溝通誤解與落差，提升產品交付品質。
通過清晰的架構、靈活的內容設計和良好的團隊協作，PRD 能成為產品開發成功的堅實基石，為後續的執行與驗收奠定紮實的基礎。
UX 工作產出
在 第五堂課 : 雙鑽石設計思考和 UX 使用者體驗設計思維與研究工具 章節中，就已經有看過下面這張產品設計規劃大表，此段落會專注於黃色區塊 (下圖) 的內容，深入解析每個 UX 工作產出的介紹。
若無法清楚看到圖片文字，請點擊下方連結預覽 or 下載查看清晰版本 :
由於內容較多，提供超連結列表，大家可以依序參閱 UX 產出介紹和實際上要怎麼操作使用 :
- 第七堂課補充學習 UX 工作產出 : 1. IA 資訊架構 & 2. Functional Map 功能地圖
- 第七堂課補充學習 UX 工作產出 : 3. Flow Chart 流程圖
- 第七堂課補充學習 UX 工作產出 : 4. Wireframe 線框圖 & 5. Wireflow 線框流
- 第七堂課補充學習 UX 工作產出 : 6. UI Mockup 精描圖 & 7.UI Flow 使用者介面流
- 第七堂課補充學習 UX 工作產出 : 8. Prototype 原型
番外篇 : Figma & FigJam，數位產品經理的必備協作工具
作為數位產品經理（PM），我們經常需要 快速視覺化想法、提升跨部門溝通效率，甚至確保設計與開發的無縫銜接，尤其上面內容提到的 UX 產出，就可以透過 Figma 和 FigJam 達到團隊高效協作工具，讓 PM 在 UX 流程中事半功倍！之後我也會另開文章系列來講講 PM 怎麼使用這兩個工具！
🛠 FigJam：電子白板，快速整理思路 & 流程圖
FigJam 是 Figma 旗下的 線上電子白板，特別適合 頭腦風暴、需求梳理、流程設計。
🔹 繪製流程圖 & 使用者旅程 —— 直覺拖拉，快速建立需求架構
🔹 無拘束討論 —— 便箋、手寫、貼圖，模擬實體白板互動
🔹 即時協作 —— 團隊成員同步編輯，遠端會議超順暢
PM 可以用 FigJam 整理需求、製作用戶流程，再將結果直接帶入 Figma 進行 UI 設計，提升專案完整度。
🎨 Figma：設計、協作、開發無縫串聯
Figma 不只是 UI/UX 設計師的神器，更是 PM 強化溝通、減少落差的關鍵工具！
✅ 即時協作 —— 多人同步編輯，像 Google Docs 一樣直覺
✅ 跨平台雲端運行 —— 免安裝，任何裝置隨時存取
✅ 快速建立原型 —— 互動式 Prototyping，讓需求一目了然
✅ 內建開發模式 —— 工程師可直接查看尺寸、色碼、CSS，減少來回溝通
✅ 設計系統支援 —— 確保 UI 一致性，提高開發效率
✅ 強大插件生態 —— 流程圖、UI Kit、假數據填充，讓設計更高效
🔗 Figma + FigJam = PM 的 UX 協作利器！
📌 會議 & 討論 → 用 FigJam 進行需求梳理、流程設計
📌 設計 & 原型 → 轉入 Figma，建立 UI 與互動流程
📌 開發交付 → 工程師使用 Figma 開發模式，無縫對接
小結
無論是從 0 到 1 的產品設計，還是日常優化迭代，Figma & FigJam 讓 PM 更輕鬆推動專案，減少來回溝通成本。
在產品開發過程中，若是針對已經存在的平台進行優化而非從零開始設計，產品經理可以選擇跳過一些對於該任務較不需要的 UX 流程。例如，若時間緊迫且無法進行詳細的 UI Mockup 精描圖設計，則可以選擇使用清晰且具邏輯性的 Wireframe，將重點放在功能和用戶體驗上，而非過度關注細節設計。這樣的做法能在保持設計清晰度的同時，提升工作效率，避免過度消耗時間，並且讓開發團隊能夠快速理解並實施調整。
課程推薦
還記得 還沒有 Figma 的時代，PM 和設計師還得依賴各種地端設計軟體，來回傳檔、版本混亂，溝通起來超崩潰！直到 Figma 橫空出世，一鍵改變了設計協作的世界。
當時我也聽過 Figma 的大名，但工作忙、時間少，自己摸索又超花時間。其實我平常不太愛買課程，但這次為了效率，想少走彎路、趕快上手，才開始認真找學習資源。後來選擇了 Hahow 的《產品設計實戰：用 Figma 打造絕佳 UI/UX》，每天午休偷偷學一點，沒想到不到一個月就能流暢上手，開始在工作中 狂用 Figma，現在完全離不開它！對 PM 來說，規劃 Wireframe 超直覺，還能跟設計師無縫協作，根本生產力神器！
如果你是 PM、產品設計新手，或想快速搞懂 Figma，別只靠自己摸索亂試了，這堂課真的能幫你 少走彎路，事半功倍，投資自己，絕對值得！打完這段突然覺得自己很像直銷 XDD ，但可以看出來我是多麼喜歡這堂課吧 ! 在這邊推薦給大家啦 🚀
結論 Recap
這邊整理一張 UX 產出的目的、應用場景等讓大家快速 recap !!
| 項目 | 目的 | 應用場景 | 交付形式 |
|---|---|---|---|
| Information Architecture 資訊架構 | 定義產品資訊的組織方式，提升用戶快速定位內容的效率 | 複雜產品或多層次結構的設計（如電商平台、資訊網站） | 階層圖（Hierarchy Diagram） |
| Functional Map 功能地圖 | 列出產品的所有功能與層級，作為功能實現的全貌與設計基礎 | 功能多樣、跨模組的產品（如 SaaS 工具、ERP 系統） | 清單、樹狀圖 |
| Flow Chart 流程圖 | 描述用戶在完成特定目標時的操作路徑與系統反應 | 用戶行為複雜或多分支流程（如註冊流程、交易支付流程） | 流程圖（Flow Diagram） |
| Wireframe 線框圖 | 初步設計頁面佈局與內容排版，展示核心功能位置 | 產品初期設計階段，用於與團隊溝通基本功能佈局 | 靜態草圖、低保真原型 |
| Wireflow 線框流 | 結合線框圖與流程，展示用戶在頁面間的操作與跳轉 | 用戶交互複雜的場景（如表單填寫與確認、多步操作） | 線框頁面可視化流程圖 |
| Mockup 精描圖 | 展示更完整的頁面視覺設計與品牌風格，接近最終產品的外觀 | 確定 UI 設計後用於內部評估與外部溝通，特別是對客戶或利害關係人展示 | 高保真設計圖（High-Fidelity） |
| UI Flow 使用者介面流 | 定義頁面之間的完整跳轉流程與互動邏輯 | 全站頁面規劃（如應用程式、網站） | 高保真設計可視化流程圖（UI Flow Diagram） |
| Prototype 原型 | 提供互動體驗的產品模擬，測試用戶操作與功能邏輯 | 用戶測試階段，驗證設計方案是否符合用戶需求 | 可交互的原型 |
這堂課教你如何編寫一份清晰且專業的 PRD（產品需求文件），確保團隊協作順利並成功交付產品。PRD 主要描述產品目標、需求、設計細節及功能，並與設計、開發、測試等團隊對接，確保開發符合最初的商業目標和用戶需求。課程內容包括：
- 什麼是 PRD，如何在產品開發中扮演關鍵角色。
- 區分 BRD、MRD、PRD 三種文件的作用。
- PRD 的結構：產品概述、功能需求、設計、技術需求、風險管理、驗收標準等。
- UX 工作產出 : 例如資訊架構、流程圖、原型等設計工具，幫助團隊達成一致，確保無誤。
掌握這些技巧，讓你從概念設計到交付流程更順利！
下一堂課，第八堂課 : 敏捷開發 (上) 敏捷核心價值以及基本框架與方法，在數位產品開發的過程中，經常聽到「敏捷開發」這個詞。但究竟什麼是敏捷？它真的能讓團隊更高效、更快速地交付成果嗎？將從敏捷的核心價值與基本框架與方法出發，一窺全貌。
📩 歡迎交流！看完文章後，若有任何想法、建議或想一起討論的話，隨時歡迎來信交流！
Miss 六月奶茶聯絡信箱 : junemilktea6@gmail.com
