設計思考 Design Thinking 2026-06-1477

政府數位服務越做越多，民眾卻越用越累—真正缺的不是技術，是設計思考

讀完這篇，你會知道：

為什麼政府投入大量資源做數位轉型，民眾卻常常覺得服務更難用
Stanford d.school 設計思考框架中的「同理心」「定義問題」如何應用在公共服務設計上
從「建立系統」到「提供服務」的思維轉變，對企業組織的數位轉型同樣適用

思考的起點

你有沒有過這樣的經驗—要辦一件跟政府有關的事，得先下載一個App登記身分，再到另一個網站查詢進度，最後又要回到第三個系統繳費，三個系統互相不認識彼此，連你輸入過的資料都要重複填一次。你心裡忍不住想：政府到底投入了多少資源建立這些系統，為什麼用起來還是這麼累？

這不是只有台灣才有的困擾。2026年6月，印尼GovTech機構Peruri旗下的INA Digital Edu設計研究主管Lody Andrian，在GovInsider的「Festival of Innovation 2026」活動上分享了一段觀察：印尼政府的數位服務「非常分散、彼此重疊、互不連接」，這是他加入公部門後第一個發現的問題。更棘手的是，許多功能其實系統裡早就存在，只是沒有被好好利用。

聽起來似曾相識，對嗎？這正是許多企業在推動數位轉型或組織變革時，也會遇到的情境—投入大量資源建立系統，卻沒有人真正問過：使用者在用這個系統時，到底經歷了什麼？

Andrian曾在世界銀行、聯合國機構與數位顧問公司工作過，他形容自己被公部門吸引，是因為這裡有「私部門遇不到的問題」。而他開出的解方，不是更多技術，而是一個我們很熟悉的詞—設計。

從「建立系統」到「提供服務」：政府數位轉型卡在哪裡

多年來，許多政府機關推動數位轉型的方式，是「把紙本流程搬到網路上」：原本要跑三個窗口的事，現在變成要登入三個系統。系統確實建立起來了，相關指標也達標了—但對民眾來說，體驗並沒有真正改變，甚至因為介面、帳號、流程的不一致，反而變得更加混亂。

Andrian在分享中直接點出，印尼政府數位轉型最大的挑戰「不是技術本身，而是思維的轉變」。他用了一句很簡單的話來總結：「我們正在嘗試從建立系統，轉變為提供服務。」

這句話聽起來像是常識，但要真正做到，需要先回答一個問題：誰是這個服務的使用者？他們在使用這個服務時，真正想要達成的目標是什麼？這正是Stanford d.school設計思考框架中「同理心（Empathize）」階段要解決的問題—先放下「我們要做什麼系統」的工程師視角，回到「使用者正在經歷什麼」的現場視角。

INA Digital Edu團隊目前由22位設計師、研究員、文案寫手與視覺設計師組成，他們的工作不只是把畫面做得好看，而是負責整套數位服務的設計系統、設計原則與使用者體驗文案指引。Andrian特別強調：「我們談的不只是平面設計或視覺設計，而是產品設計與服務設計—這些設計決定了公共服務本身的樣貌。」

換句話說，當一個政府網站讓民眾填了三次同樣的身分資料，那不是「美感」的問題，而是「服務設計」失敗的問題。Andrian也提到，糟糕的設計會讓公部門付出額外代價—從教育訓練、宣導推廣，到民眾投訴的增加，這些隱性成本常常被低估，卻會持續消耗組織的資源與信任。

同理心不是口號：INA Digital Edu怎麼把「使用者研究」變成日常工作

INA Digital Edu隸屬於印尼GovTech機構Peruri，過去曾與印尼初等與中等教育部合作，協助建立國家的數位教育生態系統。在這類專案中，團隊的第一步往往不是「畫介面」，而是先盤點現有系統—哪些功能已經存在、哪些服務彼此重疊、哪些是民眾真正需要卻一直沒有被滿足的需求。

這個步驟，對應到d.school框架裡的「同理心（Empathize）」與「定義問題（Define）」階段。在企業端，我們在工作坊現場也常常看到類似的情況：團隊急著討論「要做什麼功能」，卻很少有人願意先花時間去問「使用者現在到底卡在哪裡」。

Andrian提到，INA Digital Edu團隊推動「共創（co-creation）」與「深入研究」並重的工作方式，相信好的設計必須建立在「對公民行為與需求的深刻理解」之上。這聽起來像是老生常談，但放在政府服務的情境下，意義特別重大—因為政府服務面對的往往是「身分、金錢這類重要事項」，使用者的焦慮感遠高於使用一般消費型App。

他舉了一個很具體的例子：「當民眾使用政府應用程式時，他們需要的不一定是『更快的流程』，而是『確認自己每一步都做對了』的安心感。」這句話點出了一個常被忽略的設計重點—效率與信任，有時候是兩種不同的設計目標，而政府服務往往更需要後者。

根據Stanford d.school設計思考框架，同理心是指透過觀察與訪談，深入理解使用者的真實處境、情緒與未被滿足的需求，作為定義問題的基礎。當設計師願意花時間進入使用者的處境，才有可能設計出真正被需要、被信任的服務。

別寫厚重報告：用「簡單、可重複的設計原則」推動改變

要讓「以人為本」的設計思維真正在組織裡扎根，需要的不是一份厚厚的研究報告，而是一套簡單到任何人都能記住、套用的原則。

