委員會設計

一句話定義

設計反模式——當一個設計案被「讓每個利害關係人的意見都納入」這條原則統治時，最終產出會是各方妥協的稀釋版而非任何一方原本想要的好設計；典型徵兆是設計師無止盡的妥協 + 會議超級無效率 + 結果不如預期——對抗工具是回到「指導原則」。

核心要點

命名典故

「A camel is a horse designed by committee.」（駱駝是委員會設計的馬。）

—— Sir Alec Issigonis（1906-1988，英國汽車設計師、Mini Cooper 原型設計者）

→ Issigonis 用這句話表達「多人妥協必出怪物」的設計信念。意思是同樣要在沙漠跑長途，理性決策者會設計馬，但若每個利害關係人都加一條「我希望它更耐渴」「我希望它能背重物」「我希望它腳趾更穩」⋯⋯最後會做出駱駝。駱駝對沙漠夠用、但作為「馬」來看是徹底失敗。委員會設計的核心病症：特性堆疊取代了問題定義。

→ Issigonis 本人是 Mini Cooper 的設計者——一台單一架構師主導的經典車型；本人就是「獨裁設計」的歷史代表。他能說這句話帶著反諷的權威。

3 大徵兆（Ep3 完整心路歷程版）

徵兆 1：設計師無止盡的妥協

剛入行時的心路歷程：

1. 熱血階段 — 「我們是用設計改變世界的人」 → 一頭熱血加入公司
2. 吵架捍衛階段 — 公司 UX 文化不成熟 → 一天到晚在會議吵架捍衛使用者
3. 發現無效階段 — 大家「要聽不聽」的樣子 → 設計師覺得自己「不太好合作」
4. 全面妥協階段 — 「還是定調以團隊想要的東西為主好了」 → 妥協面積越來越大 → 「我是誰我在哪我在幹嘛」迷失
5. 中庸之道階段 — 從兩極（極端妥協 / 極端不妥協）找到中間 → 「剛柔並濟的設計師」

核心紀律：

「身為設計師，你如果還沒有站住自己的陣線、Hold 住自己最後一個陣腳的話，其實很有可能你的價值是會越來越低的——你就沒有在成為顧好使用者經驗的那個最後一道防線。」 —— Blair

→ 設計師全面妥協 ≠ 好合作；設計師全面對抗 ≠ 守紀律。剛柔並濟是中位點。

徵兆 2：會議多但沒共識

會議的反模式：

• 大家很多話想說
• 各自有意見
• 開完會 = 超多意見 + 沒有解決方向 + 沒有具體方案

Ep3 補入的解方：每場會議前就要明確「目標 + 過程 + 結果」三段式：

• 目標：這場會議要解什麼問題？
• 過程：怎麼進行？
• 結果：希望達到什麼共識？

→ 沒有這三段式的會議，必然產出「超多意見」。

徵兆 3：設計成果不如預期（馬後炮辨識）

馬後炮辨識法：專案做完之後，回看成果與原本預期的差距——差距非常遠 = 必有委員會設計。

→ 馬後炮辨識的價值不是「悔不當初」，而是作為下次專案的指導原則修訂依據。詳見「馬後炮回顧」段。

→ 三條同時出現 = 確診委員會設計；單一條出現可能只是專案前期常態。

解方 1：避免單向 UX 原則 / 數據壓人（Ep3 補入）

「不管你拿了再多的數據、再多的 UX 原則來說服他，他還是不會聽。」 —— Blair

→ 對抗委員會設計不能靠單向論證——對方不買單時，你拿再多 UX 原則也無效。真正的解法是回到 利害關係人管理 Ep1 的收編工法——把利害關係人變成盟友。

對位 信任公式：原則性論證對「已被收編的人」（高 I 熟悉度 + 低 S 自利）有效，對「未被收編的人」沒用。先建立信任、再講原則。

解方 2：回到 指導原則（umbrella 仲裁工具）

委員會設計的根因是「沒有比意見更高的判準」——每條意見都被等同對待，於是會議變成意見市場。指導原則 (guiding principles) 是對抗委員會的高階仲裁工具。

指導原則 4 條（與 利害關係人管理 工作坊產出物完全對齊）：

1. 專案價值 values — 為什麼要做這個專案？
2. 方法 methods — 用什麼方式做？
3. 已知數據 facts — 有什麼研究 / 用戶行為 / 競品數據可參考？
4. SMART目標 — 量化、可驗收、可被多方接受的成功定義

