UI 與 UX 是什麼？定義、差異、流程與網站案例

UI（使用者介面）是人看見並操作產品時接觸的畫面與控制項；UX（使用者體驗）涵蓋人在特定情境下使用產品或服務的整段經驗，包括是否能理解、完成任務與獲得預期結果。兩者互相影響，不能簡化成「UI 管長相、UX 管感受」。

本文用網站案例說明 UI 與 UX 的差異、工作內容、設計流程與衡量方法。網站改版後轉換率不變，可能涉及內容、產品、價格、流量或流程，不能只憑畫面判斷。搜尋排名也不會與 UI/UX 指標一對一綁定；需要分開看搜尋文件與站內操作。

如果你是新手、行銷人、PM，或正在自己架站的創業者，接下來會協助你把觀念釐清，不再只憑感覺跟設計師溝通。等觀念有了底、想真的動手做一個網站時，可以接著看從零開始做網站的完整流程，從規劃、設計到上線走一遍。

UI 和 UX 的定義：介面是接觸點，體驗涵蓋整段使用情境

先把兩個詞各自拆開來看，不要急著合在一起。

UI 講的是「介面」。你眼睛看得到的按鈕顏色、字體大小、圖示、欄位之間的留白、配色、選單怎麼排列、滑鼠移過去會不會變色、手機上的按鈕夠不夠大、表單要填幾格，這些全部都是 UI。它關心的是視覺與互動的細節：東西擺哪裡、長什麼樣、看起來像不像同一個品牌。一個判斷方式很簡單，如果你拿掉所有顏色、僅剩黑白線框，還能討論的東西（位置、大小、層級、間距），多半偏 UI 的結構面；而那些討論「這個藍配這個灰會不會太冷」「這個圓角要不要再縮小」的，則是 UI 的視覺面。

UX 講的是「體驗」，範圍比 UI 大得多。它從使用者「還沒進到你網站之前」（他為什麼要搜尋這件事、他心裡帶著什麼問題、他從哪裡連過來）一路涵蓋到「用完之後」（他解決問題了嗎、會不會再來、會不會推薦給朋友）。中間包含資訊怎麼組織、流程怎麼設計、內容有沒有回答他的問題、操作的時候會不會卡關、出錯的時候系統有沒有給他一條清楚的路。UX 關心的是人與產品互動的那一整段經驗，介面僅是其中一個載體。

Nielsen Norman Group 說明，Don Norman 在 1990 年代提出「user experience」一詞，目的是涵蓋一個人與公司、產品或服務互動的各個面向。這個範圍比單一介面寬，但不意味著 UI 工作只能處理外觀、UX 工作只能處理流程；角色分工會因團隊而異。NN/g 的定義可作原文對照。

用一個具體例子把兩者擺在一起，你會更有感覺。同一個「會員註冊按鈕」：從 UI 的角度看，要決定的是它放哪裡、什麼顏色、圓角多少、字多大、滑鼠移過去要不要變色、跟旁邊的「登入」按鈕層級怎麼拉開；從 UX 的角度看，要問的是使用者到底需不需要註冊這件事、能不能讓他用 guest 身份先結帳再說、註冊要填幾個欄位才合理、填到一半離開會不會保留資料、註冊完之後他被帶到哪裡。同一顆按鈕，UI 問的是「它長怎樣」，UX 問的是「它在整段旅程裡扮演什麼角色、甚至能不能不要存在」。這就是兩者視野的差距。

所以一個常見的誤解可以馬上拆掉：UX 不等於 UI。一個網站可以 UI 做得很漂亮、得過設計獎，但 UX 一塌糊塗（使用者找不到他要的東西、結帳流程卡到爆、客服電話藏在三層選單底下）；也可以 UI 很樸素、甚至有點過時，但流程順暢到使用者用一次就上手。這兩件事會互相影響，但不是同一件事。想深入看兩者在工作流程上的差異，可以搭配這篇 UI/UX 設計差異全解析。

用一間餐廳看懂 UI 與 UX 的關係

定義聽完還是覺得抽象？換個我常用的方式想。

想像你今天走進一間餐廳。餐廳的裝潢風格、燈光氣氛、菜單的排版與印刷質感、餐具的樣子、服務生制服的顏色、牆上那幅畫，這些你「眼睛看到」的東西，就是 UI。它決定你第一眼覺得這間店高級還是隨性、值不值得信任、會不會想拍照打卡。