Andrian提到一個很實際的觀察：「決策者不一定會讀很長的研究報告，也不一定能理解複雜的服務藍圖，但如果能持續套用簡單的原則，組織設計服務的方式就能慢慢改變。」他推動的第一步非常單純—「建立一套可重複、可執行的實用設計原則」。

這個做法，其實正是d.school框架中「原型（Prototype）」與「測試（Test）」精神的延伸：與其追求一次到位的完美藍圖，不如先建立一個簡單、可操作的版本，讓組織在實際運作中持續調整與優化。

以「速度與安心感的平衡」這個原則為例—許多團隊在設計流程時，預設目標就是「越快越好」，但Andrian提醒，在處理身分、財務等高敏感度的政府服務時，「使用者需要的不一定是更快的流程，而是每一步都正確的確認感」。這條原則一旦被寫成清楚的設計準則，未來不論哪個團隊接手哪個服務，都能依循同一套邏輯做判斷，不需要每次都重新討論「這次要做得多快」。

對企業而言，這種「簡單原則勝過厚重報告」的做法同樣值得參考。許多組織投入大量資源做使用者研究、寫出厚厚的洞察報告，卻因為內容太複雜，最後沒有人真正拿去用。如果能把研究結果濃縮成幾條簡單、可被各部門共同遵守的設計原則，反而更容易真正影響日常的決策與產出。

用一句話定義問題：POV 與 HMW 在公共服務設計中的應用

在印尼這個案例中，雖然受訪者沒有直接提到「POV陳述」或「HMW（我們可以如何）」這些詞彙，但他描述的工作方式，其實正是這兩個d.school工具的精神體現。

POV陳述（Point of View Statement）是一種將使用者、需求與洞察整合為一句話的工具，標準寫法是：「〔使用者〕需要〔需求〕，因為〔洞察〕」。如果套用在Andrian提到的案例上，可能會寫成：「使用政府應用程式辦理身分或金融相關事務的民眾，需要在每一步都確認自己沒有出錯，因為這些事務一旦出錯，後果往往難以挽回。」

有了這樣一句清楚的POV陳述，團隊就能進一步發展出HMW（How Might We，我們可以如何）的提問，例如：「我們可以如何讓使用者在每個步驟都清楚知道自己『做對了』？」「我們可以如何在不增加流程步驟的前提下，提升使用者對系統的信任感？」

這些問題看起來簡單，卻能讓團隊跳出「先決定要做什麼功能」的慣性，轉而從「使用者真正卡住的地方」出發去發想解法。這正是設計思考流程中，「定義問題」與「發想」兩個階段之間最關鍵的橋接—一句清楚的問題定義，往往比十個倉促提出的功能建議更有價值。

設計思維不是SOP：找到適合自己組織的做法

Andrian對印尼地方政府的未來抱持樂觀態度。他觀察到，越來越多地方政府開始意識到「設計思維」與「產品思維」在公共服務中的價值，而這股風氣有機會從專責的設計團隊，逐漸擴散到整個組織的日常運作中。

他特別強調一個關鍵心態：「我希望這種做法能更深植到他們自己的流程裡—重點不是完全照搬我們的流程，而是用適合他們自己的方式去調整應用。」

這句話對任何推動組織變革或設計思維工作坊的人來說，都是一個重要的提醒。設計思考本身不是一套標準作業流程，而是一種「先理解使用者、再定義問題、再動手測��」的思考方式。如果只是把別人的流程原封不動搬過來，往往會因為組織文化、資源條件、使用者群體不同，而失去原本的效果。

換個角度看，這也是為什麼d.school的框架被稱為一種思考方式，而不是一套工具箱—同理心、定義問題、發想、原型、測試這五個階段，本身是一套可以被不同產業、不同規模的組織各自詮釋與調整的思考流程，而不是一套必須照單全收的標準步驟。

從印尼GovTech的案例回望，公共服務設計面臨的挑戰—系統分散、缺乏整合、決策者時間有限、使用者對「正確性」比「速度」更敏感—其實跟許多企業在數位轉型路上遇到的狀況高度相似。差別只在於，政府服務的影響範圍更廣，民眾的容錯空間也更小。

我們的觀點

從INA Digital Edu的案例，我們看到一個很值得玩味的現象：當一個組織談「設計」時，如果只停留在「畫面好不好看」的層次，往往會錯過真正能改變服務體質的機會。真正的設計思考，是先願意放慢腳步，去理解使用者在系統背後經歷的真實處境，再回頭定義問題、調整原則、反覆測試—這正是Stanford d.school框架中從同理心到測試五個階段所要傳遞的核心精神。

我們在過去三百多場企業工作坊中，也經常觀察到類似的情況：許多組織導入新系統或新流程時，第一個被討論的問題往往是「我們要選哪個工具」「介面要怎麼設計」，卻很少有人在最初階段就花時間去問「使用者現在卡在哪裡」「他們真正在意的是什麼」。等到系統上線後才發現使用率不如預期，這時候要再回頭做使用者研究、調整流程，成本往往比一開始就投入同理心訪談高出許多。

印尼的案例也提醒我們，「簡單、可重複的原則」往往比「一份完美的報告」更容易被組織採納並持續使用。這對於正在推動AI轉型、數位轉型或組織變革的團隊來說，是一個值得借鏡的方向：與其追求一次到位的完整方案，不如先建立幾條清楚的設計原則，讓團隊在日常決策中反覆套用、逐步修正。