UX設計研究方法怎麼選？網站改版從訪談到測試的判斷指南

UX設計是什麼？和 UI 設計差在哪？

UX設計關心使用者能不能順利完成任務，UI設計關心介面如何呈現與操作。兩者會一起工作，但判斷標準不同：UX看流程是否合理，UI看畫面是否清楚可用。

項目	UX設計	UI設計	常見產出
核心問題	使用者為什麼卡住	介面看不看得懂	User Flow、Journey Map、測試報告
主要焦點	需求、情境、流程、任務完成	版面、元件、狀態、互動呈現	Wireframe、UI稿、Prototype
判斷依據	研究與使用者測試	視覺一致性與操作可理解性	設計規格、元件狀態

UX 關心的是使用者如何完成任務

UX設計會追問使用者從進站、理解內容、比較選項到完成轉換的每一步是否順。網站改版時，真正的問題常不在按鈕顏色，而是資訊順序、導覽命名或表單流程讓人中斷。

UI 關心的是介面如何被看見與操作

UI設計負責把流程變成可操作的介面，包括文字層級、按鈕樣式、表單狀態、RWD呈現與互動回饋。好的UI能降低理解成本，但如果流程本身錯了，再漂亮的介面也救不了轉換率。

為什麼實務上常寫成 UI/UX？

台灣許多團隊人力有限，同一位設計師常要處理研究、流程、Wireframe、Prototype與UI稿。職稱混在一起很常見，但做決策時仍要分清楚：UX先回答為什麼這樣設計，UI再回答如何讓介面被正確使用。

UX設計為什麼需要使用者研究與測試？

使用者研究用來找出需求、痛點與情境，使用者測試用來驗證設計是否真的可用。沒有研究與測試，產品決策容易只剩內部猜測，最後把預算花在錯的地方。

問題	常見風險	適合方法
不知道使用者為何不購買	只改視覺，沒有碰到真正阻礙	訪談、漏斗分析、易用性測試
會員註冊流失高	內部以為欄位合理，使用者覺得太麻煩	任務測試、表單觀察、A/B Testing
網站導覽常被抱怨	分類用公司語言，不是使用者語言	Card Sorting、Tree Testing

研究解決「我們該做什麼」

使用者研究偏探索，適合在需求還不清楚、產品方向有爭議、網站改版前使用。它能找出使用者的決策原因、比較方式與痛點，避免團隊只用自己的習慣設計。

測試解決「這樣設計有沒有用」

使用者測試偏驗證，適合在有流程、Wireframe或Prototype之後進行。測試時不要問「你喜歡嗎」，要讓使用者完成任務，觀察他在哪一步停住、誤解或放棄。

UX方法不是越多越好，而是要選對時機

小型網站不一定需要完整研究流程，但一定要知道現在缺的是探索資料還是驗證證據。我的判斷是，很多專案失敗不是沒做UX，而是拿錯方法回答錯問題。

UX設計流程中，每個階段該用哪些研究方法？

UX流程通常可分為探索、定義、設計、驗證與迭代。每個階段需要的資料不同，研究方法、測試方法與產出物也不應混用。

階段	要回答的問題	常用方法	產出物
探索	使用者是誰，痛點是什麼	訪談、問卷、觀察、競品分析	研究筆記、需求摘要
定義	哪些問題最值得先解	Persona、Journey Map、Affinity Mapping	問題陳述、優先級
設計	流程與介面要怎麼安排	User Flow、Wireframe、Prototype	流程圖、線框稿、原型
驗證	使用者能不能完成任務	Usability Testing、Tree Testing、A/B Testing	測試報告、改善清單
迭代	修正後是否更好	Analytics、熱圖、回訪測試	版本紀錄、成效比較

探索階段：先理解使用者與問題

探索階段適合用使用者訪談、觀察與問卷。目標不是立刻畫畫面，而是找出使用者需求、使用場景、決策阻礙與目前解法。

定義階段：把資料整理成可設計的問題

訪談與觀察資料需要被整理成主題、族群與痛點優先級。Persona、Journey Map與Affinity Mapping的價值，在於讓產品經理、設計師與前端工程師對齊同一個問題。

