利害關係人管理

Properties2
tags狀態/草稿, 領域/ux, 領域/設計, 領域/管理
aliasesStakeholder Management, 厲害關係人管理, 跨團隊協作, 跨團隊設計合作, 利害關係人收編, Stakeholder Engagement, 利害關係人衝突處理

閱讀時間約 33 分鐘

利害關係人管理

一句話定義

在有多個利害關係人（stakeholder）的專案中，主動鑑識誰會影響專案 / 受專案影響、用差異化策略收編、靠信任公式維護中期關係、靠衝突管理化解多方衝突、靠指導原則對抗委員會設計、靠設計專案文件實現被採納 的 7 階段全週期工法——三條核心元命題：(1) 好點子被否決常常不是點子不夠好，而是還沒建立健康互信關係 / (2) 共識與信任都是人工後天被創造出來的 / (3) 一個人跑得快、帶著團隊跑得遠。

核心要點

1. 大原則：前期溝通成本 vs 後期改動成本

  • 產品最早期討論成本最低；隨時間推進，新意見納入時改動成本越來越高
  • 設計師「直接動手做設計、發表後才收意見」是把改動成本推到最貴的時點
  • → 前期溝通投資 = 後期改動成本的對沖

2. 全週期工法（啟動 → 中期 → 衝突 → 共識 → 迭代 → 開發 → 交付）

Ep1（2026-05-03-Unblock-跨團隊設計合作術-Ep1）建立的啟動三步驟（鑑識 / 計畫 / 工作坊）對應「從 0 到收編完成」的啟動期；Ep2（2026-05-03-Unblock-跨團隊設計合作術-Ep2）補入中期信任建立 + 衝突處理；Ep3（2026-05-03-Unblock-跨團隊設計合作術-Ep3）補入設計迭代 + 開發 + 交付——構成完整 7 階段 stakeholder 生命週期：

階段主題核心工具
1. 啟動期鑑識誰是利害關係人、規劃溝通、收編工作坊、產出 指導原則4 鑑識問句 + 影響力與利益矩陣 + 利害關係人參與評估矩陣 + SMART目標 + 1:3 聆聽
2. 中期經營維持關係、降低焦慮、建立深度互信信任公式 + 微貢獻 + 1-on-1 + RACI框架
3. 衝突峰值多方衝突發生時化解衝突管理 + 我訊息 + 拖延戰術 + 行為 ≠ 動機
4. 共識凝聚把意見導向創造性出口How-Might-We + JTBD + 設計觀點 + Crazy 8 + QOC
5. 設計迭代（Ep3）對抗 委員會設計、持續提醒 指導原則招兵買馬技巧 + 尚方寶劍提醒 + 找回饋背後理由 + 設計即假說 心態
6. 開發（Ep3）跨職能即時溝通、降低工程師理解成本面紙 / 白板 / Keynote / 高敏原型 / Loom / Zoom 工具箱（詳見 建構為被採納）
7. 交付 / Adoption（Ep3）讓設計被採納而非僅交付、馬後炮回顧設計專案文件 9 組成 + 建構為被採納 mindset + 馬後炮檢討

出錯後的分層溝通

2026-08-11-陳一枝-工作中捅了大簍子怎麼辦 補入危機場景中的 stakeholder handling：工作出錯後通常至少涉及三類人：

類型處理重點
負責人需要知道事實、風險、目前處理方向；若責任歸屬不明，要先回到 RACI框架 或 owner 定義。
知情人需要知道哪些資訊可同步、哪些先不要外擴；避免消息失真或恐慌擴散。
受害人 / 受影響者需要知道錯誤造成的影響、補救時間線與補償 / 修復安排。

這裡的紀律是「由內到外、簡潔誠懇、有建設性」：先對齊內部可執行的事實和方案，再對受影響者溝通；不要用臨時編造的複雜敘事美化錯誤，因為越複雜越容易失真，也越容易讓信任破產。

預期管理：先把隱形期待說出來

2026-08-12-陳一枝-如何管理預期 補入更日常的 stakeholder handling：父母、同事、主管與伴侶都可能把「你應該怎樣」當成默認前提，但這些期待若沒有被明確說出來，就會在落差出現時變成失望、指責或額外工作。

在利害關係人管理裡，預期管理 可以視為三個問題：

  1. 對方期待什麼結果？ 是成功、體面、安全、即時回覆，還是情緒安撫？
  2. 這個期待是否被自己承諾過？ 若只是對方單方面投射，需要回到界線或 scope。
  3. 期待落空時誰會受影響？ 高影響者的失望可能變成阻力，受影響者的失望則需要更早透明溝通。

