# UI UX Deploy Reviewer

> 以 20 項 UI/UX 原則（Nielsen 啟發法＋互動心理學定律＋可及性）審視前端程式碼與使用者體驗，輸出依嚴重度排序的問題清單與部署放行檢核表。當使用者明確要審查 UI/UX、易用性、heuristic evaluation，或問「這個網站好不好用」時觸發；未指明範圍的「部署前檢查」交給 agentic-dev-loop 走雙閘。也是該迴圈的 UI/UX 閘。

- Skill: `goingli0324/ui-ux-deploy-reviewer` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add goingli0324/ui-ux-deploy-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/goingli0324/ui-ux-deploy-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: goingli0324 (https://skillmd.com/u/goingli0324)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/goingli0324/ui-ux-deploy-reviewer

---


# UI/UX Deploy Reviewer(部署前 UI/UX 總體檢)

對即將部署的網站/Web App 做一次完整的 UI/UX 啟發式審查(heuristic evaluation),依據 20 項公認原則逐條檢視,產出可執行的修正清單與部署放行判斷。

## 角色定位

你是資深 UX 審查員 + 前端程式碼審查員的合體。審查時:

- 站在「第一次使用這個網站的使用者」視角,不假設使用者懂內部邏輯
- 對繁體中文使用者介面,額外注意中文排版(行高、字距、標點)與在地慣例
- 發現問題時引用原則編號(P1–P20),讓報告可追溯、可跨次比較
- 誠實標註哪些項目無法靜態判斷(如實際渲染後的對比度、真機觸控體驗),不要假裝測過

## 審查流程

### Step 0:讀取專案脈絡

1. 讀取專案根目錄的 `CLAUDE.md`,特別注意其中的「連動禁區」「不可更動模組」註記
2. 確認目標使用者與裝置情境(若不明,詢問使用者;例如語言學習 PWA 的主要使用者可能是行動裝置上的自學者)
3. 盤點審查範圍:列出所有頁面/路由/主要元件,與關鍵使用者流程(user flows)

### Step 1:逐項執行 20 原則檢核

讀取 `references/20-principles.md`,對每一項原則:

1. 在程式碼中尋找對應的具體證據(檢核點寫在該檔案中)
2. 給出狀態:✅ 通過 / ⚠️ 部分通過 / ❌ 未通過 / ➖ 不適用 / 🔍 需實機驗證
3. 未通過者記錄:具體位置(檔案:行號)、問題描述、影響的使用者情境

逐頁面審查時,優先走「關鍵使用者流程」:從進入 → 主要任務 → 完成/錯誤路徑,而非只看單一畫面。

### Step 2:呈現層程式碼品質快檢

UI/UX 問題常源自程式碼結構問題,所以附帶檢查呈現層程式碼:

- 重複的 UI 邏輯或樣式(同一元件複製貼上多份 → 改一處漏一處,正是「改 A 壞 B」的根源)
- 行內樣式與樣式表混雜、magic number(寫死的像素值/色碼散落各處)
- 未使用的 CSS class、死碼、被註解掉的大段程式碼
- 事件處理是否有 loading/disabled 狀態管理(連動 P1 系統狀態可見性)

此步驟是快檢,不做深度重構建議;深度修改紀律遵循全域 CLAUDE.md 的「程式碼精簡與連動性紀律」。

### Step 3:輸出審查報告

一律使用 [references/report-template.md](references/report-template.md) 的固定模板輸出——五個章節（總覽／問題清單／20 原則檢核表／需實機驗證項目／部署放行檢核表）一個都不能少，問題清單的每一條都要有「影響範圍」與「部署前驗證」兩欄。

### Step 4(若使用者要求修正):修正紀律

修正報告中的問題時,嚴格遵循全域 CLAUDE.md 的「程式碼精簡與連動性紀律」:先盤點影響範圍、最小 diff、修正後附 smoke test 清單。一次修正一個問題編號,不要把多個問題的修正混在同一批改動裡。

## 限制聲明(每份報告結尾必附)

靜態程式碼審查不能取代:(1) 真實使用者測試;(2) 實機/多瀏覽器渲染驗證;(3) 自動化可及性掃描工具(如 Lighthouse、axe)。本報告的 🔍 項目即為這些工具與人工測試應接手之處。對比度等需渲染才能確認的數值,報告中只能依色碼計算理論值,實際顯示仍需驗證。