UI/UX 設計差異解析：工作流程與實用工具指南

三分鐘重點：介面是看得見的身體，體驗是感受得到的靈魂

UI/UX 設計涵蓋使用者研究、資訊架構、流程、介面、原型與測試；UI 著重介面呈現，UX 則處理完整使用體驗，兩者在實務上經常交互影響。

換個比喻你就懂了。UI 是一間餐廳的裝潢、菜單排版、餐具質感、燈光氣氛；UX 是你從訂位、推門進去、點餐、等上菜、吃飯到結帳離開的整體感受。裝潢再漂亮，如果上菜等四十分鐘、服務生全程臭臉、結帳時還被多收一筆沒講清楚的服務費，你下次絕對不會再來。裝潢與體驗，缺一不可，但它們是兩件事。

換句話說，就一件事：UI 處理產品看起來與操作起來的介面，UX 關注使用者能否順利完成任務與整體感受。兩者的範圍不同，但實務上常有重疊，也跟資淺資深無關。下面會用常見場景拆開兩種視角，再走進流程、工具，以及它們如何影響轉換與搜尋體驗。

用一個結帳頁面拆開來看：UI 設計師和 UX 設計師在想什麼

想像你正在經營一個線上商店，結帳頁的放棄率怎麼都降不下來。你找了兩個人來看這個頁面，一個是 UI 設計師，一個是 UX 設計師。他們盯著同一個畫面，腦袋裡跑的卻是完全不同的一組問題。

UI 設計師會問：那顆「立即結帳」按鈕的顏色跟頁面背景對比夠不夠、視障使用者能不能分辨？手機上拇指搆得到嗎、熱區夠大嗎？表單欄位的間距會不會太擠、容易點錯格？載入中的動畫會不會讓人焦慮？字體在手機這個尺寸下還清楚嗎、行距讀起來吃力嗎？這些問題有一個共同點：全部聚焦在「這個畫面長怎樣、使用者怎麼跟它互動」。

UX 設計師問的完全是另一回事：為什麼有四成的人走到第三步就放棄了？我們有沒有提供「免註冊直接結帳」的選項，還是強迫每個人都要開帳號？使用者填錯信用卡號的時候，系統是冷冰冰把他打回原形，還是溫柔地標出到底是哪一格錯了？整個結帳流程是三步還是七步，有沒有哪一步根本是多餘的、可以砍掉？這些問題也有一個共同點：全部聚焦在「使用者的目標是什麼、哪一個環節卡住他了」。

同一個畫面，UI 設計師看到的是像素與互動，UX 設計師看到的是流程與情緒。一個把按鈕調到最好按、最漂亮，一個則會回頭質疑「這個步驟到底該不該存在」。把這個結帳的例子記住，後面所有的差異你都會一看就懂。很多團隊吵了半天 UI 與 UX，根本問題其實是大家在看同一個畫面、卻在解不同的題。

UI 與 UX 的五個核心差異（對照表）

前面用比喻跟例子讓你抓到整體感覺，這裡收斂成一張對照表，方便你之後跟設計師、工程師、或老闆溝通的時候可以直接指著講，不用每次從頭解釋。

維度	UI 設計	UX 設計
核心關注	介面元素的視覺呈現與互動回饋	使用者達成目標的完整旅程與感受
主要產出物	視覺稿、設計系統、圖示、互動原型、Spec	人物誌、顧客旅程地圖、線框稿、研究報告、流程圖
衡量指標	視覺一致性、可達性、操作效率、美感	任務完成率、放棄率、滿意度、錯誤率
進場時間點	流程底定後，進入視覺化與細節階段	更早介入，從研究、定義問題、到上線後迭代
思考起點	「這個畫面要怎麼呈現才清楚、才好看」	「使用者為什麼來、卡在哪、接下來要往哪去」

這張表裡容易被低估的是「進場時間點」。設計不是打開軟體就開始畫畫面；使用者研究、需求釐清與流程梳理，會影響後面需要哪些畫面。前期釐清不必要的步驟，能減少後續設計與開發返工，但能省多少要看專案情境。

「衡量指標」這一列也值得留意。UI 不只談主觀美感，也可量測辨識度、錯誤率與可及性；UX 則常用任務完成率、放棄率與滿意度等指標持續檢驗。這些數據可能與轉換或搜尋表現同時變化，但不能直接證明 SEO 因果。只看畫面好不好看就結案，會漏掉使用者能否完成任務的證據。