但 UX 是另一回事。UX 是從你「決定今晚要吃這家」開始：你在 Google 搜到它、看了評價、打電話訂位有沒有人接、到現場好不好停車、進門後等多久才被帶位、服務生介紹菜色清不清楚、點完餐等多久才上菜、菜對不對味、中間要不要加水是不是自己來、結帳時店員態度如何、離開之後你會不會推薦給朋友。這整段從頭到尾的體驗，才是 UX。

餐廳的裝潢、菜單與指示屬於可見的接觸點；訂位、等候、用餐與結帳共同構成顧客體驗。這個比喻能說明範圍差異，不能把「UI 好、UX 差」當成可直接量化的評分；介面本身也會影響整段體驗。

對應到網站也是一樣的道理。你花大錢做了一個漂亮的英雄區橫幅、精緻的配色、流暢的動態效果（這都是 UI），但若結帳流程五步走不完、按鈕主次分不清、手機版某個欄位點不到（這都是 UX），那些漂亮的視覺一個都救不了你的轉換率。

若網站畫面更新後，讀者仍無法完成購買或詢問，就要檢查資訊、流程和技術狀態。視覺與流程不是互斥的預算選擇；字體層級、錯誤提示或按鈕狀態也會直接影響操作。先找證據，再決定該修哪一層。

UI 設計師 vs UX 設計師：工作內容哪裡不一樣

在規模夠大的團隊裡，UI 設計師與 UX 設計師是兩個不同的位子。理解他們各自做什麼，你才會知道自己的問題該找誰、或該學哪一塊。這張表是我在帶專案時常用的對照方式：

研究、資訊架構、互動與視覺可能由不同角色分工，也可能由同一人反覆處理。團隊最好先釐清使用者任務與限制，再用原型驗證；若先做視覺稿，也不代表必然要全部重畫，應看發現的問題影響哪一部分。

但在台灣多數中小企業、新創或接案情境裡，這兩個角色常常是同一個人包辦，這也是為什麼履歷上會看到「UI/UX 設計師」這種寫法。這沒有不對，僅是你要知道：這是一個人同時在做兩種不同的訓練，一種偏視覺判斷，一種偏研究與邏輯。要兩邊都做到水準之上，需要刻意練習；光把 Figma 學會，還遠遠不夠。工具的部分，Figma 中文完整教學這篇可以幫你快速上手業界標準工具。

UI 和 UX 怎麼合力決定一個網站好不好用

定義與分工講完，接著要把兩者接起來看。業界有一套流傳很廣、也最好用的框架，叫「使用者體驗的五個層次」，由資訊架構師 Jesse James Garrett 提出。它把一個網站從無到有拆成五層，從最抽象到最具體，分別是：策略層、範疇層、結構層、骨架層、表面層，完整架構發表在 Garrett 的 The Elements of User Experience。我用白話把它翻一次：

• 策略層：我們要服務誰、解決他什麼問題、我們想得到什麼。這層談的是目標，跟畫面一點關係都沒有。
• 範疇層：這個產品要包含哪些功能、哪些內容，更重要的是「不包含什麼」。
• 結構層：資訊怎麼組織、使用者從 A 走到 B 要經過哪些步驟。這是 UX 的核心戰場。
• 骨架層：頁面上什麼東西放哪裡、按鈕與欄位的相對位置。wireframe 就活在這一層，是 UI 與 UX 交界的地帶。
• 表面層：配色、字體、圖片、最終的視覺呈現。這才是大眾直覺以為的「UI」。

Garrett 的五個層次能幫團隊檢查策略、範疇、結構、骨架與表面是否互相一致。它不是線性施工規範：視覺稿可能暴露流程問題，研究也可能讓團隊回頭修正目標。用框架整理討論，不必把每個轉換問題都歸咎於某一層。

用這個角度回頭看很多業主的抱怨就清楚了。他們常說「我的網站不漂亮，所以轉換率差」，但真正的問題往往藏在結構層與骨架層：流程太長、按鈕位置違反直覺、資訊分類讓人找不到東西。換一張好看的皮（表面層），並不會修好底下的斷層。把這五層放在心裡，你跟設計師溝通時就不會雞同鴨講，因為你講得出「問題出在哪一層」。

講一個我在專案裡反覆看到的場景。業主跟設計師在會議室裡，為了一個按鈕要不要用藍色吵了半小時，兩個人情緒都上來了。但如果用五層框架拆，你會發現他們表面在吵顏色（表面層），真正的爭點其實是「這個動作到底是不是這個頁面的主要任務」（結構層與範疇層）。把問題往下拉一層討論，答案常常自己就浮現：如果這個按鈕真的是這頁的主要任務，那它當然該是主視覺、該用主色；如果不是，它就該安靜下來。很多看起來像「美感之爭」的會議，本質都是層次沒對齊。把這五層學起來，你會發現自己吵的架少了一大半。

