PRD
一句話定義
產品需求文件——統一 PM、UIUX、RD 之間的溝通協定（Protocol），把「抽象、形而上的功能價值」用結構化文件具體化為可被工程師施工的規格。
核心要點
本質
- 溝通協定：寫 PRD 一定比口頭溝通慢，但比口頭溝通準確。
- 由大到小：撰寫過程強迫從「開立功能 → 排程規劃 → 頁面流程 → 功能參數」逐層落實，逼出「由價值到細節、由近期到遠程」的思考模式。
- 格式自由：「PRD 沒有固定的格式」——能讓開發團隊有脈絡施工、把產品做好就是好的 PRD；「千萬不要墨守成規」（Tom-Liou）。
PRD 是 產品經理 把需求與取捨轉成規格的工具之一，不是 產品思維 本體。沒有先釐清第一用戶、需求強度、商業目標與技術限制，文件再完整也只是把模糊假設寫得更正式。
什麼時候 UIUX 應該主動寫 PRD
不是只有 PM 寫——當 UIUX 兼 PM、要對接多 RD、團隊文檔散亂、人員流動高時，UIUX 自己寫 PRD 是常態。
四個觸發情境（Tom-Liou 自述）：
- 小團隊沒 PM，UIUX 兼 PM 角色
- 對口 RD 很多，需要建立設計文件 SOP 制度
- 新創高流動率 + RD 輪流交接，需可長期承載的文檔
- 打字成本比畫圖低——先打字釐清產品脈絡再進原型
2026-05-06-救救我的作品集-Ep8-作品不多也能做出面試官青睞的作品集 補上另一個求職語境：在沒有 PM 的新創 / agency 產品案中，UX/UI 設計師若主動撰寫 PRD、整理產品文件與導入設計系統，這不只是內部交付物，也可以成為 作品集 中「職能補位」與產品成熟度的證據。但作品集中要說清楚 PRD 如何幫助前後端理解功能、降低返工，而不是只列「我有寫 PRD」。
兩個工作流優點
- 降低溝通阻力：白紙黑字無含糊字眼 → 從幻想的「價值論述」收攏到實際的「功能落地」
- 統一溝通媒介：APP 牽涉的外部資源清單（語意指令 / 動作表演 / 音樂 / 動畫等）需要單一入口集中管理
七部曲結構（Tom-Liou 實踐版）
| # | 區段 | 內容 |
|---|---|---|
| 1 | 文件概況 | 修訂紀錄、日期、負責人、平台版本、產品版號、利害關係人 |
| 2 | 產品簡介與功能（Product Value） | Overview / Value / Target User / User Story / Feature / Phase / Release Version / Release Time；需求來源必填（內部企劃 / HelpDesk / 老闆） |
| 3 | 產品架構與流程 | 功能心智圖（Function Map，配 CRUD 檢查）/ 資料結構圖（IA）/ 全局與局部 Flow Chart |
| 4 | 圖形化流程與原型 | 線框圖 / 高低保真 / Mockup；越上層越文字化、越下層越視覺化 |
| 5 | 產品指標（Metrics） | 用 Goal-Signal-Metric 由大到小拆解；商業指標與體驗指標需區分 |
| 6 | 字串表（Strings Table） | key/value 定義；進版時集中至 Poedit 等字串管理工具 |
| 7 | 附件 | 切圖鏈結、各平台工作時間表 |
排程與優先級
- 把功能盤點後切 Phase 0 / 1 / 2 / 3
- P0 = MVP：先把最小可運行的產品功能定好，再依開發資源切分
- 撰文者習慣：把「用戶故事 + 功能 + 發版時間」做成綜合表格，掌控產品當前狀況
與敏捷 / Scrum 的關係
敏捷宣言從未說過「不寫文件」——只是比起「詳細的文件（施工圖）」更著重「可用的軟體」。Scrum 不寫 PRD 是錯覺。
→ 對位 專案管理「預防勝於治療」：PRD 是文檔層的事前預防工具，把延遲、誤解、變數扼殺在開發前。
撰寫工具
- 整合型：AXURE RP（整合性高，內建 Flow Chart + html 低保真原型）
- 無預算組合：Dropbox Paper / GoogleDoc（章節索引）+ Xmind / Miro / Draw.io（心智圖、流程圖）
- 範例參考：人人都是產品經理（中國大陸大量逆推 PRD 練習文章）
與其他概念的關係
- 與 產品經理：PRD 是產品經理與設計 / 工程 / 商業團隊對齊需求的常見文件，但產品經理的工作不等於寫 PRD。
- 與 產品思維：產品思維先回答「為誰解決什麼問題、為什麼這樣取捨」；PRD 再把這些判斷具體化成可施工規格。
- 與 BRD / MRD 構成**「由大到小」的三層需求文件**：BRD（戰略）→ MRD（市場）→ PRD（規格）；實務中 PRD + MRD 常揉合成單份產品提案簡報
- 與 Goal-Signal-Metric：PRD 第 5 部「產品指標」直接套用 G-S-M 思考；指標規劃在 PRD 中是必填項
- 與 UX文案：PRD 第 6 部「字串表」是 UX 文案在開發階段的交付形式——把介面引導文字結構化為 key/value 給 RD 與翻譯流程使用
- 與 專案管理：PRD 是「預防勝於治療」在文檔層的具體實踐——事前釐清需求源、版本、利害關係人，比事後救火便宜
- 與 接案提案 對位：兩者都是結構化溝通協定——接案提案面向業主（態度 → 風險五階段）/ PRD 面向 RD（七部曲）；同源精神：用結構化降低溝通阻力
- 與 使用者研究 / 人物誌：PRD 第 2 部「Target User / User Story」是 UX 研究產出在規格化階段的承接點——研究結果不能停在 Persona PDF，要轉成 PRD 中可被工程引用的條目
- 與 商業流：PRD 中的「需求來源 + 商業目標」是商業流在規格層的具體交付——回答「該做什麼產品 / 為誰做」轉成「這個版本要交付什麼功能」
- 與 拆分需求：拆分需求是 PRD 撰寫之前的需求釐清階段（Discovery 階段）——盈秀（同 AAPD-As-A-Product-Designer publication）撰 PRD 時的「使用情境」段落直接套用「依使用情境拆分」的結果（定義每個流程「起點 / 終點」）；Tom-Liou 七部曲是文檔交付結構 / 盈秀 拆分需求是 Discovery 方法論——兩者構成 AAPD 系列「Discovery → 文檔」完整工作流
- 與 INVEST原則：PRD 第 2 部「Feature 條列 + Phase 切分」的子顆粒應通過 INVEST 檢驗——若 P0 = MVP 但無法獨立交付（違反 Independent），則 P0 還沒切對
- 與 作品集：在小團隊中 UIUX 兼 PM 撰寫 PRD，可作為作品集證明「能把設計想法規格化給工程施工」的素材；重點是交代文件如何支撐決策與開發，而不是展示文件本身。
相關來源
- 2026-05-01-Tom-Liou-PRD指南 — 七部曲文檔結構主來源
- 2026-05-06-IC實驗室-產品經理消亡與產品思維 — 補入產品經理職能本質：PRD 是需求與開發橋接工具之一，不是產品思維本體
- 2026-05-01-盈秀-拆分需求 — Discovery 階段需求釐清主來源（PRD 撰寫之前的工作）；引用其「依使用情境拆分」直接對應 PRD 第 2 部使用情境段落寫法
- 2026-05-06-救救我的作品集-Ep8-作品不多也能做出面試官青睞的作品集 — Vicky 案例中 UIUX 補位 PM、撰寫 PRD 與產品文件；補入作品集語境的 PRD 證據用法
備註
本頁聚焦小團隊 / 新創語境下 UIUX 兼 PM 自寫 PRD 的撰寫實踐。中高階 PM 的需求排序評量方法（如 RICE / WSJF / Kano）超出此來源範圍，未涵蓋。
未來累積方向：
- (a) 需求排序評量方法（RICE、ICE、WSJF、Kano）
- (b) PRD 在不同產業 / 規模的差異（軟體 vs 硬體 vs 服務）
- (c) PRD 與 Design Doc / RFC / Engineering Spec 的關係
- (d) PRD 工具實作層深入比較（AXURE RP / Notion / Confluence / Linear / Productboard）
- (e) Lean PRD / 1-pager PRD 等簡化變體