建構為被採納

Properties2
tags狀態/草稿, 領域/ux, 領域/設計, 領域/管理, 領域/pkm, 領域/反模式
aliasesBuild for Adoption, Build for Adoption Not Handoff, Adoption-Mindset, Play for Adoption, 為被採納而建構, 為採納而非交付

閱讀時間約 9 分鐘

建構為被採納

一句話定義

Unblock Blair 提出的設計交付元命題——「Build for adoption, not handoff.」——把寫文件 / 做交付的對象從「現在的接收者」轉成「未來的、不在當下脈絡的讀者」；元洞見是組織的瓶頸往往不是員工不寫文件，而是缺乏中心化的 findability。

核心要點

元命題

「Play for adoption, not handoff.」 —— Blair，Unblock Ep17

英文原句也常見為 “Build for adoption, not handoff.”——精神同源：

  • Handoff 心態 = 把東西交出去就好（責任轉移）
  • Adoption 心態 = 確保東西被使用（價值實現）

→ 設計師、PM、工程師、文件作者都常陷入 handoff 心態——交付的瞬間以為任務完成，實際上沒被採納的交付等於沒完成。

三條核心紀律

1. 寫給「半空降進來者」視角

「之後誰會來看這個文件？他們需要哪些額外的資訊？」

寫文件時的盲區：

  • 內化資訊 — 你已經知道、覺得是常識，但新讀者不知道
  • 播出脈絡 — 為什麼這個專案存在、為什麼選這個方向、為什麼放棄某些方向
  • 瑣碎斷片 — 跨會議才知道的細節、口頭達成的共識、某個人某天的反對意見

→ 檢驗法：找一個完全沒參與這個專案的同事讀你的文件，看他能不能 30 分鐘內理解全貌。讀不懂的部分 = 你的內化盲區。

2. 中心化的 findability > 單一文件品質

「很多時候組織的問題並不是員工不寫文件、不記錄、或不保留文件，而是他們缺乏一個中心化的地方來讓大家可以找到、查閱所有的文件。」 —— Blair

反直覺洞見：寫了沒人找得到 = 沒寫。

常見組織誤判真正瓶頸
「員工不寫文件」寫了但沒地方存
「員工不更新文件」不知道別人在更新哪份
「文件品質不好」找不到就無從評論品質

→ 設計專案文件的架構（在公司文件系統中的位置）比單一文件的品質更影響 adoption。

3. 共享給團隊 = 預防異動

把決策過程主動共享給團隊有雙重效果：

  • 正向：讓團隊持續對齊
  • 反向（防委員會設計）：對齊過的決策難被翻案——文件化後，異動者要解釋「為什麼推翻」而非設計師要解釋「為什麼這樣」

→ 對位 委員會設計 解方：事前對齊（指導原則）+ 事中守線（持續提醒）+ 事後文件共享（本頁第 3 紀律）= 三段紀律。

跨職能即時溝通工具箱（adoption 加速器）

開發階段降低工程師理解成本的 6 種工具：

#工具適用情境
1面紙 / 紙上草圖旁邊立即討論可行解方
2白板多人即時討論達共識
3Keynote / 簡報軟體比較正式 / 會後分享
4高敏真原型疊加工程師問細節時直接展現；以既有設計稿為基底
5Loom 錄影（Slack channel 內）輕便小巧的解釋互動效果；非同步
6Zoom 螢幕錄製 + 講解同步螢幕錄製口述設計意圖

共通紀律：

「畢竟不是每一個跨團隊的夥伴，都這麼習慣自己去點擊那些原型。」 —— Blair

→ adoption-mindset 在工具選擇的具體展現：不要假設對方有耐心 / 有技能 / 有時間。主動降低對方的理解成本 = 主動增加 adoption 機率。

元紀律：完成 = 被採納

對位 完成的定義：完成的標準不是 ship，而是「有人因此使用了 / 改變了行為」。

  • Ship + 沒人用 = 失敗
  • Ship + 被找到 + 被採納 + 改變行為 = 完成

→ 「Build for adoption」是在 ship 之前就把 adoption 路徑想清楚。

與其他概念的關係

同 cluster：跨團隊協作工具

  • 利害關係人管理 — 本頁是 7 階段全週期 umbrella 中「交付 / Adoption」階段的核心 mindset
  • 設計專案文件 — 是本頁的具體 9 組成載體；mindset → tool 關係
  • 委員會設計 — 本頁第 3 紀律「共享給團隊預防異動」是其反制工具之三
  • 指導原則 — 文件化的指導原則是 adoption 的定錨段

個人 PKM 對位

  • CODE系統 — Tiago Forte 的 Express 階段在組織協作場景的擴展；CODE 的 Express 對象是「自己」、本頁 Express 對象是「未來的他人」
  • 第二大腦 — 個人版的「為未來自己寫」 / 本頁是組織版的「為未來他人寫」
  • PARA / Actionability — 「輸出決定輸入」原則在組織文件的應用：寫文件的人應反推「這份文件會在誰的什麼 Project 被用到？」

工程實踐對位

  • Naming — 「未來自己也是讀者」紀律的程式碼版；本頁是文件版
  • Pull-Request — PR description 是「為 reviewer 寫」；本頁紀律的工程版
  • GitHub工作流 — squash-merge 維持 main 簡潔的紀律也是 adoption mindset 的一種（讓未來閱讀 git log 的人輕鬆）
  • AGENTS-md / CLAUDE.md — 「為未來的 LLM agent 寫」是 adoption mindset 在 AI 時代的延伸

反面對位

  • Handoff 心態 — 把文件丟過去 / 把設計交給工程就完事；最常見的設計師 / PM 失敗模式
  • Hero Documentation — 寫超詳細但只有自己懂的文件；adoption = 0
  • Tribal Knowledge — 知識只在資深員工腦中；本頁紀律的最壞反例

隱性對位

  • 最後一哩 — 物流 / 行銷常用詞；本頁是「最後一哩」在組織知識管理的應用：文件寫完只是交付，讓未來讀者找得到、看得懂、願意使用才是 adoption 的最後交付段
  • Net Promoter Score 的擴展邏輯：你的文件讓多少人「會推薦給其他人」？

相關來源

  • 2026-05-03-Unblock-跨團隊設計合作術-Ep3 — Blair / Unblock Ep17；vault 第一個明確展開「Play for adoption, not handoff」元命題的來源；含三條核心紀律（半空降視角 / 中心化 findability / 共享預防異動）+ 跨職能即時溝通工具箱

備註

學術與業界淵源：「Build for adoption, not handoff」精神在敏捷 / DevOps / Design Ops 文化中廣泛存在，但常以隱性紀律存在而非命名概念。Donald Norman《Design of Everyday Things》的「signifier」概念（產品的可發現性）是其哲學基底；Edward Tufte「Above All Else, Show the Data」是其視覺呈現版。本頁初版以 Blair Unblock 影片版本為主，未深化學術原典。

未來累積方向：

  • Design Ops — 規模化設計組織的 adoption infrastructure
  • Internal Developer Platform / IDP — 工程界的「降低 adoption 門檻」基建
  • Onboarding Documentation — 新人入職文件的 adoption 紀律
  • Knowledge Graph / Confluence Tree — 中心化 findability 的具體工具實作
  • 與 產品的 AARRR Activation 階段 對位 — 文件的 Adoption 與產品的 Activation 同精神
  • Failure to Adopt 的反模式列舉（無人寫 / 寫了沒人找 / 找到了沒人懂 / 懂了沒人用 / 用了沒回饋）

反向連結