概念地圖・使用者體驗五層模型
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
使用者體驗五層模型：沿著畫面查清依賴
出庫查詢頁的按鈕截圖已經改了三版，客戶真正要問的出庫時間，仍得打電話才能查到。使用者體驗五層模型把一個產品攤成策略、範圍、結構、框架、表現，愈往上愈接近眼前的畫面。它幫團隊沿著依賴往下追：這顆按鈕承接哪個流程，流程要用什麼資料，資料又在替誰完成什麼事？畫面可以很快改完——底下那份承諾，可能還沒有人接手。
五個平面承接哪些決定
先把同一件服務由下往上讀一遍，再看螢幕上的抱怨落在哪裡。
| 平面 | 要回答的問題 | 線上展覽導覽的決定 |
|---|---|---|
| 策略 Strategy | 誰要達成什麼？ | 觀眾想找到感興趣的展品，主辦希望傳達策展主題。 |
| 範圍 Scope | 提供哪些內容功能？ | 準備展品介紹、主題索引，確認這次要收錄的內容。 |
| 結構 Structure | 資訊流程怎麼接？ | 讓人從主題進入展品，再找到相關延伸內容。 |
| 框架 Skeleton | 介面元件怎麼擺？ | 安排目錄的位置，以及返回上一件展品的導覽元件。 |
| 表現 Surface | 感官外觀怎麼呈現？ | 決定色彩、字級、圖片呈現與視覺辨識。 |
Jesse James Garrett 的原模型同時展開產品功能與資訊內容兩種視角，結構層分別談互動設計與資訊架構，框架層再處理介面、導覽與資訊設計。本文把兩側共同的決策依賴合成一張簡圖。往上是愈具體的設計決定，測試發現問題時可以往下重問——五層會互相牽動。（來源：《The Elements of User Experience》原書目錄）
沿著故障訊號往下找原因
一、把雙方目的放在同一張紙上。氣調保鮮服務商想少接查詢電話，客戶想安排提貨。這兩個目的接起來，需要客戶查完就知道下一步怎麼走。若團隊只記錄電話量，很容易靠藏起聯絡方式達成報表目標，讓客戶的等待轉移到別處——先保留兩邊的目的，才有辦法檢查解法的代價。自問：使用者與組織各自要達成什麼？
二、追到畫面背後的那份資料。客戶說「看不到出庫時間」，可以從字級與位置查起，也得確認出庫時間這個欄位有沒有被納入範圍。若查詢頁只有狀態碼，就要追問誰把狀態轉成提貨安排、多久更新一次。把訂單編號、出庫狀態與聯絡窗口各自接回來源——每一筆都要有人供應。自問：每個功能依賴哪份資料，由誰維護？
三、讓改動沿著依賴傳下去。假設服務商重新界定目標，這一版只讓客戶辨識出庫進度，提貨時段仍由窗口確認。範圍、查詢後的流程、欄位排列與畫面文案都要再走一次。原本寫「立即安排提貨」的按鈕尤其要重驗——它背後需要的交付，比「查看進度」多了一截。自問：底層決定改變後，哪些上層設計需要重新驗證？
氣調保鮮服務商的查詢入口
底下這家台灣中部的氣調保鮮服務商，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。
- 策略：客戶希望知道何時能安排車輛提貨，服務商希望減少重複查詢。團隊先把「查詢後能否決定下一步」放進驗收討論。兩邊目的同時留在桌上。
- 範圍：頁面預計提供出庫狀態及聯絡窗口。盤點資料後才發現，狀態一天才回填一次，當日的異動還留在現場紀錄裡。查詢功能已列入，資料時效尚待處理。
- 結構：客戶由訂單編號查到狀態，再依指示確認提貨。團隊要逐步檢查：查無訂單、尚未更新、可以聯絡安排時，各自往哪裡走——中途卡住也要有去處。
- 框架：查詢欄、訂單識別、狀態與聯絡窗口須在畫面上可找。可先用草圖測試客戶能否辨認這是自己的那一批，以及狀態更新到什麼時候。先讓資訊的位置接受檢查。
- 表現：再看文字、色彩與字級如何幫人讀懂狀態。把按鈕換色可以改善辨識，資料延遲仍需另外處理——顏色無法替現場完成回填。三版截圖都碰不到這段等待。
這場討論走到資料回填，就找到一條值得繼續查的線。一天一更的狀態能支撐哪些查詢承諾，需要拿客戶安排車輛的時間來比對；能否提高更新頻率，則要和現場確認人力與紀錄方式。若暫時維持原頻率，頁面該揭露更新時間，並交代聯絡窗口如何接手。這些都是待驗證的處理方向，改善程度仍要看實際查詢與提貨經過——先把根因找準，才知道下一輪該找誰進會議。以上為說明結構用的示意情境，僅供理解框架之用。
五層模型什麼時候會騙你
- 把依賴排成單向時程，會把回頭修正當成犯錯。畫面測試可能揭露使用者的目的理解錯了，內容盤點也可能迫使團隊縮小範圍。五層提供追查路徑，實作時仍需要往返。若每層一簽核就永久封存，後來的人只能替早期假設補洞——進度表前進了，問題還留在原地。
- 精美的表現會遮住空缺的範圍。提案畫面很容易把理想資料先填進去，讓狀態看起來隨時完整。真實訂單還要經過資料取得、維護與異常處理。審稿時應抽一筆真的可能查不到的訂單，沿著五層走一趟——那個空白由誰補，通常比按鈕要用哪個色號更早影響體驗。
- 服務交付還有螢幕外的人與資料。氣調保鮮服務的現場紀錄、回填責任與聯絡交接，會決定頁面能承諾到哪裡。五層可以提示相依關係，完整的現場作業仍要另外盤點。若只找設計師改查詢頁，每一層都填滿名詞，也可能留下同一段斷點——窗口收到電話後，還得再去找人問。
查不到的消息由誰補上
每一次畫面修補，都背著幾層承諾。
《痛點》的 P.A.I.N. 會把注意力帶回那個正在等消息的人：他查完這頁，接著得付出什麼代價？電話接通前，車輛安排可能只能暫停，窗口也得重問現場。這張圖畫得出決策之間的依賴，畫不出客戶為一句「還要再確認」付出的等待。所以團隊需要把一段具體經過帶進五層，看看每次查詢、轉問與回覆各由誰承接。這能替「體驗不好」找到可討論的位置——也讓資料負責人參與原本只談版面的會議。今晚挑最近一則詢問出庫時間的紀錄，找接電話的同事重走回覆過程，把最後一次向現場確認的時刻記下來。
使用者體驗五層，常被問到的幾件事
使用者體驗五層的順序是什麼？
由下往上是策略、範圍、結構、框架、表現，英文依序為 Strategy、Scope、Structure、Skeleton、Surface。底層回答目的，上層逐步落成使用者接觸的樣子。閱讀時依序檢查有助於追蹤決定的來源；實作可以先做草圖來驗證理解，再回頭調整目的或範圍——往返是必要的學習。
結構層與框架層差在哪裡？
結構處理資訊之間的關係與互動流程，例如由訂單進入出庫狀態，接著聯絡窗口確認提貨。框架處理這些關係如何在介面上被找到，包含查詢欄、狀態、導覽與操作元件的安排。可以先用流程圖討論結構，再用線框草圖檢查框架——同一個流程，仍可能因欄位排列而讓人走錯。
五層模型是否只能用在網站？
這個模型最初以網站體驗展開，目的、內容功能、組織方式、介面與感官呈現的問題，也可協助團隊檢視其他數位產品。延伸到完整服務時，要把現場工作與人員交接另外補進來。像出庫查詢頁就依賴現場回填，五層可以指出需要追查的地方，後續仍須檢查實際作業和交付條件。
改版應該先做哪一層？
先從具體故障訊號追查，並核對策略層的目的是否仍成立。字太小可以直接測試表現；使用者查不到需要的消息，就繼續查範圍、資料來源與流程。找到影響目的的依賴後，再決定這次改版要動到哪裡。底層更動時記得重驗上層，避免舊文案繼續承諾新流程已經拿掉的服務。
上下層的依賴整理清楚後，探索與收斂可以各自安排時間。接著用雙鑽石設計流程安排探索問題與測試解法，再以價值主張畫布對照工作、痛苦與承諾的價值，把下一輪訪談帶回客戶安排提貨的那一刻。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。