UI、UX 與轉換率：先找實際障礙

用常見的電商結帳情境來看：流程分成多個步驟，主要按鈕又跟次要按鈕同色，使用者就不容易判斷下一步。這類網站視覺可以很精緻，但結帳路徑仍可能卡滿讓人猶豫的設計。

處理順序可以很節制：先檢查流程能否整併、主按鈕與次要按鈕是否有明確層級、不必要的欄位能否拿掉，以及訪客結帳入口是否清楚。這些都屬於流程與互動層，也就是 UX 那一塊。實際轉換變化要以網站自己的分析與測試資料驗證，不能套用別人的固定百分比。

把這個邏輯拆開，你會看到一個清楚的分工：

• 介面影響辨識與操作：畫面層級、文字、對比與回饋，可能影響使用者能否理解下一步與信任服務。
• 整體體驗涵蓋完整任務：入口、表單、付款、錯誤處理與後續服務，都可能影響使用者是否完成任務。

介面是整體體驗的一部分，兩者共同影響結果。先用任務測試與站內資料確認障礙，再決定調整視覺、流程、內容或技術。

這裡我想補一組在表單與結帳流程上特別有用的原則，都是 UX 層面的摩擦來源，跟配色一點關係都沒有：

• 檢查欄位是否必要。刪除或合併冗餘欄位，保留完成任務或提供服務所需的資訊，並清楚標示必填與選填及蒐集用途。是否延後詢問，應依任務、資料品質與法規需求決定。
• 主按鈕要明顯到不用想。主按鈕（下一步、結帳、送出）跟次要按鈕（返回、取消）必須在顏色、大小、位置上拉開層級。當兩者長得像雙胞胎，使用者就會停下來猶豫，而猶豫是轉換率的敵人。
• 錯誤訊息要告訴人怎麼修。不要僅跳一個「輸入錯誤」，要明確講「這個欄位需要填到手機號碼的十碼格式」。把使用者從錯誤裡救出來，他才有機會走完流程。
• 進度要看得見。多步驟流程一定要讓使用者知道「我現在在第幾步、還有幾步」。不知道終點在哪，人就會想放棄。

優化轉換時，先觀察讀者在哪裡失去方向、理解錯誤或無法操作，再判斷要改流程、視覺或內容。按鈕層可參考CTA 按鈕設計，整頁路徑可看Landing Page 轉換率優化；不能預設流程總比視覺更值得先改。

UI/UX 和 SEO 的關係：內容可用性與網頁體驗

UI/UX 與 SEO 的交集，在於內容可用性與網頁體驗訊號這兩件事：前者是使用者能不能完成任務，後者是 Google 排名系統會參考的體驗指標。這也是一般設計文章最少提到、卻對你網站生意最直接的一段。

Google 主要根據可檢索的內容、連結與各種系統判斷頁面。網站結構混亂、手機按鈕難點、內容被彈窗擋住或載入太慢，會直接傷害使用者完成任務的能力；但網站分析工具裡的跳出率、停留時間，不應被直接當成 Google 的排名因素。

Google 的排名系統會使用 Core Web Vitals 等網頁體驗訊號。它包含三個具體指標：最大內容繪製（LCP）、互動到下一次繪製（INP）與累計版面位移（CLS）。這些指標有助於找出真實的體驗問題，但 Google 在 Search Central 對 Core Web Vitals 的說明中也明確指出，良好分數不保證排名，相關性仍是核心。

Google 的行動優先索引主要使用手機版內容進行索引與排名，不是因手機版設計好看就額外加分。手機與桌面應提供相當的主要內容、標題、結構化資料與可用功能；互動障礙也需要靠實機測試找出。

把 UX 做好，不是靠「停留時間越長就排名越高」這種簡化公式，而是讓相關內容更容易被讀取、操作與完成。SEO 與 UI/UX 有交集，但不能把每一個體驗指標都改寫成直接排名因果。

所以下次再有人把「做 UI/UX」跟「做 SEO」當成兩條獨立預算在搶，你心裡要有個底：它們其實是在做同一件事的不同切面。

一份實用的 UI/UX 設計流程：從研究到原型

觀念講完了，接著給你一套可以照著走的流程。這套流程沒有什麼獨門秘技，它就是業界公認的設計方法，我把它壓縮成你在中小型專案裡真的用得到的版本。這套方法一般稱為設計思考，想看未壓縮前的完整版，可以讀同理到測試的五步驟拆解，把每一步的來龍去脈補齊。

