生態系統圖
一句話定義
生態系統圖是把一個服務所在的整體系統畫出來，盤點其中的人、組織、部門、系統、平台、資源與交換關係，協助設計師看見被忽略的角色、依賴與機會缺口。
核心要點
用宏觀視角看服務所處的系統
2026-05-06-Unblock-服務設計入門-Ep3-Service-Blueprint-Ecosystem-Map 將 Ecosystem Map 定義為「以宏觀角度展示服務在大環境裡涉及的所有元素與它們之間的關聯」。
這張圖的重點不是單一路徑，而是服務如何存在於更大的系統中：使用者、平台、供應商、金流、物流、資料流、政策、社群媒體、演算法、部門與外部夥伴都可能是服務生態的一部分。
三大元素
| 元素 | 說明 | 例子 |
|---|---|---|
| Actor 參與者 | 服務生態中的任何元素，不限於人 | 使用者、組織、地點、部門、系統、平台、供應商 |
| 關係與價值交換 | 參與者之間交換什麼，或形成什麼依賴 | 資訊 / 數據、貨品 / 食材、金錢 / 勞力、僱傭關係 |
| 區塊 | 幫助讀者理解系統結構的分區方式 | 直接 / 間接 / 無接觸、供應鏈、政府政策、產品部門、行銷部門 |
製作時可用「誰、做什麼事、在哪裡、什麼時候發生」作為盤點起手式，再標出元素之間的缺口與機會。
中心選擇會改變地圖
同一個服務若把不同 actor 放在中心，地圖會長得不同。
以配餐服務為例，若把「餐點訂購者」放在中心，會優先看到：
- 他如何知道服務：email 訂閱、朋友 / 同事分享、傳單、社群媒體。
- 他直接接觸什麼：訂購介面 / app、派送員、客服。
- 服務背後依賴什麼：菜單與食譜系統、貨運公司、品牌倉儲、食材供應商、包裝供應商、金流系統、廣告演算法、剩食處理與食物銀行合作。
若改以供應商、配送員、政府機構或品牌營運團隊為中心，圖上的強弱關係、缺口與決策問題也會改變。
區塊分法
常見區塊不只一種：
- 同心圓：依中心 actor 的關係強度分成直接接觸、間接接觸、無接觸。
- 產業 / 角色：把供應鏈、政府政策、技術平台、使用者端、營運端分區。
- 組織階層 / 部門：把產品、行銷、客服、供應鏈、管理團隊等責任範圍分開。
分區本身就是設計判斷：它會決定團隊看見的是「關係強度」、「角色分工」還是「組織責任」。
不要一個人畫
生態系統圖的價值來自多方視角。面對複雜社會議題、醫療系統、生態保育或大型服務系統時，設計師應邀請利害關係人與不同專家一起工作坊盤點。若只靠單一設計師想像，圖很容易變成片面假設。
2026-05-06-Unblock-服務設計常見誤區指南 可視為這條紀律的反面清單：只有觀察沒有對話、憑空捏造或模板照抄，都會讓系統圖看似完整但缺乏可信度。生態系統圖應該把隱形關係變得可被討論，而不是把設計師自己的推測包裝成系統全貌。
與其他概念的關係
- 服務設計 — 生態系統圖是服務設計四工具線中的第四步，回答「這個服務存在於什麼系統」。
- 服務藍圖 — 生態系統圖看角色與交換關係；服務藍圖看這些角色與流程如何在服務交付中串起來。
- 顧客旅程地圖 — 旅程地圖沿時間看使用者經驗；生態系統圖沿系統關係看服務依賴。
- 利害關係人管理 — 生態系統圖延伸了利害關係人地圖，不只看人與人，也看人機、系統與系統、界面與平台。
- 使用者體驗設計 — 使用者感受到的體驗常被非使用者端元素決定；生態系統圖把這些後端與外部元素納入 UX 判斷。
相關來源
- 2026-05-06-Unblock-服務設計常見誤區指南 — 補入假設驗證、對話補強觀察、開放協作與分享等服務設計方法共同紀律
- 2026-05-06-Unblock-服務設計入門-Ep3-Service-Blueprint-Ecosystem-Map — Unblock 服務設計入門第 3 集；補入 Ecosystem Map 定義、三大元素、工作坊製作紀律、配餐服務案例與分區方式。
備註
- 本頁先採「服務設計工具」語境。若未來有系統思考、system map、actor-network theory、policy design 或 civic design 來源，可再補入與系統圖 / 因果迴路圖 / stakeholder map 的邊界。