「思考起點」那一列則點出了一個實務上很重要的分工原則。當一個設計師遇到問題，他是先問「這個畫面要怎麼呈現」，還是先問「使用者為什麼來、要往哪去」，會決定他解出來的答案落在 UI 還是 UX。兩種問法都對，但問錯層次，就會得到正確卻無效的答案。例如使用者抱怨「找不到結帳按鈕」，你若只從 UI 層去把按鈕放大變紅，可能永遠解不掉真正的痛點；真正的問題也許是整個結帳流程太長，使用者根本走不到那顆按鈕就放棄了。

三個把 UI 與 UX 搞混的常見誤解

這三個誤解常出現在客戶、設計師與產品經理的溝通裡。把它們一次講清楚，之後能省下大量雞同鴨講的時間，也能避免把預算花在錯的方向上。

誤解一：UX 是 UI 的「升級版」或「資深版」

很多人以為設計師做久了、資深了，就會自動從 UI「升等」成 UX。這是根本性的誤解。UI 與 UX 是兩個不同的專業領域，需要的能力組合完全不同。資深的 UI 設計師代表他在視覺、排版、互動細節上累積了深厚的功力，但不代表他自動具備使用者研究、心理學、實驗設計、數據分析這些 UX 的核心能力。

反過來也一樣。一個很強的 UX 研究員，可能對使用者旅程、痛點洞察瞭若指掌，但請他把一個畫面的視覺細節打磨到位，他未必做得比一個專職 UI 設計師好。這也是為什麼成熟的公司會把這兩個角色分開招募、分開評估，避免用一個「設計師」的頭銜把所有工作混在一起。

誤解二：介面做得漂亮，體驗就會跟著好

這大概是所有誤解裡最危險的一個。一個視覺極度精緻、動態超級炫炮的 App，完全可能難用到讓人想摔手機。流程設計混亂、資訊架構錯誤、關鍵功能埋在第五層選單裡，這些問題再漂亮的按鈕都救不回來。

如果網站把整筆預算砸在重新設計視覺上，卻沒有處理根本的流程問題，轉換率未必會跟著改善。使用者要找的東西找不到、表單太長、結帳步驟太多，這些都是 UX 層的問題。把 UI 當成唯一解藥，很容易花了預算卻沒有解決真正的阻礙。

誤解三：UX 只在專案前期才需要

UX 不是「做完研究、畫完旅程地圖就結束」的一次性工作。它是一個持續的循環：上線後看數據、找斷點、做假設、設計實驗、驗證、再迭代。產品只要還在服務使用者，UX 的工作就不會真正結束。這跟 SEO 的邏輯很像，都需要持續投入、持續優化，是一場長期工程，沒有所謂「做完一次就可以放著不管」這回事。

先把這四個常被搞混的設計名詞分清楚

聊 UI 與 UX 的時候，有四個名詞經常被混在一起講：Wireframe、Mockup、Prototype、Design System。它們各自對應設計流程裡不同的階段，搞混它們會讓溝通變得很卡，也容易讓你誤判一個設計師交付的東西到底做到哪一步。下面先用一張表把差異列出來，再逐一解釋。

名詞	中文	核心用途	保真程度
Wireframe	線框稿	定義頁面結構與資訊層級	低保真，通常黑白灰
Mockup	視覺稿	呈現最終的視覺樣貌	高保真，靜態
Prototype	原型	模擬互動與流程，可點擊	高保真，可互動
Design System	設計系統	統一元件與規範，確保一致	規範層，跨專案複用

Wireframe 常是前期產出，重點是頁面放什麼、放在哪，以及資訊優先序。它通常用灰階方塊與佔位文字呈現，刻意降低配色和字體的影響。好的 Wireframe 應讓團隊能辨識頁面任務、主要內容與互動路徑，不需要套用固定秒數判定。

Mockup 是在線框方向較穩定後，加上配色、字體、圖示、圖片做出的高保真靜態稿。它呈現的是「產品預計長怎樣」，但通常還不能完整操作或跑流程。把漂亮的 Mockup 當成完成品是常見誤會；它與真正能用的產品之間，還隔著互動設計、內容驗證與前端實作。