→ 每次會議出現「這個能不能也加進來」時，設計師主動拿這 4 條對照——不符合的一律拒絕。「不」這個字的合法性來源不是設計師的個人偏好，而是事先共識的指導原則。

Ep3 深化：會議內持續提醒紀律

當會議中有人在共識部分翻案：

1. 設計師不要進防禦模式（不馬上變刺蝟、不顧左右而言他、不防衛性地說「為什麼要提出來」）
2. 平心靜氣 + 深呼吸
3. 拿出「尚方寶劍」guiding principles
4. 提醒：「你們現在提出這些異動，跟我們專案的原本目的好像沒有很相關，是不是先把這樣的異動放在一邊？」

Ep3 深化：但保持靈活（健康用法）

「不要直接拿這份指導原則說『我明明就寫這樣，那時候的目標跟已知事實就不是這樣啊』——不要不要不要。」 —— Blair

健康用法：主動詢問「現在我們有沒有遇到哪些挑戰，是專案的指導原則已經不太適用的？」

• 若需要修訂 → 大家重新達成一次共識修訂
• 若不需要修訂 → 理直氣壯地把會議拉回議程

→ 指導原則是錨，不是枷鎖。詳見 指導原則 三段式紀律。

解方 3：找出反饋背後的「為什麼」

「盡力找出利害關係人給出某設計回饋的理由」 —— Blair

很多委員會設計的意見其實不是真心要那個設計，而是反映對方更深的擔憂或目標——

• 「字大一點」← 真實擔憂：自己的長輩用戶看不清
• 「加一個按鈕」← 真實擔憂：自己的 KPI 漏掉某個轉換路徑
• 「用紅色」← 真實擔憂：跟其他同事的提案區隔

→ 找出真實擔憂後，可以不採納原意見而用更好的設計同時解決真實擔憂——這條紀律對位 原則性談判法「立場 vs 利益」與 信任公式 的「降 S 提 I」。

解方 4：「招兵買馬」防禦會議技巧（Ep3 補入）

核心動作：當回饋給予者的個人偏好非常明顯時，主動問會議中其他人：「有沒有其他人也感覺到一樣的挑戰？有沒有其他人有不同的意見可以解決這個挑戰？」

→ 看似團隊合作（把所有人意見納進來），實際上變相擋掉個人偏頗意見——把 1 個人的偏好稀釋為團隊的多元意見。

為什麼有效：

• 對話結構從「設計師 vs 提意見者」變成「全團隊 vs 一個問題」
• 團隊其他成員的「沒這個感受 / 我有不同想法」自然削弱原偏頗意見的權威
• 提意見者無法將其感受為「設計師在針對我」——是團隊在共同探討

注意紀律：不能讓對方識破「這是你在擋我」。「招兵買馬」的執行要真誠地希望聽到團隊意見，而非只是話術——否則會破壞 信任公式 的 S 軸。

解方 5：馬後炮回顧（Ep3 補入）

專案結束 = 整個團隊檢討的最佳時機。

回顧檢核項：

• 哪些指導原則已經偏離但沒人拉回來？
• 對哪些事實的掌握不足？

典型 fact-blindness 案例（Blair 舉例）：

PM 以為「推出更多客製化功能可以避免客戶流失」 → 結果發現事實上是「整合功能不足」導致流失 → 再多客製化設計都無效。

→ 馬後炮回顧的價值是把「錯誤事實假設」變成下一輪的指導原則修訂依據。對位 完成的定義：完成 ≠ ship，包含回顧 + 學到下一輪的脈絡。

解方 6：設計即假說 心態（Ep3 元命題）

「直到設計被驗證以前都只是假說；對方意見也是假說。」 —— Blair

把所有論證都降階為待驗證假說 → 委員會設計失去「意見鬥爭」的戰場 → 焦點轉到「怎麼驗證」。詳見 設計即假說。

為什麼「全部納入」聽起來像對的事，做起來是災難

組織心理學上「全部納入」迎合 3 種感覺：

• 公平感 — 每個聲音都被聽到
• 政治正確 — 不得罪任何利害關係人
• 責任分散 — 失敗了不是任何單一決策者的錯

但設計上「全部納入」必然產生：

• 特性肥腫 — UI 上塞了所有人想要的東西
• 訊息混亂 — 沒有任何單一訊息突出
• 使用者放棄 — 看不懂、找不到、用不會
• 沒有任何人為結果負責 — A 不唯一（對位 RACI框架 的 A 紀律）

