學校沒教的跨團隊設計合作術 Ep3：設計迭代與開發階段如何跨團隊溝通
後設資料
- URL：https://www.youtube.com/watch?v=tsvSbvTv0GM
- 頻道：Unblock
- 主持人：Blair
- 集數定位：Unblock「跨團隊設計合作術」迷你影集最終第 3 集（共 3 集；對應頻道 Ep17）
- 上集：2026-05-03-Unblock-跨團隊設計合作術-Ep2
- 上上集：2026-05-03-Unblock-跨團隊設計合作術-Ep1
- 配套發行物：2026-05-03-Unblock-跨團隊溝通協作懶人包 PDF
- 內容形式：YouTube 影片（口語講解 + 投影片 + 漫畫案例）
- 語言：繁體中文
- ASR 來源：YouTube 自動字幕（含明顯辨識錯誤；wiki 摘要段已修訂）
一句話濃縮
設計迭代到開發完成的下半場跨團隊合作工法——以 「設計即假說」 為心態 + 委員會設計 3 徵兆 + 解方深化（拿出「尚方寶劍」guiding principles + 招兵買馬擋偏頗意見 + 馬後炮回顧）+ 設計-開發跨職能即時溝通工具箱（面紙草圖 / Loom / Zoom 螢幕錄製）+ 設計專案文件 9 大組成 + adoption-mindset（「Build for adoption, not handoff」），把 Ep1+Ep2 收編 / 衝突 / 共識下半場接到專案落地。
提取要點
元命題
「直到你的設計被驗證以前，它都只是你的假設或假說；你要推廣這個心態給利害關係人。」 —— Blair
→ 完整版包含對等紀律：「他們提出的意見，在他們有辦法驗證以前，也只是他們的假說。」這條把「設計師 vs 利害關係人」的權威之爭轉成「雙方共同面對驗證」的合作關係——是 Ep3 的精神基底。
三集架構回顧
| 集 | 階段 | 核心 |
|---|---|---|
| Ep1 | 專案啟動期 | 收編利害關係人、定指導原則 |
| Ep2 | 中期信任 + 衝突峰值 | Trust Equation、RACI、I-Statement、衝突管理 |
| Ep3 | 設計迭代 → 開發 → 交付 | 委員會設計深化 + 跨職能即時溝通 + 設計專案文件 + adoption-mindset |
→ Ep3 完成 in-house 產品設計師「啟動 → 中期 → 衝突 → 共識 → 迭代 → 開發 → 交付」7 階段全週期工法線。
主題 1：委員會設計 深化
命名典故（Ep3 補入）
「A camel is a horse designed by committee.」 —— Sir Alec Issigonis（Mini Cooper 設計師）
懶人包 / Ep1 都未明示出處，Ep3 補上 Issigonis 的歸因。Issigonis 是英國汽車設計師、Mini 的原型設計者；他用這句話表達「多人妥協必出怪物」的設計信念。
漫畫案例引用
Blair 在影片中引述 marketoonist.com（推測為 Tom Fishburne 的行銷漫畫網站；ASR 拼成 “marketuniverse.com”）的兩張漫畫——典型場景：
- 設計師每出一個方案，會議裡的人就根據個人喜好提改動
- 「我覺得這個顏色太無聊了，加一些這些顏色吧」/「不如加 5 個促銷 banner」
- 最後產出「一事無成、讓人無法直視」的設計稿
3 徵兆深化版（Ep3 完整展開）
| # | 徵兆 | Ep3 補入的細節 |
|---|---|---|
| 1 | 設計師無止盡的妥協 | 心路歷程：熱血 → 妥協 → 「我是誰我在哪我在幹嘛」迷失 → 找到中庸之道 → 剛柔並濟。核心紀律：設計師如果還沒站住自己的陣線，價值會越來越低，不再是顧好使用者經驗的最後一道防線 |
| 2 | 會議多但沒共識 | 大家很多話想說，但沒有解決方向、沒有方案 |
| 3 | 設計成果不如預期（馬後炮辨識） | 專案結束回看，與原本預期差距非常大 → 必有委員會設計痕跡 |
解方 1：避免當「家藝」+ 不一昧拿 UX 原則 / 數據壓人
「不管你拿了再多的數據、再多的 UX 原則來說服他，他還是不會聽。」
→ 解法是回到 Ep1 的收編工法——把利害關係人變成盟友。原則性論證對「已被收編的人」有效，對「未被收編的人」沒用。
解方 2：詢問回饋背後的「為什麼」+ 招兵買馬技巧（Ep3 補入）
「招兵買馬」防禦性會議技巧：當回饋給予者的個人偏好非常明顯時，主動問會議中其他人：「有沒有其他人也感覺到一樣的挑戰？有沒有其他人有不同的意見可以解決這個挑戰？」
→ 看似團隊合作，實際上變相擋掉個人偏頗意見——把 1 個人的偏好稀釋為團隊的多元意見。核心動作：把「對話」從「設計師 vs 提意見者」變成「全團隊 vs 一個問題」。
解方 3：會議中持續提醒「上方寶劍」指導原則（Ep3 補入紀律）
當有人在共識部分翻案時：
- 設計師不要進防禦模式（不馬上變刺蝟、不顧左右而言他）
- 平心靜氣 + 深呼吸
- 拿出 指導原則 guiding principles（價值 / 方法 / 已知事實 / SMART 目標）
- 提醒：「你們現在提出這些異動，跟我們專案的原本目的好像沒有很相關」
解方 4：保持靈活（Ep3 補入紀律）
不要死守 guiding principles：
「不要直接拿這份指導原則說『我明明就寫這樣，那時候的目標跟已知事實就不是這樣啊，我們就應該 follow 這個』——不要不要不要。」
健康用法：主動詢問「現在我們有沒有遇到哪些挑戰，是專案的指導原則已經不太適用的？」
- 若需要修訂 → 大家重新達成一次共識修訂指導原則
- 若不需要修訂 → 理直氣壯地把會議拉回議程，不被旁支耽擱
解方 5：專案結束時的馬後炮回顧（Ep3 補入）
專案結束 = 整個團隊檢討的最佳時機。
回顧檢核項：
- 哪些指導原則已經偏離但沒人拉回來？
- 對哪些事實的掌握不足？例：PM 以為「客製化功能可以避免客戶流失」、結果發現是「整合功能不足」導致流失——此時再多的客製化設計都無效
→ 對位 完成的定義：完成不是 ship，而是回顧 + 學到下一輪的脈絡。
主題 2：設計-開發跨職能即時溝通工具箱
工程師交付期 slap：「Houston, we have a problem」
開發過程中工程師常見的壞消息：
- API 後端團隊「這個雞好像生不太出來」（產出時間超預期）
- 沒辦法做出設計師理想的樣子
- 出現未考慮過的 common cases / edge cases
設計師應保持彈性的 5 種跨職能溝通工具
| # | 工具 | 適用情境 |
|---|---|---|
| 1 | 面紙 / 紙上草圖 | 旁邊立即討論可行解方 |
| 2 | 白板 | 多人即時討論達共識 |
| 3 | Keynote / 簡報軟體 | 比較正式 / 會後分享（ASR「機保針」推測） |
| 4 | 高敏真原型疊加 | 工程師問視覺 / 互動細節時直接展現；以既有設計稿為基底加細節 |
| 5 | Loom / Slack 錄影 | 在 Slack channel 直接錄輕便 Loom 解釋互動效果 |
| 6 | Zoom 螢幕錄製 + 講解 | 螢幕錄製的同時口述設計意圖 |
→ 共同紀律：「畢竟不是每一個跨團隊的夥伴，都這麼習慣自己去點擊那些原型」——主動降低工程師的理解成本。
主題 3：設計專案文件（Design Project Documentation）
9 大組成（Ep3 列出）
設計師專案進行中應持續記錄：
- 核心問題
- 設計研究方法
- 專案目標
- 利害關係人有誰
- 決策的記錄（誰在何時決定 / 為什麼）
- 整個專案的指導原則
- 成功的指標有哪些
- 跑過的工作坊
- 嘗試過的方案 + 採納理由 + 不採納理由 + 最終方案
雙重收益：個人作品集
「之後求職的時候，放在你的作品集上面也會更容易更輕易的一舉。才不會等到要做作品集的時候熊熊想不起來——我的天啊那個專案到底做了什麼東西。」
→ 設計專案文件 = 即時版的作品集。對位 履歷寫作 / 履歷設計：完整的專案文件本身就是高品質作品集素材。
共享給團隊的副效益
把決策過程共享給團隊看 = 避免再有任何異動的方法。對位 委員會設計 解方：事前對齊 + 事中守線 + 事後文件化 三段紀律。
主題 4：建構為被採納（Build for Adoption, Not Handoff）
元命題
「Build for adoption, not handoff.」（不是「交付完就好」，而是「為被使用而建構」。）
→ 寫文件時心裡想著 adoption——「之後誰會來看這個文件？他們需要什麼資訊才能用得上？」
寫文件的「半空降進來者」視角
寫文件時的紀律：
- 內化的資訊（你已經知道）≠ 新讀者的資訊（他們不知道）
- 半空降進來的人不知道你的播出脈絡
- 有哪些瑣碎斷片的資訊是他們不會知道的
→ 對位 Naming / CODE系統 的「未來自己也是讀者」紀律——文件對未來讀者的可讀性 > 對作者當下的書寫便利。
組織瓶頸不是員工不寫文件
「很多時候組織的問題並不是員工不寫文件、不記錄、或不保留文件，而是他們缺乏了一個中心化的地方來讓大家可以找到、查閱所有的文件。」
→ Adoption 的瓶頸是 findability，不是 quality。寫了沒人找得到 = 沒寫。設計專案文件的架構比單一文件的品質更重要——把文件放在公司文件結構中正確的位置是 adoption 的前置條件。
主題 5：三集總結
Ep1：及早掌握你的利害關係人、掌握專案指導原則、靈活運用工具、保持開放心態。
最最最重要的：帶著你的團隊一起見證 UX 所帶來的好處。
元命題：跑得久跑得遠 vs 跑得快
「你一個人雖然跑得非常快，但是帶著你的團隊一起跑，才會跑得久跑得遠。」
→ 對應非洲諺語「If you want to go fast, go alone. If you want to go far, go together.」(Blair 沒明示引用)。對位 利害關係人管理 元命題「點子被否決 ≠ 點子不夠好」+「共識與信任是人工後天創造」+ 本句 = Unblock 三集合計3 條核心元命題。
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
- 設計即假說 — 本來源新建：「直到設計被驗證以前都只是假說」meta-mindset；vault 第一個 hypothesis-driven design 概念頁
- 設計專案文件 — 本來源新建：9 大組成 umbrella；對位 PRD（PM 的文件）/ 履歷設計（個人檔案）；設計專案文件是團隊層級的設計操作文件
- 建構為被採納 — 本來源新建：「Build for adoption, not handoff」元命題；vault 第一個 handoff vs adoption 反模式對抗框架
- 指導原則 — 本來源新建：guiding principles 4 組成 (values / methods / facts / SMART)；recurring across Ep1 + 懶人包 + Ep3，三來源共建獨立頁
- 委員會設計 — 大幅更新：補入 Sir Alec Issigonis 命名典故 + 3 徵兆 Ep3 完整展開（妥協 / 會議無共識 / 馬後炮）+ 招兵買馬技巧 + 指導原則持續提醒紀律 + 馬後炮回顧紀律
- 利害關係人管理 — 更新：4 階段 (Ep1+Ep2 已建)擴展為 7 階段全週期 (補 5. 設計迭代 / 6. 開發 / 7. 交付 + adoption mindset)；補入「設計即假說」共識心態
- Unblock — 更新：Ep17 URL 補入 + 三集主題完成標註（trilogy complete）
- 完成的定義 — 既有概念對位：Ep3「專案結束 = 馬後炮回顧最佳時機」是「完成 ≠ ship」的具體展開
- 履歷設計 / 作品集 — 對位：設計專案文件即時記錄 = 即時版作品集
- SBI溝通術 — 對位：設計-開發跨職能即時溝通工具是 SBI「結構化句型」之外的「結構化視覺呈現」家族
- 拆分需求 / PRD — 對位：本系列最後完成設計師端的「拆分後的執行協作 + 文件化」工法
- CODE系統 / 第二大腦 — 對位：設計專案文件即時記錄是 Tiago-Forte CODE 流程在設計專案場景的應用
Ingest 筆記
本次 ingest 是 Unblock 跨團隊設計合作術迷你影集第 3 集（最終集）——前 2 集 + 配套懶人包 PDF 已於同日 ingest（2026-05-03-Unblock-跨團隊設計合作術-Ep1 / 2026-05-03-Unblock-跨團隊設計合作術-Ep2 / 2026-05-03-Unblock-跨團隊溝通協作懶人包）。本集完成 4-source cluster 的最後一塊，是 vault 中第一個完整 ingest 的 mini-series + companion deliverable。
ASR 修訂（不窮盡）
- 「學校沒交」→ 學校沒教
- 「DX 文化」→ UX 文化
- 「marketuniverse.com」→ marketoonist.com（推測 Tom Fishburne 的行銷漫畫站）
- 「家藝」→ 嫁衣（「不要當嫁衣」推測；ASR 不確定）/ 或為「答應」相關詞
- 「厲害觀點 / 厲害官員 / 厲害的關鍵人 / 厲害關係人」→ 統一為 利害關係人
- 「招兵買馬」→ 正確（成語）
- 「上方寶劍」→ 尚方寶劍（成語）
- 「顧前提」→ 顧此失彼（推測）
- 「顧左右而言差」→ 顧左右而言他（成語）
- 「心臟 BAD」→ 心臟病（口語化）
- 「機保針」→ Keynote（推測為簡報軟體）
- 「來長慶公司」→ 來自前公司（推測）
- 「Sir Alex Issigoni」→ Sir Alec Issigonis（Mini Cooper 設計師正名）
- 「play for adoption not handle」→ Build for adoption, not handoff（推測為原英文）
- 「他從迭代到開發完成之間」→ 推測為「設計從迭代到開發完成之間」
- 「Disc 檔」→ Loom（Slack channel 內錄影通常指 Loom；Disc 為 ASR 錯誤）
- 「總決心」→ 總決賽（推測）
- 「跑圖工作坊」→ 跑過工作坊
- 「事鞋」→ 試試
- 「銘了」→ 明了
- 「Houston, we have a problem」→ Apollo 13 引用（正確）
- 「MING PAO CANADA / MING PAO TORONTO」→ YouTube auto-caption 干擾（疑似媒體浮水印或字幕系統錯誤；非影片內容，不入 wiki）
- 「機保針」第二次出現（「機保針的方式去討論」）→ 推測為「Keynote 共享」或「會保針 = 會議白板筆」
- 「事鞋過這些方式」→ 試過這些方式
- 「請對位無止盡的妥協」→ 設計師無止盡的妥協
- 「進當的設計師」→ 精明的設計師
- 「未卜先知」→ 正確（成語）
- 「靈活運用」→ 正確
- 「保持彈性」→ 正確（影片內反覆使用）
- 「鞋面紙」→ 拿一張面紙
概念抽取的判斷
為什麼 設計即假說 獨立成頁？
- Ep3 開場的 meta-mindset 元命題（「直到驗證前都只是假說」），且包含對等紀律（利害關係人意見也是假說），是 vault 第一個明確的 hypothesis-driven design 概念
- 對位 Test（設計思考第五階段）的「驗證前都只是假設」精神在跨團隊場景的擴展
- 未來累積方向豐富：Lean UX / Eric Ries Lean Startup / Continuous Discovery Habits（Teresa Torres）/ A/B Testing 都是這條的下游
- 本身有清晰邊界：不是研究方法（不告訴你怎麼驗證），而是心態 + 共識工具（雙方平等面對驗證）
為什麼 設計專案文件 獨立成頁？
- Ep3 列出 9 大組成是清晰的工具邊界
- 對位 vault 中既有的多個文件類型形成清晰位置：
- 是 利害關係人管理 7 階段中「文件化」階段的核心工具
- 對位 第二大腦 / CODE系統 在設計工作流的應用
為什麼 建構為被採納 獨立成頁？
- 「Build for adoption, not handoff」是 Ep3 的主軸元命題，且包含完整框架：
- 半空降進來者視角（誰來讀文件）
- 中心化 findability（組織瓶頸不是品質而是位置）
- 共享給團隊預防異動（adoption 的擴散路徑）
- 是 vault 第一個 handoff vs adoption 反模式對抗框架
- 對位 Tiago-Forte CODE 系統的「Express」階段在組織協作的擴展
- 與 設計專案文件 是 mindset → tool 關係（adoption 心態 → 9 組成文件實作）
為什麼 指導原則 獨立成頁？
- 三來源共建（Ep1 / 懶人包 / Ep3），且每個來源從不同角度補充：
- Ep1：工作坊事前產出（價值 / 方法 / 數據 / SMART）
- 懶人包：事中對抗委員會設計
- Ep3：深化會議內實操（持續提醒 + 評估修訂 + 不死守紀律）
- 在 利害關係人管理 / 委員會設計 / SMART目標 / 設計專案文件 多頁中被反覆引用，獨立頁是「集散頁」型概念
- 與 guiding principles（英文）+ 企業價值觀 / 公司原則（更廣概念）的對位空間大
為什麼 招兵買馬 / 「剛柔並濟的設計師」/ 「設計-開發溝通工具箱」不獨立建頁？
- 招兵買馬：是會議內單一情境戰術；獨立建頁會孤兒化（無多源累積）；併入 委員會設計 解方段
- 剛柔並濟的設計師：太詩意；本質是「設計師心態演化」narrative；併入 委員會設計 徵兆 1 的心路歷程段
- 跨職能即時溝通工具箱：5-6 個工具是操作性 list；獨立建頁太薄；併入 建構為被採納 的「降低工程師理解成本」段
對 利害關係人管理 umbrella 的擴充
Ep1 + Ep2 已建立 4 階段：啟動 → 中期 → 衝突 → 共識。Ep3 補入後段 3 階段：
| 階段 | 來源 | 核心工具 |
|---|---|---|
| 5. 設計迭代 | Ep3 | 委員會設計 反模式深化 + 招兵買馬技巧 + 指導原則 持續提醒 |
| 6. 開發 | Ep3 | 跨職能即時溝通工具箱（面紙 / 白板 / Keynote / 高敏原型 / Loom / Zoom） |
| 7. 交付 / Adoption | Ep3 | 設計專案文件 9 組成 + 建構為被採納 mindset + 馬後炮回顧 |
→ 完整 7 階段 stakeholder 生命週期 = vault 中最完整的單一 in-house 設計師工法線。
跨頁影響鏈
- 委員會設計 大幅升級：學術出處從「無明確歸因」升級為「Sir Alec Issigonis（Mini Cooper 設計師）」；3 徵兆從「3 條一句話」深化為「3 條各帶心路歷程 / 馬後炮辨識 / 防禦動作」；解方從 2 條擴展為 5 條
- 利害關係人管理 umbrella 擴展為完整 7 階段生命週期；補入「設計即假說」作為跨階段共識心態
- Unblock entity Ep17 URL 補入；mini-series 標註為 trilogy complete；備註強化「單一作者多形式 + 完整三集」的累積模式
- SMART目標 / Goal-Signal-Metric 透過 指導原則 新頁形成新的對位關係（指導原則是 SMART 的 umbrella，G-S-M 是指導原則「已知數據」項的具體載體）
觀察清單
| # | 待 ingest 項 | 來源 |
|---|---|---|
| 1 | Sir Alec Issigonis entity（Mini Cooper / British Motor 工業設計師） | 本影片提及 |
| 2 | marketoonist.com / Tom Fishburne 行銷漫畫 entity | 本影片漫畫案例引用 |
| 3 | Lean UX（Jeff Gothelf 2013）— hypothesis-driven design 系統來源 | 設計即假說 學術深化方向 |
| 4 | Continuous Discovery Habits（Teresa Torres 2021）— 持續驗證 mindset | 設計即假說 累積方向 |
| 5 | Loom entity / 非同步影片溝通工具 | 跨職能溝通工具引用 |
| 6 | Sprint（Jake Knapp 2016）— 對委員會設計的時間箱對抗 | 既有觀察清單延續 |
| 7 | Conway’s Law / Fred Brooks — 委員會設計的學術原典 | 既有觀察清單延續 |
| 8 | 設計系統 / Design System — 規模化設計組織內的 adoption 反模式 | 建構為被採納 累積方向 |
| 9 | Information Architecture for organizational documentation — 中心化 findability 的學術深化 | 建構為被採納 累積方向 |
| 10 | OKR vs guiding principles — 兩種「組織方向定錨工具」對位 | 指導原則 累積方向 |
元觀察：vault 中 mini-series 完整 ingest 的範本價值
本次達成 vault 中第一個完整 ingest 的 mini-series + companion 4-source cluster：
- Ep1：啟動三步驟
- Ep2：中期信任 + 衝突
- Ep3：迭代 + 開發 + 交付
- 懶人包 PDF：所有 9 個工具的可填表伴侶
→ 該 cluster 累積至16 個相關 wiki 頁 + 4 個來源頁，是 vault 內最高密度的單一主題 cluster。pipeline 視角：未來遇到 mini-series 來源時，可參考此**「完整 ingest + 工具版伴侶」**範式——影片 + 配套 PDF 同主題並行，互補不重複，建立完整生命週期 umbrella。
原文（可選）
YouTube 影片逐字稿（使用者直接貼入；含明顯 ASR 錯誤；保留原文以利長期保存，wiki 摘要段已修訂）。
恭喜你終於撐到了最後一集，學校沒交的跨團隊合作術第三集，這一集我們要講設計別袋的時候，你到底要如何做跨團隊的溝通。那第一集的時候呢，我們介紹了專案剛起步的時候，方向很不明確的時候，你到底要怎麼樣做跨團隊溝通，怎麼樣去收編收買你的利害關係人。那第二集的時候呢，我們講到了如果你是半路空降，然後呢在一個人多嘴雜，多頭馬車的這個專案的話呢，你到底要怎麼樣去處理團隊之間的衝突啊，邊緣的專案的方式，然後呢如果你這兩集都還沒看的話，拜託拜託暫停暫停立刻暫停，重複的梗一直在用，先去把前面的兩集看完，你才可以得到最大最大的功效。然後呢真的這一次佛心來著好不好，超級佛心，我們這三集講到了說有溝通策略、模板、然後心法、各種只要跟跨團隊溝通合作有關係的，都已經打包好然後放在了影片的資訊欄裡面了，所以呢趕快去下面點連結，那你就可以直接得到這一包非常豐富的懶人包，下一次跟利害關係人呢處理這些有的沒的心臟BAD的時候呢，就把Blair這包懶人包呢打開看一下，哎呀原來還有這些方法可以用啊，那就拿來試試看，希望就是對大家都有幫助囉。那然後今天這一集呢，就要教你們設計接待的時候，甚至到開發的時候，到底要怎麼做團隊內或是跨團隊的溝通。
好然後呢一樣跟前面兩集非常的像，我們進入我們正題以前呢，我都希望教給大家一個心態好不好，這一集的心態呢就是直到你的設計被驗證以前，它都只是你的假設或是假說。你要推廣這個心態給利害關係人才對，他們提出來的意見，在他們有辦法驗證以前，也只是他們的假說。這一個心態呢，我認為應該要共同的分享給所有跨團隊一起做產品的人。
好今天第一個主題呢，就要談到委員會設計啦。那委員會設計這個詞呢，其實是非常非常經典有名的設計師Sir Alex Issigoni，他是Mini Cooper的設計師。他提出了這一個委員會設計這個詞，他就曾經說過呢，駱駝就是委員會設計出來的馬。到底是什麼意思呢，什麼駱駝什麼馬，那其實說不定呢，正在看影片的你，也曾經遭遇過委員會設計，所以我們今天就一起來看看這個到底什麼樣的情況。那我在marketuniverse.com找到這一個很好笑的漫畫，大概講了一下委員會設計，通常會產出什麼樣的設計產品。當設計師呢，每次就出一個想法，就是會有會議裡面有一些人呢，根據自己的喜好啊意見啊，想要來更改你的設計稿，然後呢最後專案的成果呢，就是一事無成，產到一個讓人家無法直視的狀態。那接下來這個漫畫呢，就用一個非常幽默的方式，寫出了設計師的心聲，是不是呢，你也曾經這樣子在會議裡面，尤其是設計評審會議的時候，發生這種事情。好像就是會有幾個人突然冒出來說我覺得這個顏色太無聊了，可不可以加一些這些顏色，或者是呢我覺得我們沒有好好的就是利用我們現在這個版位，不如就加五個促銷banner在那邊吧。然後呢好像他們提出來的產改這種理由都不是理由。
好啦那想必從這兩個漫畫中呢，你也大概猜到了委員會設計的定義。就真的當一個專案出現了非常多人都被忙碌在裡面的情況的時候，如果呢又缺乏一致的計畫或是看法，這個時候呢委員會設計可能就慢慢的正在產生了。但是身為精明的設計師的我們，我們到底要怎麼樣知道，未卜先知，這個專案正在被委員會設計呢。那其實委員會設計呢有幾個徵兆，大家可以參考看看。第一個徵兆呢，就是這個專案是不是設計師他們本人可能是比較不敢發聲，比較願意做出很多妥協的情況。或者是呢設計師本身的個性呢，或是團隊裡面有些主導設計的人，他的個性是比較希望避免衝突的，那這種時候很可怕，委員會設計很有可能會發生。
那第二個辨認方法呢，就是如果你發現這個專案好像很多的會議，然後可是會議之後好像都沒有達到什麼共識，然後呢不斷的開會，不斷的討論，但是又是沒有共識。
那第三個我會覺得稍微就是馬後炮的辨識法，就是你專案做完之後，回去看看這個專案的成果，是不是離原本預期的成果差距的非常遠。那如果差距非常遠的話，很有可能就是在整個專案進行當中呢，也有一些委員會設計的情況出現。
好首先第一個，設計師無止盡的妥協。剛開始入行的時候，那你都是懷抱著夢想理想，我們這一群用設計改變世界的人，所以你都會寫技方綱的，然後呢一頭熱血的加入你的公司。那這個公司呢，萬一又剛好是DX文化比較不成熟的時候，你就一天到晚在吵架，在捍衛你的使用者。然後呢你可能就會發現，欸奇怪，好像天天吵架，天天捍衛使用者沒什麼用欸。好像大家還是一副要聽不聽的樣子。然後呢身為設計師，你開始覺得，欸不行不行，我這樣子呢可能不太好合作，然後呢推動這些UX的概念，可能也不是這麼有幫助。我還是定調以團隊想要的東西為主好了，所以你就發現了團隊合作的重要性，然後就漸漸的一直在妥協，一直在妥協，一直在妥協。你心裡的妥協面積越來越增加，最後怎麼堅持都沒有了。好像就是欸，厲害官員說要改什麼就改什麼，今天說要改什麼就改什麼。最後搞得好像我是誰，我在哪裡，我在幹嘛，我為什麼要做這個工作，我好像只是一隻手，然後別人有很多個腦在那邊控制你的設計成品。
那接下來的階段，你就慢慢的找到一個中庸之道。你從兩邊的一個非常多妥協，然後另外一個非常不妥協的極端，慢慢的找到中庸之道，說到底哪些東西可以讓步，哪些東西不能讓步。你就漸漸的找到一個範圍，然後呢成為一個剛柔並濟的設計師。所以我其實曾經也是那一個大家對我的設計直來直去，然後呢我為了團隊好，為了大家寫作上面非常的容易，他們講什麼，我就做什麼給他們看。那其實很多時候你的團隊成員，你的厲害官員，他們自己也不知道他們要什麼。那身為設計師，你如果還沒有站住自己的陣線，然後Hold住自己最後一個陣腳的話呢，其實很有可能你的價值是會越來越低的，你就沒有在成為顧好使用者經驗的那個最後一道防線。這個心態上的轉變是很重要的，哪些要過，哪些是可以妥協的。我覺得到最後會有一些人生上的零件吧。剛講過那麼多心路歷程的東西，到底要怎麼樣避免成為一直不斷在妥協的設計師。
那我覺得第一個很重要的就是避免當家藝。不要呢就是好像怎麼樣的厲害官員跟你給了什麼一點，就好好好你就答應你就答應你就答應，答應好像不是這樣用。那有些設計師是一昧的拿著UX原則或者是數據來壓人，那殊不知呢你的厲害官員，不管你拿了再多的數據，拿了再多的UX原則來說服他，他還是不會聽。那記得喔，我在影集的第一集呢，就有跟大家分享過到底要怎麼樣把你的厲害官員變成盟友，所以呢趕快回去複習第一集，看一下人家收編你的厲害官系人。
那所謂說呢，如果專案已經走到設計節在的階段了，他一直遇到那些給你很多奇奇怪怪回饋的人，請你一定要試著詢問他們為什麼會想要提出一些改動，請他們描述一件為什麼這對使用者來說是重要的，他們遇到的挑戰到底是什麼，想要解決的問題到底是什麼。另外呢，如果你發現這個回饋的給予的人呢，他似乎個人偏好非常的明顯，那你也可以在會議中呢，或者是其他呢非會議的時候，也詢問一下，有沒有其他人也感覺到一樣的挑戰的，那有沒有其他人呢是有其他的意見可以解決這個挑戰的，尤其是當時真的很明顯，他們的回饋就是太個人了。那你這時候就遇到招兵買馬，大家感覺好像是在為了把所有團隊成員意見納進來有沒有，但事實上其實就是為了擋，因為那個人非常個人化意見，非常偏頗的意見，就大家有沒有解決了這個問題啊，然後大家覺得我們遇到這個挑戰啊，那你們有沒有覺得除了他剛剛講的這個方法，還有其他方法。我覺得大問題提出來沒關係，很註定團隊合作的感覺，然後一方面呢也變相的擋掉了那個非常偏頗的意見。
然後另外一個第二的委員會設計的徵狀，就是好像整個會議大家都很多話想要說，大家超多意見的，然後到最後呢超多的意見，但是沒有一個解決方向，沒有一個方案的感覺。那遇到這樣的情況到底要怎麼解決呢，那解決的方法呢當然每一次會議以前，你就要有非常明確的目標過程跟結果。你這一次的設計評比會議，你到底是需要大家來解決什麼問題，然後過程會怎麼樣子，然後結果希望達到什麼樣子的共識，以及呢在會議之中呢也千萬務必持續的提醒厲害的關鍵人，任何爭動造成這個專案的影響。那這時候有人就會提出問題啊，那如果已經有共識的部分，如果這個時候就有人提出異動的話怎麼辦，所以設計師們千萬不要馬上變成刺蝟一樣，突然這樣好像是很防衛性的，就說欸我明明就有這個有共識，為什麼要提出來，千萬不要進入這種防禦模式，也不用怕因為他們提出了這個異動，而你只要開始顧左右而言差，這樣子顧前提，然後不想要面對這個異動的提出。其實這種時候你只要平心靜氣，然後呢穩住你的腳步，深呼吸一口氣，然後呢請回去看影集第一集就有提過的，專案的指導原則guiding principles，回去看一下提出來你們專案的目的、方法跟已知的事實。這種時候呢就做到了一個提醒的作用，欸這個厲害的關鍵人們，你們現在提出這些異動，好像其實跟我們專案的原本的目的，其實沒有很相關，那我們是不是就可以先把這樣的異動放在一邊，這樣子團隊持續推進的時候呢，才不會有被耽擱的機會嘛。
雖然說你拿出了這個上方寶劍guiding principles，你的專案的指導原則，當然你還是要有保持著靈活的一個態度，你不要就是直接拿這份指導原則說我明明就寫這樣，明明那時候的目標跟已知的事實就不是這樣啊，我們就應該follow這個我們指導原則，不要不要不要。其實可以直接提出來說，欸各位厲害的關鍵人們，我們現在有沒有遇到哪些挑戰，是我們專案的指導原則已經不太適用的。例如說欸我們現在討論的東西，到底對我們的專案的最終目標有沒有貢獻啊，或者是我們使用的方法是不是需要改變了。然後呢也可以再評估一次說，欸現在專案走這麼久以來，這專案掌握的已知事實到底有沒有改變了。那如果說有改變，那大家就只好回去好不好，大家再重新達成一次共識，我們最後這個專案的指導原則到底是哪些。如果發現說厲害的關鍵人提出的，跟這些指導原則的都沒有需要改變的地方，你就可以理直氣壯的直接說，就是跟我們專案的指導原則真的都沒有關係的話，那大家請就是繼續往會議的議程前進，不要再被一些行使的異動給耽擱。
好最後一個徵兆有點馬後炮，但是呢如果發現設計的成果不如預期，很抱歉，你的專案真的很有可能已經被委員會設計殺掉了。專案結束的時候也是一個非常好做整個團隊檢討的時候，請你們一定要做一個回顧，回顧這整個專案執行過程中是不是有哪一些專案的指導原則已經偏離了，但是沒有人拉回來。或者是有沒有對於一些專案的事實掌握不足的部分。那事實掌握不足的部分例如說，會不會是原本你的PM可能以為說推出更多客製化功能可以避免客戶流失，結果發現事實上應該是整合功能的不足導致了客戶流失。那當然你再怎麼樣客製化，你的客製化的設計弄得再好，沒有用嗎？所以務必在專案結束的時候，你們產品終於推出去的時候，馬上就跟所有你的核心團隊或是跨團隊都一起做一個反省檢討的會議。
好像剛剛都會講到一個在他設計評審的時候、設計迭代的時候會發生的事，他從迭代到開發完成之間到底還會發生什麼事呢。很有可能就是開發的時候，工程師突然slap你一下，Houston, we have a problem。This is Houston. Say again, please. Say again, please. 比較常遇到的情況可能就是工程師跑來跟你說一些壞消息，我們這個API的後端的工程團隊，就是這個機好像生不太出來，所以就是有些流程上需要改動的部分。例如說負責做這個API出來的後端工程師，可能做出這個東西需要超出預期的時間，那就沒辦法做出你設計師想要的理想的樣子。或者是有哪些common cases或是edge cases，整個團隊之前都沒有考慮到，想得再周旋都難免會有疏失。
這種時候其實設計師也應該要保持彈性，運用各種方法來確保你們新需求都有辦法順利的溝通，然後達到共識。例如說你馬上就是旁邊直接拿一張面紙，然後開始畫可行的解決方案，或者是白板討論，或者是直接用機保針的方式去討論達到共識，其實都是非常有效率的方法。如果說在開發過程中工程師特別對於你的視覺或是互動上面有一些疑問，身為設計師你也是保持彈性，腳步快跑，運用你的原型工具在展現你的視覺跟互動，讓你的工程師馬上就可以瞭解到，原來你的腦子裡是這樣子想，你的互動是想要這樣子做的，馬上讓他們瞭解到你想要的理想效果。這個時候你原本設計疊在後期做好的高敏真的原型就非常有用，因為你只要拿那個設計稿當成基底，然後疊加在上面你的所有其他細節的互動微互動視覺等等都非常快速。畢竟不是每一個跨團隊的夥伴，都這麼習慣的自己去點擊那些原型。而且這時候設計也可以更保持靈活保持彈性，你可以直接在團隊的Slack Channel裡面直接錄一個輕便小巧的Disc檔來展示你想要的互動效果，或者是用Zoom之類的這種軟體，然後一邊螢幕錄製你自己想要的互動效果，然後一邊講解。那我自己也都實測過這些方式，他們都是非常跨團隊友善的方法，畢竟真的不是每一個人都這麼有耐心的一個一個去點擊，然後看你的互動到底是怎麼做的。
當然專案在進行的時候，設計師們你一有時間就趕快把你所有的相關的進行的一些討論跟最後的決策都全部都記錄起來是最好的。有時候在設計解答的時候，因為一個小小回饋，我們就要重新再提出探索可能四五種不同的設計解方，那這種時候拜託你一定把這些探索跟他們為什麼會被採納跟不採納的理由全部都記錄起來。所以這樣子的一個設計專案的文件可能就包括了你的核心問題、你的設計研究方法、你的專案目標、利害關係人有誰、還有一些決策的記錄、也會包括了你這整個專案的指導原則、然後還有一些成功的指標有哪些。那當然你做過或者說跑圖工作坊，以及你在中間嘗試過的方案、採納的理由不採納的理由，然後到最後最終方案，當專案結束的時候，一定要把它記錄起來。那你可能也發現沒有錯，當你好好的在記錄這些東西的時候，之後求職的時候，放在你的作品集上面也會更容易更輕易的一舉，才不會等到要做作品集的時候，熊熊想不起來，我的天啊那個專案到底做了什麼東西，然後接待過哪些方法，完全記不起來。所以你在專案執行的時候就好好的記錄這些東西，然後順便也把這些決策過程都是共享給說團隊成員看的，都是一個非常好幫助團隊達到共識的方法，或者是說達到共識之後避免再有任何異動的方法。
好然後最後，專案終於推出總決心，已經作品都做好了，然後你就要ship出去了，專案終於結束了，等一下，就是還沒有那麼早開心，專案結束的時候有一個非常好的心態就是play for adoption not handle。你在寫這份專案結束的時候的文件，你心裡其實要想著adoption，到底誰之後會來看這個文件，然後他們還需要哪些額外的資訊，可能是你本身就已經內化的資訊，你已經知道了，但是當一個之後半空降進來這份文件的人，可能就完全不知道你到底播出的脈絡是什麼，然後有哪些資訊是非常瑣碎斷片的，是可能他們不會知道的東西。然後另外很多時候組織的問題並不是員工不寫文件不記錄或是不保留文件，而是他們缺乏了一個中心化的地方來讓大家可以找到查閱所有的文件。所以去思考你的文件的架構，它在整個公司裡面到底要被放在所有公司文件裡面的哪一區，這是非常重要要考慮的事情。
然後總結一下這三集以來設計師的小小工具箱。第一集我們講到了，其實就是及早掌握你的厲害觀點，掌握你的專案指導原則，以及靈活運用工具，然後保持一個開放的心態，以及最最最最最重要的，就是帶著你的團隊一起見證UX所帶來的好處。只有等你自己知道UX的好處，然後其他人不買單，那是沒有用，所以一定要記得帶著團隊一起跑。你一個人雖然跑得非常快，但是帶著你的團隊一起跑，才會跑得久跑得遠。這個就算是一些來長慶公司裡面的一些心法教給大家。不要忘了，如果這個影片有用的話，趕快按個讚訂閱留言分享出去。好拜拜。
MING PAO CANADA // MING PAO TORONTO