Prototype 進一步把 Mockup 串成可以點擊、可以走流程的版本。它讓你能在還沒寫任何一行程式之前，就讓真實使用者實際操作、找出流程斷點。Prototype 跟 UX 可用性測試是綁在一起的，原型設計的價值就在這裡：用最低成本驗證「這套流程到底通不通」。保真度可以從很簡陋（紙上原型）到很精緻（接近成品的高保真互動），重點是「能不能讓測試者體驗到關鍵流程」。

Design System 則是更上層的資產。它把按鈕、表單、配色、字體、間距等重複元素，整理成規範與可複用元件。價值在於一致性、維護與協作：設計師不必每次重做，工程師也有明確依據。可以從小規模的元件規範開始，等實際重複需求出現再擴充。

把這四個名詞分清楚之後，你就能更精準地跟設計師對話：要談結構的時候看 Wireframe、要談視覺的時候看 Mockup、要驗證流程的時候跑 Prototype、要確保一致性就回頭顧 Design System。每一種產出對應一個不同的決策，混在一起討論只會越講越亂。

UX 與 UI 如何交錯進行：雙軌設計流程怎麼走

很多文章會把 UI/UX 流程畫成一條單向的直線：研究、線框、視覺、交付、上線。更貼近實務的理解，是把它想成兩條會反覆交會的軌道。前期通常先釐清問題、任務與結構，但視覺探索也可能提早介入；測試結果又會回頭改動流程與介面，而非由 UX 單向交棒給 UI。

UX 軌道：先把「對的問題」找出來

UX 的起點不是畫面，是「問題」。使用者是誰、他想完成什麼、現在卡在哪、為什麼會卡？要回答這些問題，你需要的是研究方法，不是設計軟體。這個階段的核心動作包含幾項。

• 使用者研究：深度訪談、問卷、實地觀察，找出真實的使用情境與痛點。這一步的產出會直接餵養你的人物誌。
• 定義問題與需求：把研究結果收斂成「使用者要解決的核心任務是什麼」。這裡很適合套用設計思考的同理與定義階段，或用 JTBD 的角度重新看使用者的「僱用動機」。
• 顧客旅程地圖：把使用者從接觸產品到完成目標的每一步畫出來，標出情緒高低點與痛點。這份地圖是後續所有設計決策的根據。
• 資訊架構與流程圖：決定內容怎麼組織、頁面之間怎麼跳轉、一個任務要走幾步。這一步往往決定了產品是「三步搞定」還是「七步折騰」。
• 線框稿與原型測試：用最低保真、最快的方式把流程跑一遍，找幾個真實使用者做可用性測試。原型設計這一步的重點在於「驗證流程走不走得通」，好看與否是次要考量。

完成一輪 UX 探索後，團隊應該較清楚要做哪些畫面、每個畫面的任務，以及使用者可能怎麼走。UI 可以據此深入發展；若視覺與互動方案暴露新問題，流程仍要回頭修正。

UI 軌道：把對的結構，變成好看又好操作的畫面

UI 拿到 UX 階段的線框稿與流程圖之後，工作重點轉向視覺與互動。這個階段的核心動作也包含幾項。

• 設計系統與品牌視覺：建立顏色、字體、間距、元件的規範，確保整個產品視覺一致。這一步跟你的品牌色挑選、色彩心理學判斷會高度相關。
• 視覺設計：把線框稿加上配色、字體、圖示、圖片，做出高保真的視覺稿。排版細節可以參考排版設計技巧與英文字體選擇。
• 互動與微動態：按鈕點擊回饋、頁面轉場、載入動畫，這些細節決定了產品「用起來的感覺」。
• 響應式與適配：確保畫面在不同螢幕尺寸下都清楚可用，這在行動裝置佔多數流量的今天不能省。細節可以對照響應式網頁設計的觀念。
• 交付與前端協作：把設計稿、Spec、設計 token 交給工程師，並在開發階段持續校對實作成果。懂一點CSS Box Model 的設計師，跟工程師溝通會順很多。

兩條軌道在中後段交會：UI 做出來的高保真原型，會再回到 UX 手上做一次可用性測試，確認「漂亮的畫面有沒有反而破壞了原本順暢的流程」。這個循環跑個幾輪，產品才算真正準備好面對真實使用者。如果你對工具的完整地圖有興趣，市面上已有不少從研究到設計的工具鏈整理，可以挑一份跟著走一遍，會比單看工具介紹更紮實。

研究工具與設計工具分開看：UX 與 UI 各自的武器庫

