上線後的UX測試
本篇文章同樣是整理自Paul Boag的課程內容，不過探討的是上線後的監控，以及持續改進
上線後才是真正開始：用數據驅動的網站優化循環
很多團隊在網站上線那一刻鬆一口氣——「終於結束了」。
但真正重要的事情，其實才剛開始。
上線之後，我們終於能看到「真實使用者」在「真實環境」下與網站互動。
沒有主管監控、沒有人引導，純粹自然的操作。
而這些紀錄比起發佈前的任何測試都還要更有價值，該如何最大化使用這些數據呢?
分成以下三個步驟 :
第一步 找出問題頁面
使用Google Analytic 或其他分析工具，針對兩個指標進行觀察
-
- 離開頁（Exit Pages）
哪些頁面是使用者離開網站的出口？
前五名為高風險區
-
- 跳離頁（Bounce Pages）
哪些頁面使用者只停留幾秒就關掉？
過濾掉停留不到 5 秒的紀錄（可能受限於硬體或網路環境造成的延遲），
專注在停留 5～20 秒後離開的數據
那通常代表頁面內容或結構有問題。
找到跳出率或離開率最高的頁面， 就是第一個優化目標。
第二步 分析原因
使用 Microsoft Clarity 或 Hotjar 等工具，
在該頁面上開啟錄影與熱區圖（Heatmap）分析。
這些工具能讓我們看到：
-
使用者滑動到哪裡停下？
-
哪些區域完全沒被看到？
-
他們是否點擊了「不應該點擊的區域」？
-
有人完全忽略了 CTA嗎？
看幾段影片、觀察幾張熱區圖後，就可以發現使用者行為模式。
例如：「大家都滑過了說明段落」、「很多人試著點圖片但沒反應」。
這些都是非常具體的紀錄。
若仍然無法判斷原因，可以做一輪可用性測試：
- 讓幾位使用者實際完成任務（例如下單或填表），並請他們邊操作邊說出為何這樣操作。
透過更直接的言語表達，可以確認我們設計的方向是否貼近實際使用情境。
第三步 測試解決方案
確認問題後，就是嘗試修正，根據修改難度可以分成兩種 :
1. 簡單變更 : 可能不會動到Codebase
-
- 改標題文字
-
- 按鈕換色或改名
-
- 圖片替換
-
- 刪除多餘說明
2. 複雜變更 : 會動到Codebase
-
- 移除 CAPTCHA
-
- 簡化註冊流程
-
- 改動表單邏輯或頁面結構
並且透過以下兩種測試方法來確認是否要放進正式版本中 :
-
A/B 測試：一次改一個變數（例如: 標題），但可有多版本。
-
多變量測試：同時改多個區塊（例如 標題＋按鈕＋圖片）， 用於大流量網站、需更細緻分析交互影響的情境。
結論
發現問題 > 分析原因 > 驗證/修正
測試UI/UX其實和軟體開發週期中的功能開發簡直是一模一樣
