學校沒教的跨團隊設計合作術 Ep2：人多嘴雜專案就要用『團隊信賴公式』！
後設資料
- URL：https://www.youtube.com/watch?v=jiwdIt5oHsU
- 頻道：Unblock
- 主持人：Blair
- 集數定位：Unblock「跨團隊設計合作術」迷你影集第 2 集（共 3 集；對應頻道 Ep16）
- 上集：2026-05-03-Unblock-跨團隊設計合作術-Ep1
- 內容形式：YouTube 影片（口語講解 + 投影片）
- 語言：繁體中文
- ASR 來源：YouTube 自動字幕（含明顯辨識錯誤；wiki 摘要段已修訂）
一句話濃縮
當你中途加入已經人多嘴雜的混亂專案時，靠 Trust Equation 信任公式 主動建立互信、用 RACI 釐清角色、用 I-Statement 化解會議衝突、用 HMW / Crazy 8 / QOC 工作坊把意見導入創造性出口——而最該牢記的元命題是「共識與信任都是人工後天被創造出來的」。
提取要點
元命題
「共識與信任都是人工後天被創造出來的。」 —— Blair
→ 這條元命題是 Ep1 + Ep2 共同的精神基底——把「靠默契自然形成共識」這個浪漫想法戳破，逼設計師承擔主動製造共識的責任。
三階段架構
| 階段 | 主題 | 核心工具 |
|---|---|---|
| 1 | 準備：建立互信 | Trust Equation 信任公式 + 微貢獻 + 1-on-1 + 不妄想改變對方 |
| 2 | 衝突處理 | RACI + 主持會議的小技巧 + I-Statement |
| 3 | 形塑共識的工作坊 | HMW / Crazy 8 / QOC |
階段 1：準備即建立互信
Trust Equation 信任公式（出自 The Trusted Advisor）
信任 = (Credibility 確實性 + Reliability 可靠程度 + Intimacy 熟悉度) / Self-Orientation 自我利益導向
| 變數 | 含義 | 設計師預設值 |
|---|---|---|
| C Credibility | 你說的話可信嗎？專業是否到位？ | 言出必行的設計師通常已具備 |
| R Reliability | 你說到做到嗎？穩定交付嗎？ | 言出必行的設計師通常已具備 |
| I Intimacy | 對方覺得跟你熟、安全可揭露擔憂嗎？ | 是設計師最弱的一環，要主動經營 |
| S Self-Orientation | 你溝通時是不是只繞著「我自己 / 我的專案 / 我想要的東西」？ | 是分母——越大越扣分；要主動降低 |
降低 S 的具體做法：
- 不在對話中老是提到自己的利益、想法、想要的東西、自己的專案
- 把對方的立場擺在心上——句法主詞 / 受詞改用「你 / 我們」而非「我」
- 讓對方覺得你是在為他著想
中途加入專案的 3 個快速建立信任手段
- 微貢獻（micro-contributions） — 迅速幫利害關係人解答小問題、處理 5-10 分鐘可清掉的疑難雜症
- 定期 1-on-1 + check-in — 5 / 10 / 15 分鐘都行；目的是增加見面頻率而非長度
- 元紀律：沒有誰想要改變誰 — 別妄想改變利害關係人；雙方健康激盪出新點子才是健康的合作關係
階段 2：衝突處理
工具：RACI 矩陣
當「不理解每個利害關係人的立場 / 態度」時，用 RACI 把每個人分成 4 類角色，會比影響力與利益矩陣更精緻。
| 字 | 全稱 | 對應角色 |
|---|---|---|
| R | Responsible for completing the work | 設計師 / 工程師 |
| A | Accountable for delivering the work | PM / PO |
| C | Consulted about the work（影片 ASR「Complicated」誤） | 其他設計團隊成員 / 設計系統人 / 研究員 |
| I | Informed about the work | 小主管 / 大主管 / 設計總監 |
Blair 的使用建議：「如果專案不是大影響範圍時，這個模型我自己是覺得幾乎天天都會用到。」
→ 跟 影響力與利益矩陣 對位：影響力矩陣是溝通策略選擇（高/低互動頻率）；RACI 是責任歸屬釐清（誰做、誰扛、誰被諮詢、誰被通知）——兩者軸不同但常被一起使用。
1-on-1 訪談的紀律
不管用什麼方法（一對一面談 / 電話 / Zoom），一定要 1-on-1，沒有其他人在場時對方才會清楚說出對專案的擔憂——尤其是他平常在其他利害關係人面前不會透露的事情。
主持會議的小技巧
| 場景 | 動作 |
|---|---|
| 強勢的人佔用太多時間 | 掌控會議節奏，主動切回討論方向 |
| 安靜的人沒發言 | 主動邀請貢獻意見 |
| 高職等的人丟一句評語就走 | 務必請他多解釋想法，避免團隊「揣測上意」把專案帶偏 |
| 有人把已達共識的部分翻出來重炒 | 提醒這部分已決議 |
| 有人提完全不在專案範圍的點子 | 指出資源有限，不要硬提範圍外的天馬行空——「從某角度看是不尊重設計師與團隊成員的時間」 |
I-Statement vs You-Statement（Thomas Gordon）
來自美國臨床心理師 Thomas Gordon；廣泛運用於教育、育兒、親子、職場。
範例情境：喬治先生前半場會議沒到，現在突然提出整個專案的修改。
You-Statement（指鼻子型）：
「你前半場會議不在，所以沒有參與到討論；現在重新討論可能來不及，但我們先把注意力放在當前項目吧。」
→ 暗示「是你晚到、是你的錯」；對方感受到被攻擊。
I-Statement（負責任型）：
「這部分可能因為你前半場會議少了你的 input，所以有些地方我們沒有納入到你的考量。不過如果我們再回去討論這個項目，會影響今天預定的進程；如果會議結束後和你另外 catch up前面討論的項目如何？」
→ 把「沒納入」說成「我們沒納入」（不是「你沒到」）+ 主動提出 catch up；願意傾聽對方並一起找解法。
衝突處理 3 大常見錯誤
- 想要改變對方的想法 — 結果對方想法只會越來越頑固、講不停
- 太想梳理講邏輯 — 忘了「對你有道理的事，未必對對方有道理」——你們可能用不同的邏輯看事情
- 忽略對方的情緒 — 衝突中的人情緒未被處理時，邏輯與資訊都進不去
「拖延」是合法的衝突處理工具
「我回去想一想，下週再給你們答覆」——
- 不是真的拖延設計決策
- 目的是給大家冷靜空間——吵得臉紅脖子粗時，主動喊暫停
- 下週很可能莫名其妙大家就一致附和（情緒平息後共識自動浮現）
Blair 的「服服帖帖 PM」案例（行為 ≠ 動機）
Blair 曾被一個 PM「收服得服服帖帖」。觀察該 PM 溝通模式：
- 永遠樂觀積極 + 對產品保持熱忱
- 聽到別人提案時，馬上一臉真誠地說「這個點子真的很好」+ 列出對方點子的所有優點
- 再順勢加上「不如我們試試怎樣怎樣怎樣⋯」——即使新方向跟對方原案「八竿子打不著」
為什麼有效：對方覺得意見被聽到、被肯定 → 願意接受導向新方案。
→ 給設計師的應用：在設計回饋會議遇到「很佳很佳」的提案時，先列對方優點再順勢導向更好的方向，能維繫互信。
階段 3：形塑共識的工作坊
推薦 3 個工作坊活動
(a) HMW (How Might We) — 「我們可以如何…」
把問題層次拉高、回歸本質。
Blair 的 onboarding 案例：
利害關係人 1 主張「用 video 配 Q 操作」；利害關係人 2 反對「影片又瘦又長沒人看」；利害關係人 3 主張「用動畫微互動讓使用者直接看到功能」——三人在「功能性的低階討論」打結。
用 HMW 重塑為：「HMW 在最短時間內讓使用者學到我們最主要的產品功能，並降低之後使用的阻力？」 → 把問題從「用什麼工具」拉高到「要解決什麼」。
(b) Crazy 8（出自《Sprint 設計衝刺》）
8 分鐘畫 8 個解決方案——
- 用「10 倍 3A」（影片 ASR；推測為 10x A3 紙）的時間箱限制，逼利害關係人開闊思維
- 「帶你的利害關係人一起飛，飛到一個他們以前沒看過的世界的高度，跟你一起俯瞰這個世界」
- 不要拘泥於工具——不擅長白板的人就讓他畫紙上拍照，重點是用最舒適的方式貢獻
(c) QOC (Questions, Options, Criteria)
原本是設計師思考解決方案的工具，但 Blair 發現也適合用在跟利害關係人腦力激盪的工作坊中——
- Q（Question）：這個方案到底解決了什麼問題？
- O（Options）：除了這個方案，還有哪些其他選項？
- C（Criteria）：用什麼指標衡量這些選項？
→ 教利害關係人自己問自己——把判斷權還給對方，避免你扛全部決策成本。
收尾：設計師應培養的 3 種能力
「在跨團隊合作裡，最重要的設計師實力要點：」
- 衝突紛爭解決的能力
- 團隊政治覺察的能力
- 高 EQ — 應付別人對你的回饋 + 應付團隊中情緒不滿 / 政治立場不同的衝突；設計師必須想辦法幫忙團隊解決
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
- 信任公式 — 本來源新建：Trust Equation；vault 第一個 trust framework 概念頁
- RACI框架 — 本來源新建：Responsible / Accountable / Consulted / Informed 角色分類；vault 等待已久的標準框架
- 我訊息 — 本來源新建：I-Statement vs You-Statement；Thomas Gordon
- 衝突管理 — 本來源新建：umbrella；3 大錯誤 + facilitator playbook + 拖延戰術 + 行為 ≠ 動機案例
- 利害關係人管理 — 更新：Ep1 建立的三步驟（鑑識 / 計畫 / 工作坊）擴充為「Ep1 啟動期 + Ep2 中期信任建立 + 衝突處理」完整生命週期；補入「共識與信任是人工後天創造」元命題
- Unblock — 更新：跨團隊設計合作術迷你影集第 2 集 URL 補入；持續累積 Blair 的 in-house 設計師工法線
- How-Might-We — 更新：補入「利害關係人工作坊」的應用脈絡（先前只有設計思考 Ideate 階段引用）
- 活動理論 — 既有概念對位：Blair 的「行為不一定等於動機」案例（主管打槍 = 行為 / 想被聽到 = 動機）是活動理論的職場政治場景版
- 影響力與利益矩陣 — 與 RACI 形成對位：溝通策略 vs 責任歸屬，常一起使用
- SBI溝通術 — 與 我訊息 同 cluster：兩者都是「結構化句型」家族（SBI 給 feedback / I-Statement 處理衝突）
- 原則性談判法 / 把人跟問題分開 — 「忽略情緒就吵不出結果」對位「先安頓情緒、再進入議題」
- 認知失調 — 「想改變對方只會更頑固」對位「千萬不要跟認知失調為敵」元命題
- 顧客旅程地圖 — 影片開頭推薦觀眾去看「鍋子的旅程地圖」（推測為頻道 link）
Ingest 筆記
本次 ingest 是 2026-05-03-Unblock-跨團隊設計合作術-Ep1 同日續 ingest——使用者連續貼入兩集逐字稿；本集是迷你影集中段，主軸從「啟動期收編利害關係人」轉到「中期信任建立 + 衝突處理 + 共識工作坊」。
ASR 修訂（不窮盡）
- 「藏能教 / 學藏能教」→ 學校沒教
- 「孕婦旅程地圖」→ 顧客旅程地圖
- 「鍋子」→ 推測是頻道 KOL / 合作對象暱稱（影片開頭推薦觀眾去看的「旅程地圖專家」）
- 「軍中協調者」→ 居中協調者
- 「智能扣」→ Zoom（視訊會議軟體）
- 「Bingo Bingo Bingo」→ Blair 自承台語不準，原意應為台語「打架/吵架」相關詞（「相罵」/「對杠」）
- 「跳鐵人」→ 推測為「仲裁者 / 居中調停者」
- 「Eye Statement」→ I-Statement / I 訊息 / 我訊息
- 「New Statement」→ You-Statement / 你訊息
- 「Complicated about the work」（RACI 中的 C）→ Consulted about the work（諮詢；不是「複雜」）
- 「How about me」→ How Might We（HMW）
- 「Crazy A 瘋狂吧」→ Crazy 8（設計衝刺工作坊活動）
- 「自營設計衝刺」→ 《Sprint》（Jake Knapp 等人 2016 出版，Google Ventures / GV 提出的設計衝刺方法）
- 「103A 侷限」→ 推測為「用 A3 紙」或「10 分鐘限制」之一；無法精確還原
- 「GMOC」→ QOC（Questions, Options, Criteria）
- 「揣測上意」→ 正確（成語）
- 「服服帖帖」→ 正確
- 「八竿子打不著」→ 正確（成語）
- 「影畫團隊」→ 跨團隊
概念抽取的判斷
為什麼 衝突管理 獨立成 umbrella，而非掛在 利害關係人管理？
- 利害關係人管理 是「啟動期 + 中期經營 + 工作坊收編」的全生命週期 umbrella
- 衝突管理是其中特化場景（會議衝突 / 多方意見不合）的方法論集合——含 3 大錯誤、facilitator playbook、I-Statement、拖延戰術、行為≠動機案例等多個獨立工具
- 兩者關係：利害關係人管理 是 stakeholder 全週期 / 衝突管理 是「多人意見衝突」的處理工具集——後者也適用於非 stakeholder 場景（純內部會議、家庭、伴侶溝通）
- → 獨立成 umbrella 有利於跨場景累積（家庭 / 親子 / 商務談判等其他來源）
為什麼 信任公式 獨立成頁？
- Trust Equation 是 The Trusted Advisor（David Maister 2000）提出的廣泛被引用的單一公式，獨立性高
- 公式裡每個變數（C / R / I / S）都可以單獨被討論、被加強——是「單一公式 multi-variable」型概念，最適合獨立成頁
- 未來若 ingest 顧問業 / B2B sales / 醫病溝通 / 律師客戶關係等其他來源，都會引用這條公式——獨立頁有利累積
- 兩者軸不同：影響力矩陣處理「怎麼跟人溝通」；RACI 處理「誰做誰扛」
- RACI 是 PMP / Scrum / 大型組織協作的通用工具，獨立性極高——比影響力矩陣更常被獨立引用
- 兩者常被「一起使用」但不該「合併成一頁」
ingest 過程中發現的既有預備頁面：本次 ingest 開始時發現 vault 已有兩個未追蹤的 wiki 頁——[[信任公式]] 與 [[RACI框架]]——皆為他場 session 為一個尚未 ingest 的 [[2026-05-03-Unblock-跨團隊溝通協作懶人包]] 來源預備的草稿。內容紮實、與 Blair 影片版本一致，且帶有原創分析（如 信任公式「4 變項時間尺度差別」、RACI「A 必須唯一」紀律）。處理方式：保留既有內容、補入 Ep2 來源連結、在備註說明來歷與懶人包待 ingest 狀態。本次 ingest 由我新建的只有 我訊息 與 衝突管理 兩頁。
- I-Statement 是 Thomas Gordon 1970s 提出的獨立廣泛被引用的句型工具——衝突管理只是其應用場景之一
- 育兒、伴侶溝通、教師對學生、跨文化溝通等都用 I-Statement
- 與 SBI溝通術 是「結構化句型」sibling（SBI 處理 feedback / I-Statement 處理衝突）
為什麼 Crazy 8 / QOC 暫不獨立建頁？
- Crazy 8 是設計衝刺（Sprint）方法論的子工具——目前 vault 沒有 Sprint 主頁；單獨建 Crazy 8 會孤兒化
- QOC 是 Maclean et al. 1991 提出的設計理據（design rationale）工具——本期是首次入 vault，密度不足
- 兩者進觀察清單——觸發建頁條件 = 累積到 Sprint 完整方法論 / QOC 第二份來源 ingest 時
對 利害關係人管理 umbrella 結構的擴充
Ep1 建立的 利害關係人管理 三步驟（鑑識 → 計畫 → 工作坊）對應的是啟動期——從 0 到收編完成。Ep2 補入：
- 中期信任建立：靠 Trust Equation + 微貢獻 + 1-on-1 拉長時間軸
- 衝突處理：當會議出現多方衝突時的 facilitator playbook（→ 連結到新的 衝突管理 頁）
→ 完整 stakeholder 生命週期：啟動（Ep1 收編）→ 中期（Ep2 信任維護）→ 衝突峰值（Ep2 衝突處理）→ 共識凝聚（Ep1+2 工作坊）。
觀察清單
| # | 待 ingest 項 | 來源 |
|---|---|---|
| 1 | Unblock Ep17（迷你影集第 3 集，實作工具） | 本影片預告 |
| 2 | The Trusted Advisor（David Maister 2000 書）— Trust Equation 出處 | 本影片提及 |
| 3 | Thomas Gordon 親子效能訓練（PET）方法論 — I-Statement 系統來源 | 本影片提及 |
| 4 | Sprint 設計衝刺（Jake Knapp 2016）— Crazy 8 出處 + GV 設計衝刺整套方法論 | 本影片提及 |
| 5 | QOC 設計理據 / Design Rationale — Maclean et al. 1991 | 本影片提及 |
| 6 | RACI 的延伸版本 RASCI / DACI / PARIS / CAIRO 等變體 | RACI 入庫後可累積 |
| 7 | Blair 推薦的「鍋子的旅程地圖」 — 推測是台灣 UX 圈 KOL 影片 | 本影片提及 |
| 8 | 設計師的「團隊政治覺察」能力 — Ep2 收尾提到但未展開 | 本影片提及 |
原文（可選）
YouTube 自動字幕逐字稿，含明顯 ASR 錯誤；保留原文以利長期保存，wiki 摘要段已修訂。
歡迎大家回來學藏能教的跨團隊設計合作組第二集 上一集如果你還記得的話 我們介紹了在一個專案 當起步沒有特別有人在領導整個專案進駐的時候 有什麼樣子的溝通策略 可以開始收買收編你的厲害關係人
如果你還沒看完第一集的話 記得先趕快現在暫停 現在按暫停 回去看第一集 再來看第二集才會有最大的功效 你才會知道我這整集到底在講什麼東西 好不好 我求求你回去 回去看第一集
還有一個小插播 第一集提到一點點的孕婦旅程地圖 那當然鍋子就是我們的最厲害的旅程地圖的專家 所以大家趕快去點點進去鍋子的旅程地圖 好不好 去 那我們再來看第二集
到底人多嘴雜 多頭馬車 你到底要怎麼樣處理這些各種不同的意見跟衝突 今天這一集一樣分成大約三個階段 首先是專案的事前準備 再來衝突處理 以及最後一個步驟 你到底要怎麼去形塑整個團隊的共識 那我們就開始吧
先給大家這一句話非常重要 我希望所有設計師都可以記得 這就是共識與信任 它們都是人工後天被創造出來的 記得這一點
第一個階段準備即建立互信 那這邊呢 互信大家常常會覺得好抽象 到底是什麼東西 在一個Trusted Advisor 這本書裡面 這本書提出了一個信任公式 一個人值不值得信任 包含了四個面向 確實性credibility 加上可靠程度reliability 加上熟悉度intimacy 處理你這個人的自我利益導向 self-orientation
所以說呢 假設各位正在收看的觀眾 你都是言出必行的設計師 你說到就會做到好不好 那你就會發現了 在這個公式裡面 其實credibility跟reliability 你已經有了 那你最重要的就是 加強你與利害關係人的 熟悉度intimacy的部分 以及溝通策略中 你必須降低你的自我利益導向 self-orientation
這個self-orientation 可能聽起來有一點點抽象 那其實就是你跟對方在溝通的時候 降低你自己一直提到 你自己的利益 你自己的想法 你想要的東西 或者你的專案 把對方的立場擺在心上 然後你的溝通策略 甚至是你的句法語句 到底要怎麼樣去傳達 這個主詞這個受詞 到底是誰聽起來 會讓對方更覺得 你是在為他著想 那就是想辦法用這樣的溝通策略 去和你的利害關係人溝通
假設你是突然衝向到一個團隊裡面 你到底要怎麼樣 短時間抓住你利害關係人的信任感 那我這邊提了兩個辦法 它還有一個新法 可以想辦法幫你的利害關係人 快速的產出一些微型的貢獻 例如呢 迅速幫他們解答一些問題 迅速幫他們處理一些 比較小型 快速就可以解決掉的一些 工作上的疑難雜症 這樣子其實慢慢的 對方就會開始對你累積一些信任感
再來呢 就是一定要有一些定期的 1-2-1 以及定期的check in 其實都不用長 5分鐘 10分鐘 15分鐘都可以 增加了他看到你的頻率 這些都是快速的提升熟悉感的方法
然後呢 最後有新法送給大家就是 沒有誰想要改變誰 你不要妄想著 你可以改變你的利害關係人 或是你的利害關係人可以改變你 事實上呢 是不斷的雙方健康的激盪中從的點子 這才是健康的合作關係
那假設呢 這些人知道原則好像都出來了 但是就是這些利害關係人 好像是怎麼樣都沒辦法達到共識的時候呢 那這時候身為設計師呢 你可能就要開始擔任一個 比較像是軍中協調者的角色 那你可以透過很多不同的方式 來做利害關係人訪談 不管是一對一啊 電話啊 智能扣啊都可以 但是有一點非常重要的就是呢 不管用什麼方法 一定要記得你要 一對一的和那個人聊 這樣子呢 沒有其他人在場的時候 他可能才會更願意清楚他所有 對專案的擔憂 特別他平常在其他利害關係人面前 不會透露的事情
好 那如果呢 在你不理解每一個專案的 利害關係人的立場的態度之後呢 他也可以用另外一個模型 叫做RACI 來分類這些利害關係人 這個RACI 其實代表的就是 不同語文部會受的這些類別 R是 Responsible for completing the work 以一個專案來說 通常就可能是設計師 或是導工程師 或是工程師 A是 Accountable for delivering the work 那可能就是PM或是PO 那C呢 就是Complicated about the work 可能是其他的設計團隊的成員 或是比賽系統的人 或是一些研究員 那再來I呢 是Informed about the work 那有可能是你的小主管大主管 或是甚至設計總監 這個模型它跟前面第一批提到的比起來呢 稍微這個就比較精緻一點 如果說你的專案想要推動的東西 並不是這麼大影響範圍的時候 這個模型我自己是覺得 很天天都會用到的東西
等級的第二個重點 有時候你自己已經都跟利害關係人 關係打得好好的 他們都被你收買了 但是他們利害關係人之間 在會議臺是一路要跑起來 要Bingo的樣子 Bingo Bingo 好啦 我臺語真的非常差 完全不知道發的準不準 他們都快要跑起來的樣子的話 要怎麼辦呢 你可能就要開始盡量的 幫他們化解一些衝突 然後當成一個居中跳鐵人
有一些處理衝突的小技巧 大概就交給大家 那首先呢 就是你可以開始掌控整個會議 然後掌控大家的討論 看一下是不是你哪一個利害關係人 特別的強勢 阻擾了大家的討論方向 或者是佔用了太多的時間 那當然你也可以主動的 請那些比較不敢發言 比較少發言的同事 稍微多貢獻一點意見
那如果呢 這個會議啊 有特別高職等的人在裡面 你務必請他們 多解釋他們的想法 跟多解釋他們的意見 畢竟他們職等很高 影響力非常的大 那如果呢 他們今天就是 非常嚴謹地 一開始丟了一個意見 或是丟了一個評語 整個團隊就需要 揣測上意這種感覺 有可能把整個專案都塞偏的
那當然呢 你也要注意一下 有沒有一些人是把 以前已經達到共識的部分 又一直拿出來討論的 或是一直出現 把不在專案範圍內的點 拿出來討論 好像是他們有很多補充點子啊 等等的 但事實上 如果是完全不在專案範圍裡面 其實 從一個角度來講 他們非常的不尊重 這個專案設計師 跟其他的團隊成員的時間
最後一個大招 教給大家 叫做 Eye Statement 這個方法 來自美國臨床心理師 據說 Thomas Gordon 他這個Eye Statement 已經被非常廣泛的運用在 教育現場啊 育兒啊 親子關係啊 職場啊 跟人討論的一群
那我們現在直接試試看 Eye Statement吧 假設呢 我的厲害關係人 有一位叫做 喬治先生 如果這個Eye Statement 聽起來可能會像這樣 喬治先生 你前半場會議不在 所以沒有參與到討論 現在重新討論的話 可能有點來不及 但我們先把注意力 放在當前討論項目吧
接下來呢 試試看Eye Statement 喬治先生 這部分可能因為 你前半場會議少了你的input 所以有些地方 沒有納入到你的考量 不過如果我們再回去 討論這個項目的話 今天預定的進程 那如果會議結束後 和你另外catch up 前面討論的項目如何
那前者呢 是使用New Statement 後者使用Eye Statement 那你是不是前者 就好像我在指的 喬治先生的鼻子 然後我們侮辱他說 欸是你晚到 你沒有參加到會議 現在還來這邊 提其他的議程異動 那第二句呢 就比較像是 祝我們沒有納入到你的考量 祝我們之前沒有 全部納入到你的回饋 我之後呢 另外和你catch up項目 馬上提出 願意傾聽對方 然後和對方一起 找到更多解決方法 或者是傾聽他們 更多的意見等等
那麼呢 大概的總結一下 到底設計師要怎麼樣處理 多人會議的一些衝突 那第一點呢 就是你可以重塑這個專案的 目標跟任務 那第二點呢 要緊記在心的就是 行為有時候不一定等於動機 有可能是因為 他其實是一個非常想要 參與這個專案的人 但是因為他是主管 之前呢 我們都只有納入了 他屬下的考慮 他其實非常想要 貢獻他的想法 所以呢 他會出現很多行為 好像是在打槍 我們現在的一些體感 但事實上他背後的動機呢 其實只是希望 我們可以多聽他的想法 把他想法納入進來 所以這樣子 一起參加工作坊的提議呢 其實馬上解決了 他心中的焦慮感 就是啊 他有被重視了 他的想法是有人聽到的 然後這個設計師 會傾聽出他的想法 那最後呢 當然是 當大家從柯開掉的時候 你可以看一下 有沒有AZ測試的可能性啊 或者是整個 各種不同方案的可能性 這個時候呢 還需要再運用 前面那幾種方法 去找到一個最佳解決方案
我們接下來提這個 常見的衝突管理的錯誤好了 那其實呢 你會發現 職場中衝突管理 其實跟個人平常的家庭啊 感情生活 其實蠻相似的
第一個呢 就是想要改變對方的想法 那不管是在 個人感情生活中 還是在職場中 你會發現呢 如果你無奈地 想要改變對方想法 就是說對方想法 只會越來越頑固 越來越講不停
第二個錯誤呢 就是你太想要梳理 講邏輯了 但是你忘記 對你來說有道理 有邏輯的事情 是不是跟對方 也有道理也有邏輯 你們完全在用 不同的邏輯在看事情
那第三點呢 最重要的 其實就是 忽略了對方的情緒
假設在會議裡面 大家為了順利解決方案 就是吵留課開交 事實上有時候呢 還有一個話術非常好用 就是我回去想一想 想到其他的方法 或者是我回去 再對這幾種方案 多仔細思考一下 下一週再給你們一些回答 其實這樣子呢 用意不是在這個拖延 你做設計決策的時間 其實也是給大家 稍微冷靜一下 讓大家吵得臉紅脖子粗的時候呢 稍微有人出來喊個暫停 那你會發現呢 很有可能 下一週莫名其妙 大家原本一直打聽的專案 莫名其妙 大家都一致附和 然後點頭說好了
有一次呢 在以前的工作崗位中呢 然後被某一個PM 收服得服服帖帖 他講什麼我都覺得 好好聽好聽的下去 當然這個拍子長得蠻帥的 但是這不是重點 這不是重點 這真的不是重點 我發現呢 在溝通過程中 他永遠都非常的樂觀積極 然後呢 非常的保持著 對產品的熱忱 那我就發現 有時候呢 所提出的一些點子或是見解 雖然可能是對於使用者是最好的 但是太操縱專案的時間啊 跟金錢預算 那我發現呢 他永遠都會 啊 這個點子很好 我覺得我真的沒有想過這個點 不如我們試著怎樣怎樣怎樣 那我就發現呢 有時候他提出的那個 不如我們試著怎樣怎樣怎樣 好像跟我提出的點子 就是八竿子打不著的關係的感覺
但我那時候是聽得服服帖帖的 有可能是因為是 聽到點子後 他會馬上一臉非常真誠的說 各位這個點子真的很黃 然後我馬上把我提出來的點子的優點 全部都先列出來 所以這個也是一個好方法 假設你在設計回饋的會議中呢 遇到一些厲害的關係人 提出一些很佳很佳的方法 很佳的方案 其實你也可以運用這個方式 那你就會發現 欸 那個厲害的關係人好像就覺得心滿意足 覺得他的意見被你聽到了 你看他就開始建立一個 很緊密的互信關係
好啦 第三個階段 實地操作的工作坊推薦 其實就是帶著厲害的關係人一起一杯 太ㄎㄧㄤ了 OK 那我這邊呢 我列了三個工作坊的活動推薦給大家 第一個呢 就是 How about me 我們可以如何 那第二個呢 是 Crazy A 瘋狂吧 第三個呢 是QOC
通常因為大家應該不陌生 像例如呢 我以前做一個專案的時候 我在做一個onboarding的專案 厲害的關係人彼此呢 已經開始丟出非常多不同的點子 厲害的關係人 一開始說 欸我覺得我們應該要用一個video 然後有一種Q操作之類的方法 讓大家馬上知道 我們的產品能幹嘛 表現出我們產品多厲害 厲害的關係人第一呢 就說 欸影片那麼又瘦又長 應該不會有人看嘛 然後厲害的關係人第二就說 欸我覺得我們應該要用一些動畫為互動啊 然後一些飛來飛去的東西 來讓使用者直接看到說 我們的那些功能到底在哪裡 所以呢這個時候呢 我們可以如何在最短時間內 讓使用者學到我們最主要的產品功能 然後降低他們之後使用的受益 那這樣子你會發現 原本討論的問題的層次 其實在非常低階的 都是在一個功能性的討論 在用了How about me之後呢 直接把這一個問題層次拉高 讓大家回歸到問題的本質
第二個 Crazy egg跟狂巴 相信如果你也看過 《自營設計衝刺》這本書的話呢 對於這個方法都不陌生 你用8分鐘的時間 讓你的厲害關係人 畫出8種不同的解決方案 用103A侷限 要嘛就是影片 要嘛就是微互動 開闊他們的思維是最重要的 你要帶著你的厲害關係人一起飛 飛到一個他們以前沒看過的世界的高度 然後跟你一起俯瞰這個世界 那就比較重要的就是呢 不要讓厲害關係人選一個 他最舒適最擅長的方式 假設厲害關係人就是不常使用 原本要寫作白板的話呢 那也可以讓他們就是自己畫在紙上 然後拍照 最重要的就還是呢 不要讓他們拘泥於工具上的使用 而是真的讓他們找到一個 最舒適自在的方式 來貢獻他們的想法
那最後一個呢 GMOC其實意思是 Questions, Options and Criteria 這一個方法呢 一直以來都是用在設計師 在想一些解決方案的時候 像我有一個問題 然後呢提出了一些解決方案 以及他如何用不同的方式 來衡量這些解決方案 但是後來呢我發現 其實這個東西蠻適合 運用在和厲害關係人 腦內風貌的工作坊中的 然後他們列出了一些解決方案 那其實很適合用來 教他們自己問自己說 這個方案到底是解決了什麼問題 那這一個問題呢 除了這個解決方案 有沒有一些其他的提案 以及用哪些方法 來衡量他自己批刻的這些解決方案
好那最後的這兩集 講了這麼多和厲害關係人的溝通策略 要如何處理的方式 最後呢我只是想要提醒大家說 有時候呢在影畫團隊的合作裡面 最重要的身為設計師 要來實力的要點 就是衝突紛爭解決的能力 第二個呢就是 團隊的政治覺察的能力 以及最後一個就是 身為設計師你一定要有一個 非常高的EQ 去應付別人對你的回饋 以及應付整個團隊中 如果有情緒不滿 或者是有政治上的立場 不同各種衝突紛爭的情況 身為設計師你必須想辦法 幫忙團隊解決
好那這就是我們 設計第二集的通文內容啦 希望你們有學到一些東西 這個影片一樣有時間 可以跟大家下載 那如果喜歡的話 不要忘記按讚訂閱按小鈴鐺 我們下次見