設計階段：把假設轉成流程與原型

User Flow用來安排任務路徑，Wireframe用來決定資訊層級，Prototype用來模擬互動。這一階段最怕直接進UI細節，卻還沒確認使用流程是否合理。

驗證階段：測試設計是否真的可用

驗證階段要讓使用者操作，而不是只看設計稿給意見。易用性測試可以抓出卡點，Tree Testing能檢查資訊架構，A/B Testing可比較兩個版本的表現。

迭代階段：根據資料修正體驗

上線後的UX設計仍要看資料回饋，例如轉換率、表單完成率、站內搜尋、客服問題與熱圖。修正要回到具體行為，不要只憑個人偏好換版面。

常見 UX 使用者研究方法有哪些？各適合什麼情境？

UX使用者研究方法主要用來理解需求與行為，常見包含訪談、問卷、觀察、情境訪查、日記研究與競品分析。選法要看你需要深度原因、廣泛傾向，還是真實情境。

使用者訪談 User Interview

用途是理解動機、痛點、決策原因與使用脈絡。適合新產品探索、網站改版前訪談既有客戶，產出物通常是訪談摘要、洞察主題與需求假設。

適合探索動機、痛點與決策原因

訪談適合問「你上次為什麼沒有完成購買」「你怎麼比較方案」。好的訪談會追問真實經驗，而不是讓受訪者想像理想功能。

不適合直接推估全市場比例

訪談樣本通常不大，不應拿來宣稱多數使用者都這樣想。若要看比例，應搭配問卷或產品資料。

問卷調查 Survey

問卷適合收集較大量的傾向、需求排序與滿意度訊號。它不適合追深層原因，問題設計也很容易引導答案；產出物通常是統計摘要與分群線索。

使用者觀察 Observation

觀察適合發現使用者說不出來的行為，例如操作習慣、跳過資訊、誤點按鈕。它常用在實體服務、後台系統、電商結帳流程與高頻工作流程。

情境訪查 Contextual Inquiry

情境訪查是在使用者真實環境中看他如何完成任務。適合B2B、內部系統與複雜工作流程；不適合只想快速確認文案或單一按鈕表現的情境。

日記研究 Diary Study

日記研究適合追蹤跨天、跨週的行為，例如學習工具、健康產品或訂閱服務。它能看到長期動機變化，但招募與維持填寫品質的成本較高。

競品分析 Competitive Analysis

競品分析用來理解市場慣例、資訊呈現與功能差異。它適合在網站規劃與產品定位早期使用，但不能把競品做法直接當成使用者需求。

方法	適合解決	不適合	產出物
訪談	動機、痛點、決策原因	推估市場比例	訪談洞察、需求假設
問卷	大量傾向、排序	深度脈絡	問卷分析、分群線索
觀察	實際行為與卡點	抽象品牌偏好	行為紀錄、問題清單
日記研究	長期行為變化	短期快速決策	時間序列紀錄

常見 UX 使用者測試方法有哪些？各適合什麼情境？

使用者測試用來驗證設計是否可用，常見方法有易用性測試、任務測試、遠端測試、A/B Testing、五秒測試、樹狀測試與點擊測試。質性測試找原因，量化測試比表現。

易用性測試 Usability Testing

易用性測試觀察使用者是否能完成指定任務。適合測試Prototype、網站改版、會員註冊與後台流程；產出通常包含問題嚴重度、發生情境與改善建議。

任務導向測試 Task-based Testing

任務導向測試會設定明確任務，例如「找到退貨政策」或「完成結帳」。它比單純問感受更可靠，因為能看到使用者是否真的理解導覽與流程。

遠端使用者測試 Remote Testing

遠端測試適合受測者分散、時間有限或產品已可線上操作的情境。若任務複雜，主持人要特別注意錄影、螢幕分享與口述流程，否則容易漏掉卡點原因。

A/B Testing 和 UX測試差在哪？

A/B Testing比較兩個版本的轉換表現，適合已有穩定流量的頁面。它能回答哪個版本較好，但通常無法單獨解釋為什麼較好，應搭配訪談、熱圖或易用性測試判讀。