工具會影響你的工作方式，但不會決定你的設計品質。這裡把工具分成兩條軸線來推薦，避免你看到一堆工具清單卻不知道哪個該用在哪個階段。

UX 研究與分析工具

UX 階段需要的是「理解人」與「看見行為」的工具，重心放在蒐集證據，畫面屬於次要考量。

• 訪談與問卷：可用線上表單蒐集回答；訪談則搭配錄音、轉錄與質性編碼。重點在於抽樣與問題設計是否合理，工具本身只是輔助。
• 行為分析與熱圖：Google Analytics 看流量與流程斷點，熱圖工具看使用者「點哪、看哪、卡在哪」。這類數據是找出放棄點最直接的證據。
• 可用性測試平台：找目標受眾實測原型，記錄他們完成任務的時間與失誤。原型愈低保真，愈能在早期發現流程問題。
• 流程圖與旅程地圖工具：把研究結果視覺化成流程圖、旅程地圖、資訊架構，這是 UX 跟團隊溝通最重要的共通語言。

如果你想把 AI 加進研究流程，例如快速整理訪談逐字稿、產出人物誌草稿、或為可用性測試設計情境腳本，可以參考我們整理過的UI/UX 設計師的 ChatGPT 指令。把 AI 當研究助理用，能幫你省下大量機械性的整理時間，但研究結論與判斷，還是要你自己下。

UI 設計與交付工具

UI 階段需要的是「把結構變成畫面」的工具，重點在精準、一致、與可協作。

• 主力的介面設計軟體：挑選支援即時協作、元件庫、版本管理與開發交付的工具。本站的介面設計工具教學示範了常見流程，但真正的選擇仍要看團隊既有工作方式與交付需求。
• 互動與動態：從按鈕轉場、動態按鈕到載入動畫，一般原型工具已能處理多數互動展示；只有需要更細緻的時間軸、狀態或真實資料時，才需要專門工具或直接用程式製作。
• 設計系統與元件管理：把顏色、字體、間距、按鈕、表單元件建成可重用的元件，確保整個產品的視覺一致。一份維護良好的設計系統，是 UI 團隊最重要的資產。
• 素材與資源：圖示網站、免費圖庫、3D 素材，這些是加速視覺產出的彈藥庫。能不能快速找到對的素材，直接影響交付速度。
• 配色與排版輔助：配色工具、色相環、色彩學觀念，這些是你做視覺判斷時的依據，讓你不至於只靠直覺下決定。

近年 AI 繪圖與生成式工具也開始介入 UI 的前期發想，從生成版面草稿、配色組合到整頁視覺探索，都跟傳統流程不同。如果你對這條路線有興趣，可以從AI 輔助網頁設計開始了解，把 AI 當成產生選項的工具，再由設計者判斷與收斂。

當 UI/UX 開始影響轉換率與 SEO：這才是老闆該在意的事

講到這裡，UI 與 UX 已經不只是「設計部門的事」。它們會直接影響任務完成率與轉換，也可能透過行動可用性、載入與互動體驗影響搜尋表現。

先講轉換率。使用者從搜尋引擎點進網站，到完成詢問、註冊或結帳，中間每一步都涉及 UX。如果他在某一頁卡住、看不懂或找不到下一步，就可能離開。UI 的細節，例如行動呼籲按鈕是否清楚、表單是否易填，會影響他能否順利完成動作。把兩層都顧好，才有機會把流量轉成網站詢問單。

再講 SEO，這是很多人沒想到的連動。不要把 Analytics 裡的跳出率或停留時間直接當成 Google 排名公式；單次「點進去又馬上離開」也不能證明頁面沒有滿足需求。不過，若頁面難以閱讀、操作或載入，確實可能同時傷害使用者完成任務的機會、自然連結與搜尋成效，因此仍值得改善。

換句話說，UX 與 SEO 可能出現共同問題，但兩者不能畫成單一因果。跳出率偏高、停留時間偏短，只能當成調查線索；行動版難用、頁面載入太慢、元素跳動或互動遲鈍，則可透過實測找出原因。Google 將 Core Web Vitals 用於排名系統，但官方在 Understanding page experience in Google Search results 也提醒，取得良好分數不保證排名第一，內容相關性仍更重要。