1. 研究（Research）：先搞清楚使用者是誰、他帶著什麼問題來。方法包含訪談、問卷、看現有數據。這一步最容易因為「趕時間」被跳過，但它決定後面所有設計的方向是否正確。產出物會收斂成 persona 人物誌，一個具體到有名字、有目標、有痛點的虛擬使用者。
2. 定義（Define）：把研究得到的雜訊收斂成「要解決的核心問題」與機會點。問題定義錯，後面做得再漂亮都是白做。這一步要敢砍，敢說「這個不在這次的範圍裡」。
3. 資訊架構與 user flow：規劃內容怎麼組織、使用者從進站到完成目標要經過哪些步驟。畫成 sitemap 與流程圖。這一步決定使用者「會不會迷路」。
4. 線框圖（Wireframe）：用最低的成本畫出頁面骨架，這個階段不談顏色、不談字體，僅談結構與位置。它是 UX 的主場。完整做法看 Wireframe 線框圖設計入門。線框圖最大的價值是便宜，畫錯了重畫的成本極低，所以它最適合拿來快速試錯。
5. 視覺設計（UI）：在 wireframe 上面疊配色、字體、icon、圖片，產出的高保真視覺稿就是 Mockup。到這一步，才正式進入 UI 的領域。這一步要把品牌識別、色彩心理、字體層級一起考慮進來。
6. 原型（Prototype）：以紙本、設計工具或程式模擬指定操作與回饋，可用來討論和測試流程；其擬真程度取決於要回答的問題，不能把未模擬的系統行為當成已驗證。差異與實作看 UI Prototype 原型設計全解析。
7. 可用性測試（Usability Test）：找幾個真人來用你的原型，給他一個任務（例如「幫我找到結帳按鈕並完成購買」），然後閉嘴觀察他在哪一步卡住、哪裡點錯、哪裡自言自語說「這是什麼意思」。這一步回饋的價值，常常比你自己看稿一百次還多。重點是找「目標使用者」或至少是沒參與設計的人，千萬不要僅找同事測，同事已經被同一套邏輯汙染了。
8. 交付開發與持續迭代：上線僅是一個中間點，真正的 UX 工作是上線之後看數據、持續優化那一輪才開始。

研究、結構、互動與視覺應反覆驗證。原型可能暴露任務流程的問題，視覺測試也可能發現文字層級或對比不足；不用把「先 UX、後 UI」當成不能回頭的施工順序。

怎麼評估 UI/UX 做得好不好：四個看得到的指標

「這個設計好不好用」這句話很危險，因為它太主觀，每個人都能憑感覺吵半天。比較健康的做法，是換成幾個看得到、量得到、可以前後比較的指標。底下這四個，是我在專案裡最常用、也最容易跟業主溝通的：

這四個指標要搭配看，不能僅看一個。僅看滿意度會被「好看但難用」騙過去，因為使用者第一眼會被漂亮的視覺拉高印象分數；僅看完成率，又會忽略「他雖然完成了但過程罵了一整路」的情緒成本。任務完成率與錯誤率告訴你「能不能用」，時間與滿意度告訴你「用得痛不痛苦」，兩組搭起來才是完整的判斷。

System Usability Scale（SUS）是十題問卷，可幫團隊用同一套方法追蹤受測者的主觀易用性評分。分數比較要考慮樣本、任務、招募方式和情境；不能拿不同網站或不同受眾的分數直接當成改版成效。題目可參考SUS 量表。

就算團隊很小、沒有專職研究員，這四個指標依然用得起來。非正式的質性測試可以先找少量、同一使用者群的受測者，給明確任務，計時並記錄卡點，再修正後進入下一輪。不同使用者群、任務風險與研究目的需要不同樣本，不要把「五位」當成固定門檻。真正重要的是用操作證據，取代會議室裡的個人意見與美感之爭。

新手最容易搞混的 5 個 UI/UX 觀念

我整理出五個最常見、也最影響判斷的誤解。一張表把它們一次拆乾淨：

AI 工具現在能快速生成線框圖、配色與版面變體，對加速產出很有幫助。但它產出的流程假設仍需要研究、可用性測試與專業判斷驗證，使用者訪談也不能交給模型自動下結論。想把 AI 用在 UI/UX 流程裡加速，可以參考 UI/UX 設計師必收的 ChatGPT 指令；想避開自架站常見的設計地雷，則可以看 網頁設計常見錯誤。

從使用者的眼睛看你的網站：一個五分鐘的自我健檢

你不用等到有預算請設計師，才開始檢視自己的 UI/UX。這份健檢清單，是我自己在接手任何一個網站之前，一定會先走一次的快速檢查。給自己五分鐘、打開你的網站、用手機操作，誠實回答這幾題：