→ 委員會設計的反面不是獨裁設計，而是「有清晰判準的協作設計」——每個意見都被聽、但只有符合指導原則的會被納入。

與其他概念的關係

同 cluster：跨團隊協作反模式 / 對抗工具

• 利害關係人管理 — 工作坊產出的「指導原則」是本反模式的反制工具；Ep15 的工作坊機制 + 本頁的「會議中時時提醒」共構事前共識 + 事中守線雙紀律
• 影響力與利益矩陣 — 「高影響低利益」象限的隱形殺手在會議中製造委員會設計的最大來源（沒利益但有否決力 → 透過加意見阻擋）；本頁的解方對應該象限的反制動作
• SMART目標 — 指導原則第 4 條；具體寫法的目標讓「再加一條」會被「這跟我們的成功定義對齊嗎？」自動篩掉
• RACI框架 — A 不唯一是委員會設計的結構性溫床；RACI 強迫 A 唯一的紀律從制度面對抗委員會
• 拆分需求 — 拆得不夠細的需求容易被各方「全包進去」；INVEST 的 Small + Independent 對抗委員會
• 原則性談判法 / 把人跟問題分開 — 找出意見背後的真實擔憂 = 「立場 vs 利益」分離在設計回饋場景的應用

隱性對位

• 信任公式 — 高 I（熟悉度）讓設計師有空間問「你說這個的背後是什麼？」而不被認為是質疑；低 S（自我利益）讓對方相信你問這個不是為了否決他
• Goal-Signal-Metric — G-S-M 拆解產出的可量測指標 = 指導原則第 3 條「已知數據」的具體載體；無 G-S-M 時「數據驅動」會變成「誰的數據聲量大誰贏」

反面範式

• 獨裁設計 — 委員會設計的另一極端；單一決策者拍板、不徵詢；典型場景：早期賈伯斯時期 Apple；風險是設計師一人偏見放大、組織知識浪費
• 協作設計（Co-design）— 健康中位點：多方參與 + 清晰判準；本頁的核心訴求

相關來源

• 2026-05-03-Unblock-跨團隊設計合作術-Ep1 — Blair / Unblock Ep15：利害關係人管理 工作坊「指導原則」的原始出處（4 條指導原則的來源）
• 2026-05-03-Unblock-跨團隊溝通協作懶人包 — Blair / Unblock：vault 第一個明確命名「委員會設計」反模式的來源；含 3 徵兆 + 2 解方（找回饋理由 + 提醒指導原則）；指導原則 4 項與 Ep15 工作坊產出物完全對齊
• 2026-05-03-Unblock-跨團隊設計合作術-Ep3 — Blair / Unblock Ep17：本頁的主要深化來源——補入 Sir Alec Issigonis 命名出處 + 3 徵兆完整心路歷程版（剛柔並濟設計師演化）+ 招兵買馬技巧 + 指導原則持續提醒紀律 + 馬後炮回顧 + 設計即假說心態

備註

學術與通俗淵源：「Design by committee」一詞由 Sir Alec Issigonis（Mini Cooper 設計師）以「駱駝是委員會設計的馬」這句廣為流傳——Issigonis 本人是「單一架構師」設計範式的歷史代表。學術上 Fred Brooks《人月神話》（1975）的「概念整合性」（conceptual integrity）論點與 Conway’s Law（1968）「組織設計什麼樣的系統，反映了組織自己的溝通結構」是其更深的理論基礎。

未來累積方向：

• Conway’s Law 對位委員會設計：組織結構 → 設計結構 → 委員會設計的因果鏈
• Fred Brooks《人月神話》「概念整合性」（conceptual integrity）論點 — Brooks 主張「最好的設計來自單一架構師（小團隊）」；對位本頁的「協作 vs 獨裁」中位點
• Apple vs Google 設計文化對比 — Apple 偏獨裁設計（單一品味判準）/ Google 偏協作設計（多方數據判準）；兩者各有委員會風險
• 設計衝刺 Sprint 作為對抗委員會的時間箱工具：5 天內強迫收斂，制度性對抗無止盡妥協
• Design Critique 文化：固定批評儀式 + 結構化回饋（SBI溝通術 / I-Like-I-Wish-What-If）作為對抗委員會的中間機制
• Pixar Braintrust 模型：高密度但非決策權的回饋會議；對位本頁的「找回饋理由 ≠ 採納回饋」紀律