五秒測試 Five-second Test

五秒測試適合檢查首頁首屏、活動頁或產品頁的第一印象。它能看出使用者是否快速理解主張、對象與下一步，但不適合驗證完整流程。

樹狀測試 Tree Testing

Tree Testing用來檢查資訊架構是否找得到。當網站分類很多、導覽層級混亂、使用者常找不到內容時，先測分類樹通常比直接重畫介面更有效。

點擊測試 First-click Testing

點擊測試檢查使用者第一下會點哪裡。它適合評估導覽、CTA位置與任務入口；如果第一步走錯，後面的流程再順也可能失去轉換。

測試方法	資料型態	適合情境	主要限制
易用性測試	質性	找操作卡點	不代表全站比例
A/B Testing	量化	比較版本表現	需要足夠流量
Tree Testing	質性與量化皆可	驗證分類與導覽	不測視覺呈現
五秒測試	質性	檢查第一印象	不測完整任務

Persona、Journey Map、Card Sorting 這些 UX 方法怎麼用？

Persona、Journey Map、Card Sorting與Affinity Mapping都是把研究資料轉成設計決策的工具。它們的價值不在圖表漂亮，而在幫團隊知道該優先處理哪個使用者、哪段流程、哪種資訊結構。

Persona：用來對齊目標使用者，不是寫故事人設

Persona適合在使用者類型明顯不同時使用，例如新手買家與熟客的需求差很多。不需要為了交付文件硬做Persona；如果沒有研究資料，只會變成想像出來的人物卡。

Journey Map：用來找流程斷點與情緒落差

Journey Map適合整理使用者從接觸品牌、比較方案、下單到售後的完整路徑。它特別適合網站改版、客服問題多或跨部門流程混亂的情境。

Card Sorting：用來整理分類、選單與資訊架構

Card Sorting適合內容多、分類難、導覽常被抱怨的網站。它能幫團隊理解使用者如何把內容分組，但不適合拿來決定視覺風格或文案語氣。

Affinity Mapping：用來整理訪談與觀察資料

Affinity Mapping適合在研究資料很多時，把相似觀察歸成主題。它的重點是從零散意見中找模式，避免會議被最大聲的人帶走。

方法	何時需要	何時不需要
Persona	使用者族群差異會影響功能與文案	沒有研究資料，只想做簡報
Journey Map	流程跨多個接觸點	只調整單一頁面細節
Card Sorting	分類、選單與導覽需要重整	問題主要在視覺或載入速度
Affinity Mapping	研究資料多，需要找共通模式	只有少量明確問題待修

不同產品情境下，UX方法應該怎麼選？

UX方法要依產品階段、問題類型、資料需求與時間預算選擇。新產品先做探索，既有網站先找卡點，轉換率問題則要結合任務測試、漏斗資料與版本實驗。

新產品還不確定需求時

如果你還不知道使用者真正痛點，優先用訪談、競品分析與低保真原型測試。不要太早投入完整UI稿，否則團隊容易愛上自己畫出來的方案。

既有網站轉換率不好時

如果網站有流量但轉換率不好，先看Analytics、熱圖與關鍵頁任務測試。需要進一步處理CTA時，可參考CTA按鈕設計，但按鈕通常只是整段決策流程的一部分。

使用者常找不到功能或內容時

如果使用者找不到服務、規格、價格或文章，優先做Card Sorting、Tree Testing與站內搜尋分析。這類問題多半是資訊架構與命名問題，不是單純把選單放大。

表單、註冊或結帳流程流失很高時

會員註冊與電商結帳流程適合用任務測試、漏斗分析與A/B Testing。若是電商網站，也要檢查信任訊號、運送資訊、付款步驟與錯誤提示，可延伸閱讀電商轉換設計。

內部對設計方向沒有共識時

當產品經理、業務、設計與工程各有看法，先用研究摘要、User Flow與Prototype把討論拉回使用者任務。我看過不少專案卡住，不是缺創意，而是缺一份大家願意承認的證據。

