← ClaudeAtlas

ui-ux-deploy-reviewerlisted

以 20 項 UI/UX 原則(Nielsen 啟發法+互動心理學定律+可及性)審視前端程式碼與使用者體驗,輸出依嚴重度排序的問題清單與部署放行檢核表。當使用者明確要審查 UI/UX、易用性、heuristic evaluation,或問「這個網站好不好用」時觸發;未指明範圍的「部署前檢查」交給 agentic-dev-loop 走雙閘。也是該迴圈的 UI/UX 閘。
goingli0324/muzi-going-skills · ★ 0 · Web & Frontend · score 70
Install: claude install-skill goingli0324/muzi-going-skills
# 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)。本報告的 🔍 項目即為這些工具與人工測試應接手之處。對比度等需渲染才能確認的數值,報告中只能依色碼計算理論值,實際顯示仍需驗證。