設計專案文件
一句話定義
設計師在專案進行中持續記錄的 9 大組成設計操作文件——核心問題 / 研究方法 / 專案目標 / 利害關係人 / 決策記錄 / 指導原則 / 成功指標 / 工作坊 / 嘗試方案——既是團隊共識工具也是個人作品集素材，且最大化價值的紀律是為被採納而寫（建構為被採納）而非為交付而寫。
核心要點
9 大組成（Ep3 列出）
| # | 組成 | 對位 |
|---|---|---|
| 1 | 核心問題 | 對位 設計觀點 / JTBD / How-Might-We |
| 2 | 設計研究方法 | 對位 使用者研究 / 人物誌 / 同理心地圖 |
| 3 | 專案目標 | 對位 SMART目標 / Goal-Signal-Metric |
| 4 | 利害關係人有誰 | 對位 利害關係人管理 / 影響力與利益矩陣 / 利害關係人參與評估矩陣 / RACI框架 |
| 5 | 決策的記錄（誰在何時決定 / 為什麼 / 採納 vs 不採納理由） | 對位 ADR-架構決策記錄（vault 未建頁，觀察清單） |
| 6 | 整個專案的指導原則 | 對位 指導原則 |
| 7 | 成功的指標有哪些 | 對位 HEART框架 / AARRR / Goal-Signal-Metric |
| 8 | 跑過的工作坊 | 對位 利害關係人管理 步驟 3 工作坊產出 |
| 9 | 嘗試過的方案 + 採納理由 + 不採納理由 + 最終方案 | 對位 拆分需求 探索版本 + 設計探索史 |
→ 9 大組成構成 設計師的「PRD 對應物」——若 PRD 是 PM 的單一事實來源，本頁是設計師的單一事實來源。
元命題：即時記錄的雙重收益
「之後求職的時候，放在你的作品集上面也會更容易更輕易的一舉。才不會等到要做作品集的時候熊熊想不起來，我的天啊那個專案到底做了什麼東西。」 —— Blair，Unblock
雙重收益：
- (a) 團隊收益：共享給團隊看 = 避免再有任何異動的具體手段；對位 委員會設計 解方
- (b) 個人收益：即時版作品集；對位 履歷設計 / 作品集——作品集的最大成本是「事後重建」，事前記錄把成本攤平
→ 元紀律：「即時記錄」的成本由團隊收益 cover，個人收益是免費贈品。多數設計師事後做作品集才痛苦，是因為錯過了這個免費贈品階段。
2026-05-06-救救我的作品集-Ep8-作品不多也能做出面試官青睞的作品集 補上這條元命題的求職端證據：作品集若看不出 feature-level 的設計演化、決策理由與 impact，面試官容易把設計師判斷成「一個指令一個動作」。因此設計專案文件不只要留下最終稿，也要留下低保真方案、被放棄的方向、技術限制、MVP 取捨標準與成效訊號；這些才是後續 作品集 的成熟度材料。
元命題：建構為被採納（Build for Adoption, Not Handoff）
「Play for adoption, not handoff.」 —— Blair，Unblock
寫文件時的心態應該是 「之後誰會來看？」 而非 「現在我要交給誰？」。詳見 建構為被採納。
關鍵差別：
- Handoff 心態：寫給「現在的我 + 立刻要看的人」；常見後果是 3 個月後沒人看得懂、半空降的新人完全失去脈絡
- Adoption 心態：寫給「未來的、不在當下脈絡的讀者」；補入內化資訊、補入瑣碎斷片、組織成可索引的結構
→ 對位 CODE系統 的 Express 階段：在組織協作場景，Express 的對象不是「自己」而是「未來的他人」。
操作 tip：階段化記錄頻率
不同組成有不同的更新頻率：
| 更新頻率 | 組成 |
|---|---|
| 專案啟動時 1 次 | 1. 核心問題 / 3. 專案目標 / 4. 利害關係人 / 6. 指導原則 / 7. 成功指標 |
| 每場工作坊 / 訪談後 | 2. 研究方法（記錄做了什麼）/ 8. 工作坊（記錄產出） |
| 每次重大決策後 | 5. 決策記錄 / 9. 嘗試方案 + 採納理由 |
→ 1 / 3 / 4 / 6 / 7 是常駐參考頁；2 / 5 / 8 / 9 是累積追加區。設計專案文件不是單一檔案，而是一組互相連結的子文件。
與其他概念的關係
同 cluster：跨團隊協作工具
- 利害關係人管理 — 本頁是 7 階段全週期 umbrella 中「設計迭代 → 開發 → 交付」階段的核心工具
- 委員會設計 — 本頁是其反制工具之三：事前對齊（指導原則）+ 事中守線（持續提醒）+ 事後文件化（本頁）
- 指導原則 — 是本頁第 6 組成的單獨頁；guiding principles 是文件中的「定錨段」
- 建構為被採納 — 是本頁元紀律的 mindset 頁；本頁是 mindset 的具體 9 組成載體
- 利害關係人參與評估矩陣 / RACI框架 — 本頁第 4 組成「利害關係人有誰」的詳細呈現工具
對位 vault 中其他文件類型
| 文件 | 寫者 | 對象 | 邊界 |
|---|---|---|---|
| PRD | PM / UIUX | RD + PM + 業務 | 產品需求的單一事實 |
| BRD | 高層 / 策略 | C-level + BU 主管 | 商業策略 |
| MRD | PM / 行銷 | PM + 行銷 + 業務 | 市場與用戶 |
| 本頁 | 設計師 | 設計團隊 + PM + RD + 主管 + 未來新人 | 設計過程與決策 |
| 履歷設計 / 作品集 | 個人 | 求職場景 | 個人履歷與專案證據 |
→ 本頁與 PRD 是 sibling：PRD 答「做什麼產品」、本頁答「設計怎麼演化」。健康的專案兩者並存，且 PRD 第 7 部「附件」常引用本頁的探索段。
個人 PKM 對位
- 第二大腦 / CODE系統 — 本頁是 CODE 的 Capture → Organize → Distill 在設計專案場景的應用；Express 階段對應 建構為被採納
- PARA — 本頁是 PARA 中Project 層的具體文件範本
隱性對位
- ADR-架構決策記錄（vault 未建頁）— Architecture Decision Records 是工程界的「為什麼這樣設計」記錄；本頁第 5 組成「決策記錄」是其設計版
- Naming / Pull-Request — 「為未來讀者寫」的紀律在工程實踐的對應；本頁是設計實踐的對應
相關來源
- 2026-05-03-Unblock-跨團隊設計合作術-Ep3 — Blair / Unblock Ep17；vault 第一個明確展開「設計專案文件 9 組成」的來源；含「即時記錄 = 雙重收益」+「Play for adoption not handoff」元命題
- 2026-05-06-救救我的作品集-Ep8-作品不多也能做出面試官青睞的作品集 — 補入設計專案文件如何轉譯為 作品集：設計演化、取捨理由、impact 與低保真探索是面試成熟度訊號
備註
學術與業界淵源：「Design Doc」傳統上在工程界（Google / Amazon）廣泛使用——指寫在動手前的設計提案文件（含問題、方案、選擇、trade-offs）。Blair 此處的「設計專案文件」屬於 設計工作流的記錄文件，與工程 Design Doc 形式不同但精神同源——都是「為未來讀者保留決策脈絡」的文化實踐。
未來累積方向：
- ADR（Architecture Decision Record）— 每個重大決策一頁的工程界紀律；對位本頁第 5 組成
- Design System Documentation — 規模化設計組織的 component-level 文件
- Notion / Confluence / Coda 設計專案文件範本 — 業界常見的工具化呈現
- Working Backwards / PR-FAQ（Amazon 慣例）— 在動手前先寫上市新聞稿的 inverse-design 文件法
- 設計專案文件 vs 設計交付物（deliverables）的張力 — 文件是過程記錄、deliverables 是最終產出；兩者不同但常被混淆
- 與 作品集呈現（individual portfolio）的轉譯紀律 — 從團隊文件到求職 作品集 需要二次編輯（去識別化 / 去機密化 / 提煉敘事弧 / 補 impact 訊號）