把 Core Web Vitals 拆開來看，你會發現這三個指標根本就是 UI/UX 的健康檢查表。LCP（Largest Contentful Paint）衡量頁面主要內容載入完成的速度，背後牽涉的是圖片最佳化、字體載入策略、伺服器反應時間，這些都是 UI 與前端要共同處理的事。INP（Interaction to Next Paint）衡量使用者與頁面互動後、到畫面更新之間的流暢度，按鈕按下去多久有回饋、選單展開會不會卡頓，都會在這裡現形。CLS（Cumulative Layout Shift）衡量頁面元素的非預期跳動，圖片沒設固定尺寸、字體載入晚導致文字位移、廣告插入把按鈕擠走，這些都會讓使用者點錯，是典型的 UI 細節問題。

這三個指標的共通點，是從載入、互動與視覺穩定性觀察頁面體驗的一部分，但它們不等於完整的 UX，也不能單獨預測轉換或排名。你可以透過 Google Search Console 查看網站的 Core Web Vitals 分組資料，再用 PageSpeed Insights、瀏覽器效能工具與真實任務測試定位原因，會比盲目改版有效率得多。

UI/UX 不是網站完成後才補的裝飾。如果正在規劃著陸頁或產品頁，應在前期一起考量任務、內容、可及性與搜尋需求。想避開常見設計地雷，也可以對照自架網站常見錯誤。

把「好不好用」變成數字：UX 成效量化的四組指標

前面那張對照表列了「衡量指標」，但只給你「任務完成率、放棄率、滿意度」幾個詞。真要動手，多數團隊會卡在「這些數字到底怎麼測、多少算及格」。下面把實務上常用的四組指標拆開，每一組附上它適用的情境，你才知道該挑哪一組，而不是把所有指標全塞進同一份報告。

第一組：任務層的行為指標

這組指標來自使用者操作與紀錄，但任務設計、樣本與判定方式仍會影響結果。完成率是最直白的：給一群使用者同一個任務，例如「找到藍色版本並加入購物車」，看有多少比例完成。完成率偏低是流程或介面可能有障礙的線索，再搭配任務時間、錯誤數與訪談找原因，不能只靠一條通用及格線下結論。

第二組：主觀滿意度的標準化量表

問卷不是隨便寫幾題就好。SUS（System Usability Scale，系統可用性量表）由十題正反向敘述組成，換算後落在 0 到 100 分，適合比較同一產品不同版本，或搭配相近情境的基準資料判讀。分數不是百分比，也沒有脫離產品、使用者與任務情境後仍通用的及格線，相關判讀原則可見 Sauro 與 Lewis 於 2012 年出版的《Quantifying the User Experience》。類似工具還有 CSAT（單次任務滿意度）、SEQ（單題難易度自評）、NPS（Net Promoter Score，淨推薦分數）。NPS 衡量的不只是好不好用，拿來當 UI 改版的單一指標會過於鈍感。

第三組：行為訊號的線上追蹤

上線之後，從分析工具撈行為數據。跳出率、停留時間、捲動深度、漏斗各步驟的留存比例，這些數字能看到「使用者用腳投票」的結果。優點是樣本大、不用打擾使用者，缺點是只能告訴你「在哪裡流失」，不能告訴你「為什麼」。把這組數據跟熱圖、工作階段錄影搭配，才能把「在哪裡」推回「為什麼」。

第四組：A/B 測試與上線後驗證

想驗證「改了按鈕位置，轉換率到底有沒有提升」，隨機對照的 A/B 測試是常見方法：流量隨機分組、事先定義主要指標與停止規則，再檢查差異和不確定性。低流量產品也可搭配前後比較、可用性測試與質性研究，但要誠實面對因果推論的限制。少量參與者適合快速發現明顯問題，卻不能保證涵蓋所有族群與流程；樣本數應依研究目的、受眾差異與問題複雜度調整。

這四組指標不是四選一，而是彼此互補。沒有行為數據，滿意度分數會失真；沒有可用性測試，A/B 測試會找不到切入點。實務上建議團隊至少同時跑兩組：一組回答「現況多糟」，另一組回答「改完有沒有比較好」。把量化的數字當成決策的護欄，而不是讓直覺或老闆的偏好直接拍板。

重新設計的六個反模式：為什麼改版反而讓轉換率往下掉

很多團隊把「重新設計」當成解藥，結果上線後跳出率上升、老客戶抱怨找不到功能。問題通常不在設計做得不漂亮，而是改版過程踩進了常見的反模式。下面這六個，你下次開改版會議可以直接逐一檢查。