這把 stakeholder work 從「處理意見」往前推到「校準參照點」。很多衝突不是因為對方壞，而是雙方以為自己對同一件事有共識，實際上期待從一開始就不同。

外部委託方：客戶是領域專家，設計師是體驗專家

2026-08-18-Unblock-設計顧問工作大開箱 補上顧問公司面對外部客戶的 stakeholder 場景。客戶可能非常理解自己的產業與業務流程，但不一定熟悉數位產品開發、UX 研究或介面設計；設計師則理解體驗設計與產品落地，但不一定一開始就懂客戶產業。

因此外部客戶協作不是「設計師說服客戶照做」，而是兩種專業的互相轉譯：

  • 客戶提供產業知識、使用者脈絡、操作限制與決策條件。
  • 設計師提供數位產品、資訊架構、互動、文案與體驗策略建議。
  • 雙方共同把需求拉回目的性、使用情境與使用者輪廓，而不是把每個想法直接轉成畫面。

這也補強本頁的信任軸：顧問設計師能用平易近人的語言說明專業，並願意承認自己需要向客戶學習領域知識，客戶才更容易相信設計建議不是空泛方法論，而是真正貼近他們問題的協作判斷。

2.5 跨階段共識心態：設計即假說（Ep3）

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

→ 全週期 7 階段的精神基底——把所有論證一視同仁地降階為待驗證假說，避免任何階段陷入「誰權威誰贏」的權力結構。詳見 設計即假說。

3. 啟動三步驟工法（Ep1）

步驟 1：鑑識（誰是利害關係人）

四個鑑識問句：

  1. 誰在聽這個專案？
  2. 誰會受到影響？
  3. 誰可以影響這個專案？
  4. 誰說了算（決策權）？

→ 沒做這一步就動手做設計 = 等收到意見才發現「這不對 / 這不好」的根因。

步驟 2：擬定溝通計畫

態度光譜（resistance ↔ commitment）：每個利害關係人的當下態度沿曲線分布；溝通計畫的目標是把每個人從曲線左邊（抗拒）移到右邊（承諾）。

辨識立場的方法：除了看頭銜，還需要主動聯繫 / 咖啡閒聊 / 內部打聽才能掌握每個人的真實態度——「頭銜不等於態度」。

配套產出：

  • 利害關係人參與群目表 — 團隊內部的檢討工具；隨專案時間推進回頭更新每個人的態度演進；詳見 利害關係人參與評估矩陣（5 階段態度光譜 + 當下 vs 期望態度雙標註）
  • 利害關係人特寫（Stakeholder Profile）— 對關鍵盟友 / 潛在阻力者做的個人 profile，必含三項：
    • 什麼事讓這個人滿意 / 願意支持
    • 專案目標與他個人 KPI / 在乎的事有無重疊區
    • 若他持續持負面看法，可以用什麼方式扭轉

→ 核心動作：透過更多的傾聽理解擔憂，再想辦法解除擔憂、介紹他們的利益（=立場與利益 在 in-house 設計師場景的應用）。

→ 配套工具細節見 影響力與利益矩陣。

步驟 3：工作坊（收編而非交付）

目的不在產出多漂亮的成果，而在於讓利害關係人提早對專案有貢獻 = 自動變盟友。

參與者組合 tip：除了核心利害關係人，邀請影響力低但已是專案支持者的人——靠氣氛擴散讓「這個專案對公司有好處」的感覺更廣。

工作坊應釐清的「指導原則」：

  1. 專案的價值 — 為什麼要做？
  2. 完成的方法 — 怎麼做？
  3. 已知的數據 — 有什麼參考？
  4. 符合 SMART目標 的目標 — 量化、可驗收的成功定義

元紀律：「專案目標、指導原則沒基礎之前，千萬不要讓產品團隊或利害關係人跳進需求——否則專案會立刻被帶偏」。

→ 推薦工作坊活動：人物誌、顧客旅程地圖、Jobs-to-Be-Done（vault 未建頁）；早期沒數據也照樣辦——目的是偷窺利害關係人對使用者的看法並對齊專案定義。

4. 中期經營：信任公式 + 角色釐清（Ep2）

當你中途加入已經人多嘴雜的混亂專案，或啟動期過後想維護長期關係時，靠 信任公式 拆解「為什麼有些人信任你、有些人不」——

信任 = (Credibility + Reliability + Intimacy) / Self-Orientation

