【服務設計入門】Ep3: 服務設計秘密武器…Service Blueprint 與Ecosystem Map！
後設資料
- URL：https://www.youtube.com/watch?v=Np5UIJmtgO4
- 頻道：Unblock
- 主持人：果子（服務設計入門系列）
- 發表日：2022-06-21
- 片長：11:25
- 集數定位：Unblock「閉著眼睛都要會的四個服務設計方法」第 3 集；主題為 服務藍圖 與 生態系統圖
- 內容形式：YouTube 影片（口語講解 + 投影片）
- 語言：繁體中文
- ASR 來源：使用者貼入逐字稿；含明顯辨識錯誤，wiki 摘要段已修訂
一句話濃縮
生態系統圖 用宏觀視角盤點服務中的參與者、交換關係與分區，服務藍圖 則用流程視角拆出使用者活動、前台互動、後台工作與外部支援流程；兩者共同讓設計師看見服務交付中的缺口、機會與跨部門串接問題。
提取要點
Ecosystem Map：用系統視角看服務
- 定義：Ecosystem Map 以宏觀角度展示一個服務在大環境裡涉及的所有元素與它們之間的關聯，包含人類與非人類元素。
- 使用時機：面對複雜社會議題或盤根錯節的系統時，例如原住民爭議、生態保育、動物保育、醫療系統等，可用來看見隱藏關係。
- 製作方式：建議在工作坊中邀請利害關係人與不同專家一起腦力激盪，不應由設計師獨自埋頭畫圖。
- 三大元素：
- Actor 參與者：人、組織、地點、部門、系統等。
- 關係與價值交換：資訊 / 數據、貨品 / 資源、金錢 / 勞力 / 僱傭關係等。
- 區塊：用同心圓、產業 / 角色、組織階層或部門分區。
- 中心位置會改變整張圖：若以配餐服務的訂購者為中心，圖會優先展開 email 訂閱、朋友分享、傳單、社群媒體、訂購介面、派送員、菜單系統、倉儲、食材供應商、包裝供應商、金流、廣告演算法與剩食處理等關係。
- 與利害關係人地圖的關係：Ecosystem Map 是利害關係人地圖的延伸版；不只看人與人，也包含人機、機器與機器、人與系統、系統與系統、介面與平台之間的互動。
Service Blueprint：用流程視角看服務交付
- 定義：Service Blueprint 以服務提供者角度展示前台與後台元素如何串接，並描繪服務交付流程中可見與不可見的工作。
- 使用時機：
- 服務效率不佳，想改善流程效率。
- 使用者體驗已相對完整，想改善內部員工或服務提供者的體驗。
- 需要辨識缺口、可自動化節點或新科技導入機會。
- 三條基準線：
- 互動線 Line of Interaction：線上方是使用者 / 消費者活動；線下方是服務提供者活動。
- 可見線 Line of Visibility：線上方是使用者看得見的前台工作；線下方是使用者看不見的後台工作。
- 內部互動線 Line of Internal Interaction：線上方是服務提供團隊內部活動；線下方是第三方系統、外部技術團隊、供應商或組織外流程。
- 典型層次：使用者旅程 / 接觸點、前台工作（含真人與技術互動）、後台工作、支援流程。
- 配餐服務例子：
- 使用者活動：接收 email 折扣碼、填寫用餐計畫、註冊付款、收宅配、使用客服。
- 前台互動：傳單、網站 / app、配送員簽收、客服對話。
- 後台工作：產品 / 服務團隊更新優惠、定期更新菜單、接收訂單、訂購與裝箱食材、通知配送。
- 支援流程：電子報系統、Google / Facebook 登入串接、付款系統、菜品研發、供應鏈管理、供應商審核、食物銀行剩食合作。
- 表示法：用箭頭描述互動方向；雙向互動可用雙向箭頭，缺口或風險可用閃電符號標示。
兩個工具的共同價值
- 幫助設計師看見服務提供流程的缺口，並找到系統化、自動化或導入新科技的機會。
- 打破各自為政的狀態：部門與部門之間的關係會被攤開，前台承諾、後台支援與外部夥伴的責任也更清楚。
- 對 UI / 產品設計師也有價值：練習換位思考，看見使用者痛點與脈絡，讓數位服務或 app 設計更貼近真實服務流程。
- 服務設計的核心價值：讓完成一個服務的所有元素，在對的時間做對的事。
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
- 服務藍圖 — 新建：補入 Service Blueprint 的三條基準線、前台 / 後台 / 支援流程分層、使用時機與配餐服務例子。
- 生態系統圖 — 新建：補入 Ecosystem Map 的三大元素、工作坊製作紀律、價值交換類型、分區方法與利害關係人地圖延伸關係。
- 服務設計 — 大幅更新：服務設計入門三集 / 四方法工具線補齊；把 人物誌、顧客旅程地圖、服務藍圖、生態系統圖 串成「為誰 → 如何經過 → 如何交付 → 系統如何存在」的尺度遞進。
- 顧客旅程地圖 — 更新：補入它在 服務藍圖 中通常作為上方使用者活動層，並與服務提供者流程對位。
- MOC-UX / MOC-設計思考 — 更新：把服務設計方法線從 Persona / Journey Map 補到 Blueprint / Ecosystem Map。
- Unblock — 更新：補齊服務設計入門三集索引。
- 觀察清單 — 同步：消化「Unblock 服務設計入門 Ep3」待 ingest 外部資源；MOC-服務設計候選進度更新為來源 3/4、主軸 4/5。
Ingest 筆記
2026-05-06
- ASR 修訂原則：使用者貼入逐字稿有明顯辨識錯誤，例如「生態地基礎」應為生態系地圖、「同性人」應為同心圓、「換了 夠」推測為派送員到貨 / 交付互動、「經流系統」應為金流系統、「栽配員」應為宅配員。來源原文區保留貼入版本；提取與 wiki 頁使用可檢索術語。
- 新建 服務藍圖 / 生態系統圖 的理由：本來源直接給出兩個工具的定義、使用時機、構成元素與配餐服務案例，密度已超過單純內嵌於 服務設計 的程度；同時兩頁可分別連回 顧客旅程地圖 與 利害關係人管理，避免 服務設計 umbrella 過重。
- 不新建
接觸點/前台後台：本來源已大量使用 touchpoint、frontstage、backstage、line of visibility 等概念，但目前最自然位置仍在 服務藍圖 / 顧客旅程地圖 內。若未來品牌接觸點、CX、客服營運或 omnichannel 來源累積，再評估拆頁。 - 不新建 MOC-服務設計：Ep1 / Ep2 / Ep3 已補齊四個方法，但來源面仍是同一 Unblock 系列，且缺少獨立 service design 來源、touchpoint map、service safari、co-creation / workshop 等更多主軸；觀察清單維持 MOC 候選，進度更新為來源 3/4、主軸 4/5。
- 系列狀態：Unblock 服務設計入門三集已補齊；後續若 ingest 服務設計誤區講義，可作為第二類來源檢查四方法常見誤用。
原文（可選）
以下為使用者貼入的 ASR 逐字稿；保留原始辨識錯字，供日後回查。
Action! 首先,什麼是Ecosystem Map 生態系地圖 Ecosystem Map shows your service as a system and how that entire system is conducted 用中文的翻譯呢,其實就是說 生態系地圖以宏觀的角度展示在大環境裡 成就有一個服務會涉及的所有元素與它們之間的關聯 包含人類與非人類的元素 還有兩大使用時機 那你在面對複雜的社會議題 還有盤根錯解的系統的時候 比如說人住民爭議啊 生態保育 動物保育 或者是醫療系統等等 可以讓你看見很多隱藏的關係 探索一個服務所存在的生態系統長什麼樣貌的 建議呢 在工作坊中邀請利害關係的人 或者是不同的專家 一起來腦力激盪製作這個地圖 儘管是千萬不要以為自己是孤獨的一匹狼 埋頭狂化的地圖 這樣沒有用也沒有價值哦 生態地基礎有三大元素 第一個是actor參與者 第二個呢是關係與條件的交換 第三個是區塊 在製作生態地基礎的時候 有一個技巧分享給你們 想想誰做什麼事在哪裡 什麼時候發生何時何地發生 然後在製作這個地圖的時候 你可以點出每個元素跟元素之間的機會跟缺口 舉個例子來說吧 現在要做一個提前配餐的服務 這服務呢 使用者他可以選取他自己喜歡的菜單 然後我們會幫他準備新鮮的食材跟烹煮的方式 然後送到他的家門口 所以他可以節省買菜跟思考要煮什麼的時間 在生態系地圖裡面呢 Actor參與者其實他可以是任何的東西 他可以是一個人 一個組織 一個地點 一個部門 一個系統等等 那你這時候你就要想 誰要放在中心的位置 你的思維改變了 你的生態系統就會講的不一樣 這裡我的例子是這個餐點的訂購者 放在中心的位置 我就會想那他怎麼知道這個服務的 他可能是透過Email的訂閱 朋友同事的分享 大陸的傳單或社群媒體 得知這個服務 直接接觸的可能是訂購的界面或是APP然後他訂購完之後派送員會跟他有最直接的接觸快到了 換了 夠再來要怎麼讓這個服務可以成功可能你會有菜單食譜的訂製系統 你會有貨運公司 你會有品牌的倉儲 來儲存這些食材 你也會有食材供應箱 包裝的供應箱 你可能還會面臨你訂購多餘的食材 所以你必須要處理這些多餘的食材 然後在訂購界面 他的背後其實可能會有數位服務的提供者 經流系統 然後你社群媒體 背後可能是有廣告演算的系統 接下來呢 第二個元素就是 關係跟價值的交換 價值的交換呢 可以交換第一個 比如說是資訊或者是 數據的交換 當我們在使用社群媒體的時候 其實我們就是在分享 我們自己的個人資訊嘛 那這時候就會有一些 資訊的交換存在 那另外一個關係交換 可以是貨品的交換 或在這個範圍裡面 它就是食材的交換 第三種關係的交換 最常見的其實就是 金錢跟勞力的交換 當有金錢跟勞力的交換的時候 就會存在所謂的僱傭關係 那你在決定這些所謂的參與者 跟他們之間的關係交換的時候 你可能會發現 某些參與者跟參與者之間 會有一些缺口 然後你也會探索到一些機會 這時候你就可以把它標示出來 第三個元素其實就是區塊 最常見的區塊的區分方式 就是以同性人的方式 在這裡我是以訂購者的關係的強度下去做的 越靠近這訂購者他的關係是越強烈的 所以直接間接跟無接觸 那當然你也可以不要用同性人的方式 再作為區分區塊 你也可以想想 比如說產業啊 或者是他在這個生態勢裡面 他扮演的角色 比如說左上角我就會用做出是供應鏈 比如說供應商 實材供應商的角色都放在下面 然後你也可以有政府啊 政策相關的 或者是政府機構相關的角色 你就可以放在左下角的地方 另外一個區塊區分的方式 你可以組織的階層或部門做區分 像右上角我就會作為產品部門 它會需要盤掛的元素 那下面呢可能就是行銷部門 它會需要負責的服務元素 Ecosystem Map 其實它是一個厲害關係人地圖的延伸版 因為它不只包含人與人之間的關係 它包含人機的互動 機器跟機器之間 人與系統之間的互動 系統與系統之間的互動 界面跟平臺之間的互動 所以它其實包羅了外向 當你在製作完生態新地圖之後 其實你就可以知道 有哪些厲害關係的人 或有哪些元素或系統 是你現在忽視而不存在的 你需要在你做決策的時候 一起含廣 作為你之後服務提供的一些考量 但是透過這個方法你可能還是沒辦法很清楚的瞭解到這些服務元素之間串連的關係所以這時候我們就會用所謂的Service Blueprint 服務藍圖 來瞭解服務跟服務之間元素的串連 所以服務藍圖是什麼呢? Service Blueprint’s map out the entire process of service delivery above and below the line of visibility 服務藍圖以服務提供者的角度 展示前臺與後臺元素如何串連 傳出服務的流程 還有兩大時機 第一個就是你發現你的服務的效率不佳 你想要改善你服務的效率的時候 第二個就是你的使用者體驗已經很完善了 你想要改善你內部員工服務提供者的體驗的時候 你會使用到這個方法來幫助你做整合你的服務 然後認清有哪些缺口哪些可以被信用化 服務藍圖的基本元素有三條基準線你們一定要知道 第一條是互動線Line of Interaction 在互動線之上其實就是使用者或消費者的活動 在互動線之下呢 是服務提供者會有的活動 用剛剛的配餐服務 作為例子來講 互動線之上 你就會有使用者的一個旅程 那這種你可能會發現 蠻相似的 你會從使用者旅程地圖中 把上面那個區塊移過來這裡 然後你又含過要所謂的接觸點 那在這個互動線之下呢 其實就是第一個 前臺的工作 使用者怎麼直接 跟你的前臺員工做互動的 當然因為現在很多服務 都是數位的服務 所以其實人與人之間的互動可能漸漸變少 所以這時候我會加入這個subcategory 就是科技層面 比如說是這個使用者 他會點開email加附訓的折扣碼 然後在網站上之後 他會填寫應餐計劃表 然後他會開始註冊啊 付款的程序跟宅配還有客服的服務 所以這會可能是你在技術層面 他會跟使用者有所擁有的互動 再來呢你可能真正真的互動 可能是發送傳單啊 或者是當栽配員在配送服務的時候 會跟使用者會有一手的服務 他需要簽收 所以前臺的工作包含使用者或消費者 跟前臺員工還有流程的一些互動 都可以包含在這裡面 第二條線就是可見線 可見線之上是使用者看得見服務提供者在做的事 可見線之下是使用者看不見服務提供者在做哪些事情 所以可見線之下我們又成為後臺 幕後的工作 比如說你需要幫傳單的email折扣碼 其實我們產品團隊或者是服務團的 需要更新客戶的優惠 那我們需要定期的更新菜單 我們在接收訂單之後需要訂購食材 有後有裝箱食材跟搭配相關食譜的這個過程 然後我們會通知配送人才可以開始再配了 第三個項目是內部互動線 內部互動線之上呢 就是服務提供團隊的內部活動內部互動線之下呢就是服務提供團隊以外或者是組織以外的互動比如說第三方的系統啊技術團隊或者是管理團隊 或者是食材工藝商管理團隊的 這些外部的流程跟互動 就會放在這條線之下 比如說我們現在要更新顧客的優惠啊 我們其實在第三方會有一個電子報的系統 使用者在註冊服務的時候 比如說你想要跟Google Facebook 這些登錄系統的串聯付款的系統 然後你可能會有一個研發菜品的部門 專門在製作這些新的菜品的研發程序 然後你可能也會有管理供應鏈的部門 會做供應鏈的管理程序 然後審核這些食材供應商是否合格 對於剩餘的食材的處理 你可能會跟所謂的食物銀行會有合作 你可以把這些剩餘的食材發配給食物銀行 讓這一個服務它可以更永續 最後一個小技巧 就是你可以用一些箭頭來描述這些互動的方向 你的互動可能單向 但如果當你是雙向的互動的時候 我就會用雙向的箭頭 比如說使用者他在利用客服服務的時候 他想要詢問一些他的食物過敏源 然後你可能會一來一往的這些客服服務 這樣就是一個雙向的互動 但你也可以像剛剛的生態系地圖一樣 比如說閃電來標示哪些元素跟元素之間 或哪些流程的流程之間是有缺口的 服務藍圖跟Ecosystem Map 其實他們的價值幫助設計師看見服務提供流程的缺口 然後你可以找到機會 比如說系統化或引進新的科技 來讓這個服務的效率可以更完善 你也可以有機會打破各式體制的狀態 因為部門跟部門之間的關係 會透過這兩個方法 你可以看得非常非常的清楚 這四個方法其實不只是服務設計師可以學 其實對UI設計師或者是產品設計師 也是一個非常非常好的練習跟學習的方法 練習這些方法的過程中換位思考 然後看見使用者的痛點還有他們的脈絡 讓你在設計這些數位服務或者是網頁APP的時候 讓你的這些設計更深指引心 不要忘記其實服務設計的核心價值 就是讓完成一個服務的所有元素 在對的時間做對的事 所以上面分享的這四個方法呢 也就是幫助服務設計師 可以看見所有的元素 以及他們要如何串聯 為了要幫助你們更瞭解服務設計 還有不要踩到一些服務設計的地雷 我也製作了服務設計誤區的講義 放在下方的資訊欄讓你們下載 不要忘記了哦 如果你喜歡這類型影片 記得按贊分享 那如果你還有任何問題 一樣下方留言 那我們就下次見咯 拜拜