反模式一：沒有先量基準線

沒有量改版前的轉換率、任務完成率、熱點頁面，改版後就很難說清「到底變好還變壞」。很多團隊改版前只憑感覺覺得「現在版面太舊」，改版後也只看「好像比較新」。改版前應涵蓋完整業務週期，記錄關鍵指標、流量來源與異常事件；需要多長時間取決於流量、季節性與決策風險。

反模式二：一次改太多變數

新版同時改了資訊架構、配色、按鈕位置、字體，還把註冊流程從三步變兩步。上線後轉換率掉了，你很難知道是哪一個改動造成的。一次只動一個變數較容易建立因果；如果非得一次改多個，至少分階段部署並事先設定觀察指標與回復條件。每個階段要觀察多久，應由流量與完整業務週期決定。

反模式三：為了美感犧牲熟悉度

既有使用者腦袋裡有一套肌肉記憶：搜尋框在哪、選單怎麼展開、結帳按鈕長怎樣。改版把這些位置全部移走，使用者要重新學一次，這段學習曲線會直接吃掉轉換率。大型產品即使做了視覺更新，核心操作路徑的相對位置往往會刻意保留，就是為了不打破既有使用行為。如果你為了「看起來更現代」而移動了一個每月有大量使用者在用的關鍵按鈕，先問自己這個移動解決了什麼真實問題；答不出來，就別動。

反模式四：用設計師的品味取代使用者研究

「這樣比較好看」這類主觀判斷是最危險的一句話。設計師的訓練讓他對美感與排版極度敏感，但使用者的真實任務情境往往跟設計師預期不一樣。再漂亮的稿子，沒有經過至少一輪真實使用者的可用性測試，就只是主觀。改版決策應該被使用者研究的證據支撐，至少能在會議上回答「我們訪談了幾位使用者、他們在哪個步驟卡住、這個改動是怎麼回應他們的痛點」。

反模式五：只看上線第一週數據

改版剛上線時，數字可能因老使用者適應、新舊版交接或行銷活動而波動。常見錯誤是看到短期轉換率下降就立刻回復，或看到單一指標上升便宣告成功。正確做法是事先約定涵蓋業務週期的觀察期、主要指標與安全護欄；若出現結帳失敗、可及性阻礙或資料異常，則應立即處理。

反模式六：沒有退場機制

改版前先想好「什麼情況下要回滾到舊版」。回滾條件要事先寫下來：哪些指標掉到哪個區間就觸發、由誰決定、回滾需要多少時間。沒有退場機制的改版，等於把整個產品押在一個無法撤回的決定上。成熟團隊會把舊版保留成可快速切換的狀態，並讓部署流程支援漸進式導流（先導入少量流量、觀察無異常再放大），這比一次性全量上線安全得多。

這六個反模式的共通點是：它們都讓「重新設計」變成不可逆的賭注。改版本身沒有錯，錯的是沒有證據、沒有控制、沒有退場機制的改版。把改版當成一場嚴謹的實驗來設計，團隊才有機會在每次改版裡真的學到東西，而不是每改一次就掉一次轉換。

當美觀、可用、可及、效能互相打架：一個設計取捨的決策框架

設計到了中後期，問題常常不是「做不出好看的方案」，而是「四個都對的原則互相衝突」。你想加一支漂亮的進場動畫，但它會拖慢互動回饋、傷到 INP；你想用極淺灰的 placeholder 看起來更優雅，但它可能讓低視力使用者完全讀不到。光講「兼顧」沒用，你必須有一套取捨的優先序，否則每次爭論都會被最大聲的那個人贏走。

可以帶進會議室的優先序原則是：先確認任務能否完成，再看可用性、可及性、效能與美感。實際排序會依產品情境調整，但不能用美感掩蓋無法結帳、無法閱讀或無法操作等核心阻礙。

把這個排序套進常見的衝突場景，答案幾乎不言自明。第一種是美觀對上可用性。一支炫炮的選單展開動畫在設計稿上看起來很厲害，但如果讓使用者每次點選單都要等零點幾秒，那個等待會累積成挫敗感。處理方式：把動畫限縮在不影響主要任務路徑的邊緣位置，或把時長壓到使用者察覺不到的程度；重要操作按鈕則做到一點下去就立即回饋，這個回饋不需要動畫，只需要即時。