情境	優先方法	輔助資料	產出
新產品探索	訪談、競品分析	初步問卷	需求假設、原型方向
網站改版	易用性測試、熱圖	搜尋與流量資料	改版優先級
導覽混亂	Card Sorting、Tree Testing	站內搜尋字詞	資訊架構
結帳流失	任務測試、A/B Testing	漏斗分析	流程修正清單

UX研究與測試會產出哪些文件？

UX產出物是把研究、流程與測試結果交給團隊執行的文件。常見包含研究報告、Persona、Journey Map、資訊架構、User Flow、Wireframe、Prototype與Usability Test Report。

使用者研究報告

研究報告記錄研究目的、對象、主要發現、洞察與建議。它應該讓決策者知道下一步該改什麼，而不是堆滿訪談逐字稿。

使用者旅程圖

Journey Map整理使用者在不同接觸點的任務、情緒、痛點與機會點。它適合跨部門討論，尤其是網站、客服、銷售流程彼此影響時。

資訊架構與 User Flow

Information Architecture決定內容如何分類與導覽，User Flow則描述使用者完成任務的路徑。兩者對SEO與轉換都重要，內容型網站也可搭配CMS選擇檢查後續維護彈性。

Wireframe 與 Prototype

Wireframe處理資訊層級與版面結構，Prototype用來測試互動與流程。原型不一定要精美，但要足以讓使用者完成測試任務。

Usability Test Report

測試報告應包含任務、觀察、問題嚴重度、影響範圍與改善建議。好的報告會把「某人不喜歡」轉成「在哪個任務、因為什麼線索不足而失敗」。

產出物	用途	主要使用者
研究報告	整理需求、痛點與建議	老闆、產品經理、設計師
Persona	對齊主要使用者類型	產品、行銷、內容團隊
Journey Map	找流程斷點	跨部門團隊
User Flow	描述任務路徑	設計師、前端工程師
Wireframe	規劃版面與資訊層級	設計師、PM、客戶
Prototype	測試與溝通互動	使用者、設計與工程團隊
Usability Test Report	記錄問題與修正優先級	產品、設計、工程

UX設計師一定要會寫程式或前端嗎？

UX設計師不一定要會寫程式，但要理解基本前端限制、RWD行為與設計交付語言。懂工程限制能讓設計更容易落地，也能減少與前端工程師溝通時的落差。

不一定要成為工程師，但要懂基本前端限制

UX設計師至少要理解HTML結構、CSS排版、RWD斷點、表單狀態與載入速度對體驗的影響。像Core Web Vitals這類效能指標，會直接影響使用者等待與操作感受。

UX設計與前端工程如何協作？

協作時要把流程、狀態、錯誤訊息、空狀態與RWD變化交代清楚。只交一張漂亮畫面，前端工程師仍需要猜互動規則，最後很容易做出與設計意圖不同的體驗。

設計交付時要包含哪些規格？

設計交付應包含頁面目的、User Flow、元件狀態、表單驗證、錯誤提示、RWD規則、內容邊界與追蹤事件。若是小型企業網站，也要先判斷自建或外包的協作成本，可參考自架網站與外包網站的取捨。

能力層級	需要程度	實務用途
基本前端概念	建議具備	判斷設計能否實作
Figma與Prototype	通常需要	做設計交付與測試
完整程式開發	依職務而定	小團隊或混合職缺較常要求

UX研究方法常見錯誤：什麼情況下不該用？

UX方法都有使用邊界，訪談、問卷、易用性測試與A/B Testing不能互相取代。方法誤用會讓團隊得到看似有資料、其實無法支持決策的結論。

只問使用者喜不喜歡

喜不喜歡容易受個人偏好影響，對設計決策幫助有限。修正方式是設定任務，觀察使用者是否能完成，並追問他如何理解頁面資訊。

用太少樣本做量化結論

少量訪談可以找問題，不能直接推估比例。修正方式是把訪談當成假設來源，再用問卷、產品資料或實驗驗證範圍。

沒有任務情境就做易用性測試