• 請讓不熟悉品牌的人快速瀏覽首頁，再問他是否看懂服務對象、提供的內容與下一步。這是檢查訊息清楚度的方式；搜尋引擎能否理解與呈現頁面，仍須另查可索引內容、標題與搜尋資料。
• 從首頁到重要任務的入口是否容易辨識？點擊次數可作為檢查線索，不能把「超過三次」當成失敗門檻；請讓目標使用者實際找入口並觀察迷失位置。
• 每一頁的主按鈕，是不是一眼就能看出「下一步該點哪裡」？還是畫面上同時有好幾個一樣搶眼的按鈕在打架？
• 表單的必填欄位，每一格你都答得出「為什麼非填不可」？答不出來的，多半可以拿掉或設為選填。
• 錯誤發生時（填錯格式、必填漏掉），系統有沒有清楚告訴使用者「哪裡錯了、怎麼改」？還是僅丟一句「輸入錯誤」就放生他？
• 手機版上，所有可點的元素，大小夠不夠讓一根拇指穩穩點到？還是常常點錯旁邊的東西？

這份清單只能幫你找出值得檢查的地方。若有多題答不上來，先看操作紀錄、找目標讀者測試，再判斷問題在介面、流程、內容或技術；不能用答錯題數推算投資報酬率。

這個練習還有一個隱藏的好處：它訓練你切換成使用者的眼睛，去看自己的網站；這跟用老闆的眼睛看，會看到完全不同的東西。老闆看自己的網站，看到的是心血、是品牌、是花了多少錢；使用者看到的，僅有「這能不能幫我解決問題，而且別太麻煩」。兩種視角之間的差距，就是 UI/UX 改善的空間所在。

想入門 UI/UX，你該從哪裡開始

很多人以為入門 UI/UX 的第一步是去學一套軟體，其實不是。更重要的是建立判斷力。工具的基本操作可能很快上手，判斷力則要靠拆解與累積。下面是我會建議的學習順序：

1. 先讀觀念，不是先學工具。Nielsen Norman Group 網站上有大量免費文章，Jakob Nielsen 提出的十條可用性啟發法（heuristics）是入門必讀，它告訴你「好用的介面」背後有可依循的原則，不是純粹憑美感。例如「系統狀態要讓人看得見」「用使用者熟悉的語言，避開工程術語」「讓使用者有撤銷的餘地」這幾條，看起來像常識。
2. 先學一套能完成作品的工具。Figma 有原型與協作功能，適合用來練習畫面、流程與交接；是否需要其他工具，取決於團隊和作品類型。免費方案與協作限制應以當期官方說明核對，工具熟練也不能取代研究、內容與實作判斷。
3. 每天做拆解練習。挑一個你每天在用的 app 或網站，寫下三個「用得很順」的地方、三個「讓你卡關」的地方，並試著講出為什麼。這個練習做三個月，你的判斷力會比讀十本書都紮實。
4. 做一個屬於自己的小專案。最好的題目就是你自己的作品集網站，從研究、線框、視覺到原型，完整走一次流程。它同時是練習，也是你找工作、接案時最有說服力的成果。想用現成服務快速把作品集放上線，可以參考作品集線上製作工具比較，挑一個順手的工具開始。學習資源的完整地圖看 免費 UIUX 自學資源。

這條路沒有單一步驟的捷徑，較實際的順序是先理解使用者與問題，再學工具並反覆完成作品。走完整個流程能累積可展示的判斷與實作經驗；具體學習路徑可參考從零開始到接案的學習順序。

現在就能做的三個下一步

觀念讀再多，不如動手檢視一次自己的東西。給你三個今晚就能做的動作：

先選網站上最重要的一項任務，例如結帳或填表，分別在常見手機與桌面情境走完。記下看不懂、無法點擊或流程中斷之處，再找符合情境的人操作，確認這是否是個人觀察還是較普遍的障礙。選一項證據較充分的問題修正，並事先定義如何驗證結果。

UI/UX 不是一次到位的工程。每次用使用者的眼睛把流程重新走一遍，再用測試與數據確認，你就更接近「讓人用得舒服」的網站。轉換、回流與口碑是否改善，仍要回到實際資料持續驗證。

如果你已經有網站、也想把「用得舒服」跟「被 Google 找到」這兩件事一起做好，Whoops SEO 做的就是這一塊。我們可以陪你從使用者流程、行動呼籲、到網頁體驗訊號一起檢視。卡關時歡迎來聊聊，沒有壓力，想聊再來。