第二種是可用性對上可及性，這組最容易被忽略。只有滑鼠 hover 才展開的選單，可能讓鍵盤與觸控使用者無法操作；只靠顏色區分狀態，也會排除部分色覺使用者。WCAG 2.2 提供可檢驗的成功準則。實務上可在顏色之外加文字或圖示，並確保 hover 互動也能用 focus、點擊與觸控操作。

第三種是效能對上視覺。你想用一張大圖當首屏背景，但它會把 LCP 拖垮、讓使用者多等一秒。這裡的判斷不是「視覺不重要」，而是「視覺不該以犧牲載入體驗為代價」。具體做法：壓縮與正確格式（WebP、AVIF）、給圖片固定尺寸避免 CLS、用漸進式載入或低品質佔位圖先給視覺結構、把影響首屏的資源前移、不影響首屏的延後載入。這幾個手法在 Core Web Vitals 的脈絡裡會講得更細，關鍵是把它們列進設計交付前的檢查表，而不是等工程師上線後才回頭補救。

第四種衝突藏在團隊內部，是個人品味對上使用者證據。設計師 A 覺得圓角好看、設計師 B 覺得直角好看，若沒有共同原則，很容易淪為資歷與音量之爭。可把不影響任務的視覺偏好收進設計系統，真正會影響使用者行為的決策，再用可用性測試、實驗或其他證據驗證。

這個取捨框架的重點不在死背優先序，而在把「未明說的判斷」變成「可以拿出來討論的依據」。下次卡在某個設計爭論時，把這四個維度畫在白板上，請每個人指出自己支援的方案落在哪一個維度。很多看起來劍拔弩張的爭論，其實是大家在不同維度上各自有理，只要對齊到同一個優先序，共識就會自動浮現。

UX 這個詞是怎麼來的：一個被誤用了三十年的名詞

順帶補一個很多人不知道的背景。「User Experience」這個詞，是認知科學家 Don Norman 在 1990 年代初於 Apple 任職時提出的。他當時的職稱叫做「User Experience Architect」，是業界第一次把這個角色正式放進組織裡。他提出這個詞的原意，其實比今天多數人理解的更廣：不只是介面好不好用，而是涵蓋了產業、圖形、介面、實體互動、甚至使用手冊在內的「整體感受」（見他在 Nielsen Norman Group 的〈User Experience 定義〉一文）。

也就是說，UX 從一開始就是一個「大傘」的概念，UI 只是這把傘底下的一塊。但這幾年實務上，UI 與 UX 被拆成兩個專業、兩種職位，這個分工是合理的，因為兩者需要的能力確實不同。只是我們在講「UX」的時候，心裡要記得它的原意是「整體體驗」，而不只是「畫線框稿的那個人」。這個觀念清楚了，你跟設計團隊溝通時才不會把兩個詞用反。

UX 評估好不好用，業界有一套流傳很廣的標準，就是 Jakob Nielsen 提出的十條可用性啟發原則（10 Usability Heuristics），涵蓋了系統狀態可見性、真實世界對應、使用者控制與自由、一致性、防錯、辨識而非回憶等原則。這套原則從 1994 年提出到現在，仍然是評估一個介面「有沒有基本的可用性」最常被引用的檢查表，原文是 Nielsen Norman Group 的 10 Usability Heuristics for User Interface Design。不管你用的是哪一套設計工具，這十條都值得當成你檢視自己作品的底線。

而談到可用性，就不能不談可及性（Accessibility）。一個介面如果只對視力正常、操作靈活的使用者友善，那它的 UX 就還稱不上完整。色彩對比、鍵盤導覽、螢幕閱讀器支援、文字替代，W3C 的 Web Content Accessibility Guidelines（WCAG）2.2 都有清楚的成功準則。適用的法定要求會因地區與服務類型而異；語意清楚的 HTML 也有助於搜尋引擎理解內容，但不能把符合 WCAG 說成獨立的排名加分。

想入行，還是想找人做？兩條路的務實建議

讀到這裡，如果你的身分是「想學 UI/UX 的人」，跟「想找人做網站的老闆」，你關心的重點完全不一樣。下面分開給建議。

如果你想自學 UI/UX 設計