如果沒有任務，受測者只能憑印象評論畫面。修正方式是設計貼近真實情境的任務，例如比較方案、找到規格、完成註冊或送出詢價。

把 A/B 測試當成所有 UX 問題的答案

A/B Testing適合比較版本，不適合探索未知原因。修正方式是先用質性研究找出可能問題，再用A/B Testing驗證改動是否帶來更好的轉換率。

錯誤	風險	修正方式
只問喜不喜歡	得到偏好，不知道任務能否完成	改成任務測試
小樣本做量化結論	誤判市場比例	搭配問卷或產品資料
問卷題目引導答案	資料看似整齊但失真	改寫中立題目並先小規模試填
只看A/B結果	知道哪個贏，不知道原因	搭配訪談、熱圖與測試觀察

FAQ

UX設計常見問題多半圍繞UI/UX差異、方法選擇、工具、前端協作、作品集與職涯。這些問題可以回答，但不應取代研究與測試方法本身。

UX設計和 UI設計差在哪？

UX設計關心使用者能不能順利完成任務，包含需求、流程、資訊架構與測試。UI設計關心介面如何呈現與操作，包含版面、元件、狀態與視覺一致性。實務上兩者常合作，但判斷標準不同。

UX設計一定要做使用者訪談嗎？

不一定。當你需要理解動機、痛點與決策原因時，訪談很有價值；如果只是確認分類是否找得到，Tree Testing或Card Sorting可能更適合。方法要看問題，不是每個專案都要從訪談開始。

使用者研究和使用者測試有什麼不同？

使用者研究偏探索，回答使用者是誰、需要什麼、為什麼卡住。使用者測試偏驗證，回答現有設計能不能被完成任務。研究常在設計前做，測試常在Wireframe、Prototype或上線頁面後做。

UX設計常用的方法有哪些？

常見UX設計方法包含使用者訪談、問卷、觀察、情境訪查、競品分析、Persona、Journey Map、Card Sorting、User Flow、Wireframe、Prototype、易用性測試、A/B Testing與Tree Testing。

什麼時候該用問卷，什麼時候該做訪談？

想理解原因、情境與決策過程時，優先做訪談。想收集較大量傾向、排序或滿意度時，適合用問卷。問卷不適合追問細節，訪談也不適合直接推估全市場比例。

易用性測試要找幾個人？

沒有所有情境通用的人數。小型質性測試通常先找少量代表性使用者快速抓主要卡點；若要比較版本成效或推估比例，就需要更多樣本與明確指標。重點是受測者要符合目標情境。

A/B Testing 算是 UX測試嗎？

A/B Testing可以是UX測試的一部分，特別適合比較兩個版本的轉換率、點擊率或完成率。不過它偏量化，只能告訴你哪個版本表現較好，通常還需要訪談或易用性測試解釋原因。

UX設計師要會 Figma 嗎？

多數UX/UI職務會需要Figma，因為它常用來做Wireframe、Prototype、設計交付與團隊協作。但Figma只是工具，真正重要的是能把研究結果轉成清楚流程、可測試原型與可執行規格。

UX設計師一定要會寫程式嗎？

不一定要能獨立開發，但要懂基本前端限制，例如RWD、表單狀態、載入速度與互動可行性。台灣小型團隊常把UX、UI與網頁設計放在同一職缺，懂交付語言會更容易協作。

零基礎學 UX設計，應該先學哪些方法？

可先學使用者訪談、Persona、Journey Map、User Flow、Wireframe、Prototype與易用性測試。順序上先理解使用者與任務，再練習把問題轉成流程，最後用測試驗證設計是否可用。

UX作品集要放哪些研究或測試產出？

UX作品集應放問題背景、研究方法、主要洞察、User Flow、Wireframe、Prototype、測試任務、測試發現與修改前後差異。不要只放漂亮畫面，要讓人看出你如何做設計決策。

UX設計師薪水高嗎？

UX設計師薪水會受年資、產業、產品規模、研究能力、UI能力與前端協作能力影響。台灣職缺也常把UX/UI混合要求放在一起。完整薪資比較牽涉職級與公司類型，不屬於UX方法選擇的主軸。