設計師預設值：C/R 通常已具備（言出必行）→ 主要要提升 I（熟悉度）+ 降低 S（自我利益導向）。

3 個快速建立信任手段：

  1. 微貢獻 — 迅速幫對方解答小問題、清掉 5-10 分鐘可解的疑難雜症
  2. 定期 1-on-1 + check-in — 5 / 10 / 15 分鐘也行；增加見面頻率
  3. 元紀律：沒有誰想要改變誰 — 健康激盪 ≠ 誰說服誰

搭配 RACI框架 釐清角色：當不理解每個利害關係人的立場時，用 RACI（Responsible / Accountable / Consulted / Informed）正式對齊「誰做、誰扛、誰要先問、誰要後告」——比 影響力與利益矩陣 更精緻、適用範圍更廣。

→ 兩矩陣不衝突：影響力矩陣是溝通策略（怎麼對待誰）/ RACI 是責任分配（誰做什麼）——常一起使用。

5. 衝突處理：衝突管理 umbrella + 我訊息 句型（Ep2）

衝突發生時，先安頓情緒、再處理議題。詳見 衝突管理 umbrella；本節列重點：

3 大常見錯誤（避免）：

  1. 想要改變對方的想法 → 對方更頑固
  2. 太想梳理講邏輯 → 忘了「對你有道理 ≠ 對對方有道理」
  3. 忽略對方的情緒 → 邏輯與資訊都進不去

衝突當下的核心句型工具：我訊息——把「你怎樣（指責）」改成「我們沒納入你的考量 + 對我們有什麼影響 + 一起 catch up 如何」。

「拖延」是合法工具：「我回去想一想，下週再給你們答覆」不是拖延，是給情緒沉澱空間——很可能下週莫名一致附和。

行為 ≠ 動機（活動理論 的職場政治版）：主管在會議裡打槍 = 行為 / 想被聽到 = 動機；解法是邀請參加工作坊（介入動機，不辯論行為）。

6. 元命題：1:3 聆聽比例

對極端有影響力但難搞的對象，溝通時自己說話 vs 對方說話 = 1:3：

  • 主要聽對方在忙什麼、想推動什麼
  • 把焦點放在雙方可共鳴的部分
  • 從對方的立場找到「賣點子、賣專案」的入口

→ 對位 立場與利益：「對方說什麼」與「對方想要什麼」的區分；1:3 是讓「找出對方利益」這個動作有時間發生的物理約束。

7. 元命題：點子被否決 ≠ 點子不夠好

很多設計師的沮喪源頭——「為什麼客戶 / 老闆 / 同事都聽不進去？」——其實是沒先建立健康的合作互信關係。

→ 這條把「好點子失敗」的歸因從「設計能力」轉到「前期關係建立」——兩件事都要做，但設計師往往只練前者、不練後者。

8. 元命題：共識與信任是人工後天創造的（Ep2）

「共識與信任，都是人工後天被創造出來的。」 —— Blair，Unblock Ep16

→ 把「靠默契自然形成共識」這個浪漫想法戳破——共識不會自然發生，要設計師主動製造。本元命題是 Ep1 + Ep2 共同的精神基底。

9. 跨團隊設計師的 3 種能力（Ep2 收尾）

Unblock Blair 給設計師的最終提醒：

  1. 衝突紛爭解決的能力
  2. 團隊政治覺察的能力
  3. 高 EQ — 應付別人對你的回饋 + 應付團隊中情緒不滿 / 政治立場不同的衝突

10. 設計迭代 → 開發 → 交付（Ep3 補入下半場）

設計迭代階段：對抗 委員會設計

設計評審 / 迭代會議是 委員會設計 的高發場景。Ep3 補入 5 條反模式辨識 + 解方：

  • 3 徵兆：設計師無止盡妥協 / 會議多無共識 / 設計成果不如預期（馬後炮）
  • 5 解方：避免單向 UX 原則壓人 + 回到 指導原則 + 找回饋背後理由 + 招兵買馬 + 設計即假說 心態
  • 元紀律：設計師要練「剛柔並濟」——既不全面妥協（價值歸零）也不全面對抗（失去合作）

→ 詳見 委員會設計。

開發階段：跨職能即時溝通工具箱

當工程師 slap 設計師（“Houston, we have a problem”）時，設計師應保持彈性用最快速的工具溝通：

工具場景
面紙 / 紙上草圖旁邊立即討論
白板多人即時共識
Keynote比較正式 / 會後分享
高敏真原型疊加工程師問細節時直接展現
Loom（Slack channel）非同步輕便解釋
Zoom 螢幕錄製 + 講解同步錄製口述意圖