入門最實際的順序是：先建立 UX 的觀念與研究方法，再學 UI 的視覺與工具操作。順序顛倒的人很容易陷入「工具用得很熟、但做出來的東西不好用」的窘境。資源方面，我們整理過一份完整的網頁設計自學路線圖，以及一份免費 UIUX 自學資源清單，從基礎觀念到工具實作都有涵蓋，建議照著路線走，不要一開始就鑽進單一工具的細節裡。

實作比只看教學更能暴露理解缺口。看完觀念，可以找一個日常在用的網站或 App，拆解流程、找出卡點，再動手畫一版改進的線框稿。持續做「拆解、假設、重做」的練習，也能累積作品集網站的素材。一份好的作品集，與其只堆砌完成度高的視覺稿，不如交代問題、研究方法、假設、測試與迭代結果；別把沒有真實研究的練習案寫成已驗證成效。

工具的選擇上，初期不要貪多。先把一套主力工具摸熟，能獨立產出線框稿、視覺稿與可點擊原型，再依團隊需要擴充。研究方法也是一樣，先把深度訪談與可用性測試練扎實，比同時學十種方法但都半生不熟來得有用。

如果你想找設計師或設計公司

找設計服務的時候，最重要的第一個問題該問的是「你們的流程裡有沒有 UX 階段」，而非單純問「報價多少」。一家上線前會做使用者研究、會畫流程圖、會做可用性測試的團隊，跟一家直接打開軟體開始畫漂亮畫面的團隊，產出來的東西會差很多。關於怎麼挑、怎麼避免踩雷，延伸閱讀可以看網頁設計公司推薦與挑選指南。

預算的拿捏也是一門學問。純視覺改版跟「從流程到視覺完整重做」的價位會差好幾倍，你需要先釐清自己的問題是出在 UI 層還是 UX 層，才不會花大錢卻解錯題。關於不同類型網站的報價結構與省錢策略，我們在網頁設計費用指南裡有完整的拆解。判斷的重點永遠是：先搞清楚你要解的是哪一層的問題，再決定要買哪一層的服務。

六步行動方案：今天就開始檢視你的 UI/UX

觀念讀完，最重要的是動手。下面把整套流程收斂成六個你今天就能開始做的步驟，不管你是設計師、產品經理、還是老闆都適用。

1. 挑一條核心流程，自己走一遍。結帳、註冊、詢問表單都行，用新手的心態從頭走到尾，記下每一個讓你猶豫、卡住、想放棄的點。這份筆記就是你 UX 優化的第一份清單。
2. 先找少量目標受眾做可用性測試。不用正式實驗室，請參與者在你面前操作並說出疑問。這適合快速找出明顯障礙，但受眾差異大或流程複雜時，仍要分組增加樣本與輪次。
3. 看數據找斷點。用分析工具看漏斗各步驟的流失與錯誤，但跳出率高不一定代表頁面有問題。數據先告訴你「哪裡值得查」，再用錄影、訪談或可用性測試找「為什麼」。
4. 先處理阻礙任務的問題。流程與視覺不是永遠固定的先後關係；先修會阻止使用者完成任務、閱讀或操作的問題，再依證據迭代流程與畫面。
5. 建立最基本的設計系統。把顏色、字體、按鈕、間距固定下來，就算只是一份簡單的文件也好。一致性是信任感的來源，也是團隊協作的基礎。
6. 上線後持續追蹤與迭代。檢查頻率依產品變更、流量與風險決定；重大改版後提高觀察密度，穩定期則排入例行研究與數據檢查。

UI 與 UX 的差異，說到底就是兩個不同層次的關懷：一個關心畫面好不好操作，一個關心使用者好不好把事情完成。把它們分清楚，你才能真正對症下藥，避免拿著 UI 的預算去解一個根本屬於 UX 的問題。記得那個餐廳的比喻：裝潢再美，上菜慢、服務差，客人也不會再上門。畫面與體驗缺一不可，但順序永遠是體驗在先、裝潢在後。

如果你正在煩惱網站轉換率一直上不去，問題很可能出在使用者在某個環節被卡住了，跟流量不夠或設計不夠美關係都不大。把這六步走一遍，你會比任何顧問都更先看見答案。這條路沒有捷徑，也沒有一次到位的特效藥，但每修掉一個斷點，你的產品就會離使用者更近一步。

開始吧，從你自己走一遍那條核心流程開始，那就是一切優化的起點。當你願意用使用者的眼睛重新看自己的產品，UI 與 UX 的界線就不再是名詞之爭，而是你每天都在做的具體決策。