設計工程
好的介面由許多使用者從未逐一察覺的微小細節構成。以下每個細節都有其存在的原因。請在適用該原因的地方應用它，並研究您所欣賞的介面為何會有那樣的感受。
為任務選擇正確的技能
- 製作一個動畫：使用
animate。 - 需要對動畫差異做出裁決：使用
review-animations。 - 審計並規劃程式碼庫的動畫：使用
improve-animations。應該開始加入動畫的地方：使用find-animation-opportunities。需要移除的動畫：使用remove-animations。 - 多個元素同時移動：使用
choreograph。出現掉幀的動畫：使用animation-performance。 - 網頁上的拖曳、滑動與面板：使用
gestures。 - 用最極端的資料對元件進行壓力測試：使用
break-ui。 - 達到 Apple 級別的手勢、彈簧、材質與排版：使用
apple-design。 - 在手機上感覺不對勁的網頁應用程式：使用
mobile-native。 - 選擇元件庫：使用
pick-ui-library。 - 為同一個 UI 探索多個方向：使用
prototype。
這個技能涵蓋其餘部分：元件打磨，以及不僅限於動畫的 UI 審查。
能發現大部分問題的規則
- 決定某個動作是否應該有動畫。每天被看到 100 次以上的動作，或由鍵盤觸發的動作，不設定動畫。
- 指定確切的屬性。永遠不要使用
transition: all。 - 進場與退場使用
ease-out或強烈的自訂曲線，例如cubic-bezier(0.23, 1, 0.32, 1)。UI 上永遠不要使用ease-in。 - UI 動畫保持在 300 毫秒以下。下拉選單需 150 到 250 毫秒；按壓回饋需 100 到 160 毫秒。
- 每個可按壓元素都應有一個
:active狀態，例如transform: scale(0.97)。 - 永遠不要從
scale(0)進場。從帶有opacity: 0的scale(0.95)開始。 - 彈出式選單從其觸發元素進行縮放（在 Base UI 中使用
transform-origin: var(--transform-origin)）。模態框保持居中。 - 對於使用者在動畫中途可能再次觸發的任何元素，應使用 transition 而非 keyframes。它們會從當前值重新定位目標。
- 僅對
transform和opacity進行動畫。在 Motion 中，使用完整的transform字串，而不是x和y的簡寫形式。 - 尊重
prefers-reduced-motion，使用更溫和的動畫而非完全關閉，並將懸停效果放在@media (hover: hover) and (pointer: fine)內部。
當無法從程式碼判斷操作感受時，請直接說明。以 2 到 5 倍的持續時間或在 DevTools 中逐幀播放動畫，在真實裝置上測試手勢，並隔天再看一次。
審查格式
一份 UI 審查是一個包含「Before」、「After」和「Why」三欄的 markdown 表格，每個問題一行。永遠不要將「Before:」和「After:」寫在不同的行。
| Before | After | Why |
|---|---|---|
transition: all 300ms | transition: transform 200ms ease-out | 指定屬性；all 會動畫到您沒有意圖動畫的內容 |
transform: scale(0) | transform: scale(0.95); opacity: 0 | 現實世界中沒有任何東西是從虛無中出現的 |
按鈕上沒有 :active 狀態 | :active 上使用 transform: scale(0.97) | 按壓需要即時的回饋 |
參考資料
如需快速修復常見症狀（數字抖動、頭像被壓扁、「1 members」），請先查閱 references/ui-cheatsheet.md。
閱讀 references/craft.md 以了解每條規則背後的原因與程式碼：動畫決策框架、彈簧、元件設計原則（工具提示、模糊效果勝過交叉淡出、@starting-style）、變形、裁切路徑模式（分頁、長按刪除、圖片揭示、比較滑桿）、拖曳與手勢處理、效能、無障礙、使用者喜愛的元件設計原則、交錯動畫、除錯以及審查清單。