共通紀律：「畢竟不是每一個跨團隊的夥伴，都這麼習慣自己去點擊那些原型」——adoption-mindset 在工具選擇的具體展現。詳見 建構為被採納。

交付階段：設計專案文件 + 建構為被採納 + 馬後炮回顧

ship 不是終點，adoption 才是。Ep3 三條紀律：

  1. 9 大組成的 設計專案文件——即時記錄產生團隊收益（避免異動）+ 個人收益（即時版作品集）
  2. 建構為被採納 mindset——「Build for adoption, not handoff」；寫文件想著「半空降進來者」視角；中心化 findability 比單一文件品質更重要
  3. 馬後炮回顧——專案結束時做檢討，找出哪些指導原則偏離了 / 哪些事實掌握不足

11. 大型組織中的說服順序：方向 → 利益 → 證據 → 細節

2026-08-18-Unblock-說服力大拆解 補入另一個 Unblock Substack 視角：在 Booking.com 這類大型組織中，設計師 / 產品工作者要推動方案時，說服力不是單次提案口才，而是一條讓多方利害關係人看見「為什麼這跟我有關」的路徑。

文章可整理成四段順序：

  1. 大方向對齊：先接到公司願景、市場趨勢或領導層目標，避免被聽成個人偏好。
  2. 共同利益：依對象調整利益語言，可能是專案推進、公司指標、團隊合作、內容品質或對方個人發展。
  3. 證據支持：研究、實驗、策略計畫與既有規劃不是拿來壓人，而是幫對方降低採納風險。
  4. 細節收斂：時程、草稿、設計 / 文案策略能證明推動意願，也讓對方比較容易判斷下一步。

這段補強本頁啟動期工法：鑑識 → 擬定溝通計畫 → 工作坊 是「先找到人並收編」，本篇的四步則是「找到人之後，怎麼把故事說到對方能接住」。兩者都指向同一條元命題：好點子不是靠自己品質自動被採納，必須先穿過組織中的利益、信任與資訊同步。

12. 元命題：跑得快 vs 跑得遠（Ep3 收尾）

「你一個人雖然跑得非常快，但是帶著你的團隊一起跑，才會跑得久跑得遠。」 —— Blair

→ 對應非洲諺語「If you want to go fast, go alone. If you want to go far, go together.」(Blair 未明示引用)。Unblock 三集合計 3 條核心元命題：

  1. Ep1：點子被否決 ≠ 點子不夠好（前期關係 > 設計能力）
  2. Ep2：共識與信任是人工後天創造（不會自然發生）
  3. Ep3：一個人跑得快、帶著團隊跑得遠（永續 > 速度）

