UX 審核 — 完整網站審核
您將進行專家級的 UX 審核。您的工作不僅是列出問題，而是解釋為什麼每個問題會損害業務，以及具體該怎麼做。審核客戶通常是企業主或行銷人員，而非 UX 專員。請用商業術語（轉換率、信任度、流失客戶）來論證，而非設計模式。
語言： 以使用者所說的語言進行溝通。報告也應以該語言撰寫。
必要條件 — 網頁爬取工具
此技能需要一種能擷取網站內容的方式。作者已使用 Exa MCP 伺服器（web_search_exa 搭配 livecrawl: "preferred"）進行測試，該工具在頁面內容提取方面表現最佳。
如果您沒有 Exa，您可以使用：
- WebFetch — 內建於 Claude Code，無需設定
- WebSearch — 內建於 Claude Code，適用於基本頁面分析
- 其他 MCP 搜尋伺服器 — 任何能擷取頁面內容的工具
注意：作者並未測試過這些替代方案。爬取深度與內容品質可能有所差異。
輸入
- 網站 URL（必填）
- 業務背景（建議提供）：產業、目標受眾、轉換目標
- 特別關注點（選填）：「檢查表單」、「檢視行動版」、「與競爭對手比較」
如果未提供背景資訊 — 請在步驟 1 中根據網站內容自行判斷。
流程
步驟 0. 準備
詢問使用者（如果未指定）：主要轉換目標、目標受眾、特別關注點。如果使用者不願說明 — 請在下一步驟自行判斷。
步驟 1. 資料收集
爬取網站（使用任何可用的網頁工具）：
- 首頁 — 使用網站 URL 請求
- 關鍵內部頁面（服務、關於、聯絡、作品集）
- 聯絡/詢問頁面 — 另外獨立請求
針對每個頁面，記錄：結構、所有表單與行動呼籲按鈕、聯絡資訊、中繼標籤。
將中間資料儲存到一個工作檔案 — 僅在聊天中顯示摘要。
爬取限制 — 必須考慮到這些
網頁爬取回傳的是不完整的頁面文字。漢堡選單、彈出視窗、隱藏在 JS 互動後方的元素（測驗、聊天小工具、頁尾的即時通連結）、iframe 內容 — 這些都可能不會出現在爬取結果中。
鐵律： 永遠不要聲稱「該網站沒有 X」（沒有即時通、沒有選單、沒有表單），如果 X 可能位於爬取未捕捉到的頁面部分。請改寫為：「在爬取資料中未找到 X — 建議手動驗證。」「不存在」與「未找到」之間的差異，就是虛假發現與誠實限制之間的差異。
對於導航來說這點尤其關鍵：標題中一個可見項目不代表選單只有一個項目 — 完整選單通常隱藏在漢堡選單或下拉選單中。
步驟 2. 跨五大區塊進行審核
閱讀 references/checklist.md 中的檢查清單（50 個項目，橫跨 5 個區塊）。逐一檢查每個項目：
- 正常 — 簡短說明做得好的地方
- 有問題 — 描述問題、評估嚴重性、給予建議
- 無法驗證 — 誠實說明爬取資料不足
- 不適用 — 略過
重要：不要為了充實報告內容而憑空捏造問題。審核的價值在於準確性。如果某個項目是正常的，就說正常。如果資料不足以驗證 — 與其猜測，不如標記為「無法透過爬取驗證」。
步驟 3. 優先排序
| 優先級 | 何時分配 | 範例 |
|---|---|---|
| 重大 | 阻礙轉換或破壞信任。訪客會離開 | 表單故障、電話遺漏、無 HTTPS |
| 主要 | 明顯降低轉換率或造成摩擦 | 行動呼籲按鈕不明顯、8 個表單欄位、沒有評論 |
| 次要 | 不構成阻礙但可以改進的小問題 | 沒有網站圖示、頁尾有錯字 |
首頁的問題權重高於內部頁面。表單的問題權重高於「關於我們」的文字。行動版的問題權重高於桌面版（因為超過一半的流量來自行動裝置）。
步驟 3.5. 自我檢查（報告前）
在撰寫報告之前，請針對每個發現提出三個問題：
-
這是來自爬取的事實還是假設？ 如果您寫了「該網站沒有 X」，請檢查：您是否看過所有頁面？爬取可能遺漏了漢堡選單、彈出視窗、頁尾。如果不確定 — 請將「不存在」改為「在爬取資料中未找到」。
-
這個統計數據是真實的嗎？ 如果您引用了特定的百分比「根據 X 研究」— 您能確定這是一個有這些確切數字的真實研究嗎？如果不確定 — 請移除百分比，保留原則即可。
-
「重大」的判定合理嗎？ 這個問題真的會阻礙轉換嗎？或者只是一個不便？誇大的優先級會損害整份報告的可信度。
步驟 4. 報告
閱讀 references/report-template.md 中的範本並撰寫報告。將報告儲存到檔案中（與使用者協商路徑）。請以使用者所說的語言撰寫報告。
步驟 5. 輸出
在聊天中顯示：
- 摘要 — 各優先級問題數量、總體評分
- 前 5 大重大/主要問題
- 完整報告的路徑
詢問：「想深入探討任何區塊嗎？與競爭對手比較？準備修復規格？」
如何撰寫發現
每個問題都是一個微型論證。糟糕的發現只會命名症狀。好的發現則會解釋原因、影響與解決方案。
糟糕：
按鈕難以看見
良好：
「送出詢問」行動呼籲按鈕並未從頁面背景中凸顯出來。對於轉換元素，建議最小對比度為 4.5:1（WCAG AA）。當行動呼籲與背景融為一體時，使用者不會將其視為可互動的元素。建議： 讓按鈕與背景形成對比 — 使用任何對比檢查工具進行驗證。注意： 在沒有視覺存取頁面的情況下，無法測量確切的對比度。
糟糕：
表單太長
良好：
詢問表單有 9 個欄位。常見做法是將首次聯絡表單限制在 3-5 個欄位，只保留關鍵資訊。這裡的必要欄位是：姓名、電話、專案類型。其餘的（電子郵件、預算、區域、評論、偏好的聯絡方式、通話時間）可以移除或移至第二步驟。
規則：不要捏造統計數據
不要引用特定的百分比「根據 X 機構」，除非您 100% 確定這是一個有這些確切數字的真實研究。捏造的統計數據會破壞整份報告的可信度。請改為：
- 引用已建立的 UX 原則（尼爾森啟發式評估、WCAG、帕雷托法則）
- 解釋邏輯：為什麼這對這個特定企業及其受眾是個問題
- 如果您知道真實來源 — 請引用。如果不確定 — 請寫「根據 UX 研究」或「常見做法」，不要加上特定百分比
考量產業背景
並非所有規則都普遍適用。緊急性元素（「只剩 3 個名額！」）在電子商務中有效，但在律師事務所的網站上則顯得像是在操弄。認證對醫療網站至關重要，但對咖啡店來說則是可選的。「顯示價格」在 B2B 服務中很重要（降低門檻），但對奢侈品領域來說可能是錯的。
在記錄一個問題之前 — 問問自己：這對這個企業及其受眾來說真的是個問題嗎？
延伸功能（依要求）
「與競爭對手比較」 — 透過網路搜尋找到 2-3 個競爭對手，對關鍵參數進行快速審核，並加入比較表格。
「準備修復規格」 — 為開發人員/設計師撰寫技術規格，包含每個修復項目的需求，並按優先級分組。
「詳細檢查行動版」 — 擴展檢查：觸控目標（最小 44x44 像素）、字型大小（最小 16 像素）、固定元素、3G 速度。
「檢查無障礙性」 — 額外區塊：對比度、替代文字、焦點指示器、ARIA 標籤、鍵盤導航。