任務導向的產品 UX
從使用者的實際情況和預期成果開始。既有的設計系統、研究資料和提供的設計稿都是證據；請勿用一個通用的儀表板來取代它們。請閱讀相關任務類型的模式與反例，而不是閱讀所有模式。
在構建畫面之前
對於每個主要角色/任務，請識別其觸發條件、已知資訊、需要做出的決策、完成成果以及恢復路徑。當不同角色的決策內容不同時，請將其工作流程分開；當任務和情境確實相符時，則可以共享畫面。
根據變更的幅度，製作出精簡的流程圖和低保真度的佈局。針對每個可見區域的狀態：
- 使用者現在需要它來做出哪個決策或執行哪個動作？
- 它是主要資訊、情境細節，還是在此視圖中是不必要的？
- 哪項需求、來源或明確的設計決策證明了它的存在？
使用這些原則來篩選資訊，而不是用來產生更多的產品文案。請勿自動添加概覽卡片、圖表、橫幅、篩選器、導航、AI 解釋或「即將推出」面板。只有在有人會依據某個指標做出相關決策時，才將該指標納入。技術來源歸屬可以在需要判斷資訊新鮮度或有效性時加入；但除錯日誌和實作狀態通常應保留在開發記錄中。
不要盲目地做減法。請保留無障礙說明、有意義的錯誤訊息、必要的上下文、強制揭露的資訊以及決策的後果。一個主要動作是實用的預設值，而不是任意限制為一個按鈕。避免僅為了減少可見控件而將重要動作隱藏在通用選單後方。
狀態與互動
為以下相關狀態建立模型：初始、載入中、空白、失敗、成功、編輯中/未儲存、過期結果以及權限限制。只使用產品真正需要的狀態。確保選中的輸入和顯示的結果指向同一個上下文。在可回復的錯誤情況下，保留使用者的工作成果。選擇明確的動作，而非會讓使用者感到意外的靜默變更。
在選擇編輯表面或更改具狀態的佈局時，請閱讀互動模式選擇。根據任務的複雜度、頻率、上下文需求和可用空間，選擇行內編輯、對話框或專用頁面；請不要僅僅為了隱藏佈局錯誤而使用模態框。檢查有意義控件的前後位置、滾動和焦點。有意的揭露可能會移動內容；但無意的跳轉或消失的目標需要修正。
使用專案的設計 Token、元件、語言和無障礙慣例。透過可用的支援工具檢查所提供的參考設計稿；缺少 Figma MCP 本身並非停止工作的理由。切勿將未經檢查的設計標記為已匹配。不要僅僅為了小改動而引入一個新的元件庫。
檢查在有效、錯誤、恢復等狀態下的無障礙名稱和描述，而不僅僅是可見性和焦點。當被無障礙描述引用時，隱藏的訊息仍然可以被揭露；僅當錯誤適用時才將錯誤文字與其關聯。
審查渲染後的流程
使用可用的瀏覽器或應用程式工具，從實際的進入點執行該任務。檢查結構中的標籤和控制項，並檢查渲染後截圖的層級、裁切、間距和視覺狀態。僅靠自動化的無障礙或 DOM 檢查並不能證明視覺或可用性的品質。
進行響應式檢查時，請確認瀏覽器實際的視窗尺寸，並檢查最終的捕獲圖像。單獨裁剪截圖、更改元素寬度或檢查水平溢出並不等於等效的視窗尺寸測試。如果工具無法設定或驗證視窗尺寸，請將該項測試標記為「未驗證」。將截圖與報告結果進行比對：缺失內容、無法使用的換行或不可見的動作，不能僅僅因為 DOM 檢查通過就稱之為視覺通過。
對於每個發現，請記錄：重現步驟 → 觀察到的行為 → 對使用者的影響 → 最小且有用的修正 → 重新檢查。將推測與觀察結果分開標註。在添加解釋之前，優先考慮移除、移動、合併或改進預設值。除非變更或剩餘的問題需要，否則不要重複執行已通過的審查。
如果無法使用瀏覽器，請審查程式碼/佈局證據，並將運行時 UX 標記為「未驗證」；繼續進行其他可獨立完成的工作。請勿捏造螢幕截圖、點擊或用戶驗證。開發者或代理人的審查並非使用者研究。