與其他概念的關係

  • 與 專案管理 sibling：兩者都處理「多方利害關係人」場景，但角度不同。
    • 專案管理（只要有人社群顧問 傑哥版）= 甲方 account 視角的「預防勝於治療」執行紀律——目標是讓專案不出包；守的是過程
    • 本頁（Unblock Blair 版）= in-house 產品設計師視角的「前期收編利害關係人」啟動工法——目標是把人變成盟友；爭的是支持
    • 兩者互補：好的執行紀律若沒有支持基礎，會在會議中被高影響低利益的「隱形殺手」否決；好的支持基礎若沒有執行紀律，會在交付期出包
  • 與 影響力與利益矩陣 是 umbrella → tool 關係：本頁是 stakeholder management 完整工法 / 矩陣是其中的分群與策略選擇工具
  • 與 RACI框架 是 umbrella → tool 關係：RACI 是中期經營階段的責任分配工具；與影響力矩陣常一起使用
  • 與 利害關係人參與評估矩陣 是 umbrella → tool 關係：本頁步驟 2 配套產出物「利害關係人參與群目表」的獨立工具頁；用 5 階段態度光譜（不知曉 / 抵制 / 中立 / 支持 / 帶領）追蹤每個人態度演進 + 標記期望態度
  • 與 信任公式 是 umbrella → 理論基底：信任公式是中期信任建立的核心理論——CRIS 4 變數可分別經營
  • 與 預期管理 連結：利害關係人若對結果、角色、時程或回應速度有隱形期待，後續衝突會被放大；預期管理是前期溝通計畫的一部分。
  • 與 衝突管理 是 umbrella → 子場景：衝突管理是「衝突峰值階段」的特化工具集，本頁列要點、詳細工法見該頁
  • 與 委員會設計 反模式對抗：本頁工作坊產出的「指導原則」（價值 + 方法 + 數據 + SMART 目標）是會議中對抗無止盡妥協的反委員會工具
  • 與 JTBD 連結：工作坊推薦活動之一，與 POV / HMW 同 cluster；用「When _, I want _, so I can _」句型對齊多方對使用者真正要解的工作的共識
  • 與 指導原則 是 umbrella → tool 關係：指導原則是工作坊產出的核心定錨工具；本頁是其使用情境、指導原則是其組成與使用紀律
  • 與 設計即假說 是 umbrella → 跨階段共識心態：把所有論證降階為待驗證假說，避免任何階段陷入權力之爭
  • 與 設計專案文件 是 umbrella → tool 關係：設計專案文件是「交付階段」的核心工具；9 大組成記錄整個 stakeholder 互動歷程
  • 與 建構為被採納 是 umbrella → 交付階段 mindset：「Build for adoption, not handoff」是 7 階段中最後一階段的精神基底
  • 與 我訊息 連結：衝突當下最關鍵的句型工具
  • 與 活動理論 連結：「行為 ≠ 動機」的職場政治場景版（主管打槍 = 行為 / 想被聽到 = 動機）
  • 與 立場與利益 同精神：1:3 聆聽 + 「理解擔憂、介紹利益」是談判場景的「穿透立場到利益」在 in-house 設計師場景的應用
  • 與 原則性談判法 / 把人跟問題分開 連結：對「負面看法」的利害關係人，先用傾聽安頓人、再切入利益，是「對事不對人」+「利益優先」的具體執行
  • 與 SMART目標 是工作坊產出物：步驟 3 的「指導原則」第四項即為 SMART 寫法的目標
  • 與 How-Might-We 連結：共識凝聚階段的工作坊活動，把功能性低階討論拉回問題本質
  • 與 Goal-Signal-Metric 對位：工作坊產出的「已知的數據 + SMART 目標」對位 G-S-M 的「Signal + Metric」層；本頁 + G-S-M 構成設計師「指標體系 + 利害關係人共識」雙軸
  • 與 使用者研究 / 人物誌 / 顧客旅程地圖 連結：工作坊推薦活動；本頁的元創新是「早期沒研究數據也照辦」——把研究工具當對齊工具而非結論產出工具用
  • 與 檢核提案的-10-個問題 對位：007 是甲方提案 before check（提案要列哪些）/ 本頁是專案啟動 before check（誰要被收編）——兩者都是「事前 check 文化」的具體展現，但場景一甲一乙
  • 與 拆分需求 對位：拆分需求 解決「Discovery 階段需求顆粒不清」/ 本頁解決「Discovery 之前利害關係人未對齊」——往前再推一個階段的紀律。完整工作流：利害關係人收編 → 拆分需求 → PRD → 專案管理

相關來源

備註

本頁建立於 vault 第一個跨團隊設計合作主題影片的 ingest（Unblock Ep15），同日由 Ep16 補入中期經營 + 衝突處理兩階段、由 Ep17 補入設計迭代 + 開發 + 交付三階段，從啟動期工法擴展為完整 7 階段 stakeholder 生命週期 umbrella——vault 中最完整的單一 in-house 設計師工法線。

vault 中的 sibling 對位：

  • 專案管理（甲方 account 視角，只要有人社群顧問 傑哥）+ 本頁（in-house designer 視角，Blair）構成 vault 的「多方協作場景」雙視角——前者來自接案/廣告業，後者來自產品/科技業；兩者都處理 stakeholder 但出發點不同。
  • 未來如累積 PMP / Scrum / 跨組織協作等更通用的「組織協調」內容，可考慮再上一層 umbrella 收攏；目前兩頁並列即可。

2026-05-03 Ep1+Ep2+Ep3+懶人包 同日 ingest 達成的完整累積：

未來累積方向：

  • (a) Resistance to Commitment 曲線 的學術出處
  • (b) Trust Equation 原書（David Maister The Trusted Advisor 2000）
  • (c) Sprint 設計衝刺方法論（Jake Knapp 2016）— Crazy 8 出處
  • (d) Thomas Gordon P.E.T. 系列（I-Statement 系統來源）
  • (e) Sir Alec Issigonis entity（委員會設計 命名典故來源）
  • (f) Lean UX（Jeff Gothelf 2013）— 設計即假說 系統來源
  • (g) 跨地域 / 跨時區團隊 的利害關係人協作
  • (h) 上行管理（managing up）作為本頁的子場景
  • (i) 團隊政治覺察（Ep2 收尾 + Ep3 收尾提及但未展開）

反向連結