Figma 動態按鈕設計教學：製作流暢的按鈕轉場動畫效果

Figma 動態按鈕設計教學

流暢的按鈕轉場不是「加動畫」就會順，而是先把每個互動狀態當成獨立畫面設計好，再用 Smart Animate 與緩動曲線讓它們自然銜接。業界動效節奏經驗指出，按鈕轉場時長落在 200 至 300ms 最貼近人眼感知，而觸控熱區依蘋果 Human Interface Guidelines 與 WCAG 2.5.5 建議不應小於 44px。狀態切得乾淨，動畫自然就順；狀態沒定義清楚，再炫的動畫也會像硬切兩張圖片。本篇用 Figma Prototype 走完一條下載按鈕的完整動線，從預設、Hover、載入中到完成打勾，新手也能照著做完。

重點先看：按鈕動態成不成，九成看狀態設計完不完整。時長守在 200 至 300ms、緩動選 Ease In Out（依業界動畫節奏經驗與 Material Design 動效指南相近區間），四狀態的圖層名稱對齊，Smart Animate 才有東西可比對、算得出補間。

動態按鈕的價值在於即時回饋狀態

按鈕加動態的真正價值在於即時回饋狀態，外觀好看只是附帶結果。使用者點下去的那一刻，他想被告知三件事：我按到了、系統正在處理、做完了。這層回饋能降低焦慮、引導下一步，是把CTA 行動呼籲按鈕設計從「能用」推到「想點」的關鍵。流暢度關鍵看狀態切得多乾淨，動畫炫不炫是次要。

很多教學把重心放在「動畫要多酷」，結果新手照做，按鈕切起來卻毫無過渡。真正的問題出在根本沒先把每個狀態當獨立畫面設計，時長與緩動其實只是次要因素。先把未點擊、點擊中、載入、完成四個畫面的資訊層次拉清楚，動畫設定反而最簡單；跳過狀態直接調參數，才是作品看起來卡頓的真正原因。這也是為什麼成熟的UI 與 UX 設計工作流程會把狀態設計排在視覺打磨之前。

• 預設（Default）：使用者的起點，按鈕的 resting 樣貌。
• 滑鼠懸停（Hover）：底色加深或加陰影，暗示可點擊，桌面版為主。
• 點擊／載入中（Loading）：文字換成進度條與下載中，禁止再點擊。
• 完成（Done／Success）：打勾圖示加上完成，常配綠色或品牌成功色。

下載按鈕是最經典的一條龍範例：點擊、進度條跑動、完成打勾，四個狀態一次涵蓋，使用者看到載入條就不會重複點擊、也不會以為頁面壞掉而中途離開。本篇就鎖定用它走完 Figma Prototype 的完整動線，步驟拆得夠細，初學者也能跟著做完。要特別提醒的是，這套狀態先決的觀念不只適用下載按鈕，上傳、送出表單、結帳付款這類需要等待回應的按鈕，全部都能套用同一個四狀態骨架。

動手前先把下載按鈕的靜態初版畫好

開始做動畫前，先把按鈕的預設狀態靜態稿畫到定位。外框、圓角、顏色、文字、圖示全部調好，因為後續每個狀態都會從這個初版複製改動。初版沒定型就直接進 Prototype，你會反覆回頭改設計、動畫永遠調不順，這是很多人做到一半放棄的主因。

畫一個下載按鈕：矩形加圓角，配上Figma 免費圖示 Icon 外掛找來的下載圖示，文字寫「下載」，底色用品牌主色。用 Auto Layout 把內容包起來，確保文字與圖示對齊、之後加載入狀態才不會跑位。Auto Layout 是後面四狀態尺寸能保持一致的基礎，少了它，每改一個狀態就要手動調一次間距，做完圖層名稱也跟著亂。按鈕的視覺層級若還沒拿捏，可先對照網頁設計必備的 UI 視覺元素再下筆。

決定按鈕尺寸與 padding 時，建議觸控熱區高度不少於 44px。這個數字不是拍腦袋來的，而是依蘋果 Human Interface Guidelines 與 WCAG 2.5.5 目標尺寸的建議，屬於行動裝置友善的硬性下限。把這個初版命名清楚，例如 Button / Default，後面複製成 Variant 時才不會混淆。

這一步看似最無聊，卻最關鍵。實務上常見的狀況是，設計師急著進 Prototype 面板玩動畫，底層尺寸卻還沒固定，動畫做一半才發現每個狀態寬度都不一樣，Smart Animate 補間整個崩掉，只好回頭重畫。把初版當地基打穩，後面的步驟才會順。配色若還沒定案，先把主色與成功色選出來（品牌色已有規範就直接套用），文字字型也一次定好，避免按鈕文字在 Prototype 裡糊掉。

拆出四個狀態

把初版複製成四個畫面，每個狀態只改與該階段相關的元素，結構與位置保持一致。預設狀態維持原樣、Hover 微調底色或陰影、Loading 把文字換成進度條與下載中、Done 改為打勾圖示與完成。這層一致性，是 Smart Animate 能算出順暢中間帧的前提。

這裡有一個新手最容易踩的雷：四個狀態的按鈕外框尺寸務必一致。Smart Animate 靠相同圖層名稱做補間，名稱對不上，它就只能做淡入淡出，動畫當場退化成硬切。所以從 Default 複製出來之後，只動內部元素的屬性，不要更動外框與圖層命名。

狀態	視覺重點	主要改動元素	互動意圖
Default	品牌主色底、下載圖示	維持初版	等待使用者點擊
Hover	底色加深或加陰影	底色、陰影	暗示可點擊（桌面版）
Loading	進度條取代文字	文字、圖示	禁止重複點擊
Done	打勾圖示、成功色	圖示、底色、文字	確認動作成功

Hover 在桌面版是重要線索，但在手機上幾乎沒有作用，因為觸控裝置沒有真正的 hover 事件。如果你的按鈕主要服務行動版，Hover 可以省略，或改用點擊、長按來承載類似的回饋，這點在Figma 響應式行動版排版教學與響應式網頁設計 RWD 觀念裡會有更完整的脈絡。

Loading 狀態的進度條，可以從簡單的橫條開始，跑動邏輯留到 Prototype 階段用 After delay 模擬。Done 狀態的打勾圖示，建議用品牌成功色（常見是綠色系），讓使用者在視覺上立刻收到「成功」訊號。若想讓載入動畫更精緻，可參考Figma 載入動畫 Loading 原型互動的進階做法，或用Lottie 網頁動畫補上更細緻的微互動細節。

打勾這類小圖示若想自己刻，也能借助Fonts Ninja 網頁字體辨識工具或精選英文字體下載資源先把搭配的字型定下來，視覺一致性才會到位。

Prototype 連線：用 Smart Animate 串起狀態流

進入 Prototype 面板，連線順序就是使用者動線：Default 拉到 Hover、Hover 到 Loading、Loading 到 Done，方向不能錯。轉場動畫一律選 Smart Animate，因為它會比對兩個畫面中相同名稱的圖層並自動補間，這是按鈕狀態能平滑切換的關鍵，也是它與一般 Dissolve 最大的差別。

觸發條件要按狀態性質分開設。Default 到 Hover 用 On hover，模擬滑鼠移上去的瞬間；Hover 到 Loading、Loading 到 Done 用 On click，對應使用者真正按下按鈕的動作。若想模擬「按下後自動跑載入再完成」的效果，可以從 Loading 到 Done 設 After delay，例如 1500ms，這樣原型展示時就能一氣呵成看到完整流程，不需要手動連點。

連線	觸發條件	轉場類型	用途
Default → Hover	On hover	Smart Animate	桌面版滑鼠懸停回饋
Hover → Loading	On click	Smart Animate	點擊後進入載入
Loading → Done	On click / After delay	Smart Animate	手動或自動完成

這裡要特別釐清 Smart Animate 與 Dissolve 的差異，因為選錯是新手動畫毫無過渡的元兇。Figma Smart Animate 依圖層名稱比對自動補間，會計算位置、尺寸、顏色、透明度的中間帧；Dissolve 則只是單純的淡入淡出，不做圖層級補間。當 Smart Animate 找不到可對應的圖層（match 為 0）時，會自動退化成 Dissolve 行為，所以遇到動畫突然只剩下淡入淡出，第一件事就是回頭檢查兩個狀態的圖層命名有沒有對齊。

連完之後務必按下 Present 逐條測試，確認每條連線觸發正確、動畫方向沒有接反。原型 Demo 的習慣值得養成，因為UI Prototype 原型設計的價值，很大一部分建立在「能不能被預覽驗證」上。若想讓互動層次更豐富，也可搭配Figma 滑鼠追蹤視差互動效果或Figma 互動式輪播滑塊設計的手法，把按鈕放進更大的互動情境裡。

Prototype 面板背後其實是一台陽春的互動狀態機，想理解狀態轉移的觀念，可對照UIUX 設計師實用 ChatGPT 指令，把狀態邏輯想清楚再回來連線會快很多。

時長、緩動曲線與卡頓地雷排查

按鈕轉場時長建議落在 200 至 300ms，緩動曲線選 Ease In Out 或 Ease Out。這個區間最貼近使用者感知，不會眼花也不會覺得延遲。卡頓最常見的三個原因是圖層名稱不一致、Auto Layout 導致位置跳動、時長設太長超過 500ms，逐一排查就能讓動畫回到順暢。

時長的黃金區間是有知覺根據的。200 至 300ms 是業界動畫節奏經驗公認的舒適帶，Material Design 動效指南同樣建議短時長的互動回饋。太快會像閃爍、太慢會像延遲，兩者都會讓使用者覺得卡。超過 500ms 幾乎都會被感受為「卡」，因為它超出人對即時回饋的期待。緩動曲線預設選 Ease In Out，進入感柔和；若要強調完成的收束感，Done 那段可改 Ease Out。

卡頓往往來自幾個結構性問題疊加，而非單一原因。最常見的是圖層名稱沒對齊：Smart Animate 靠名稱比對補間，名稱差一個空格就退化成 Dissolve，所以逐一核對兩個狀態的圖層命名是基本功。另一個常被忽略的是 Auto Layout 尺寸跳動，某個狀態的文字變長撐開按鈕寬度，補間就會跟著位移，這時要嘛鎖固定尺寸，要嘛讓文字容器等寬。時長本身也會製造卡頓感，超過 500ms 幾乎一定被感受為延遲，壓回 200 至 300ms 通常就會改善。而硬做位移的習慣同樣會放大問題，顏色或透明度過渡比位移更吃補間品質，能用顏色變化解決就不要硬推位置，否則抖動只會被放大。

動畫順不順，八成問題出在狀態準備得不夠乾淨，而不是時長差了 50ms。較穩當的排查順序是：動畫卡住時先不要去調時長，而是回去比對兩個狀態的圖層面板，把名稱、階層、尺寸逐一對齊，往往調完動畫就順了。Smart Animate match 為 0 時會退化成 Dissolve，這是 Figma 的官方行為，遇到跳針先往這個方向找答案。

為了讓排查更有效率，把症狀、成因與修法整理成一張對照表，遇到卡頓時按表操作，比逐項試誤快得多。這張表涵蓋前面提到的四類成因，再補上幾個較少被討論卻常見的邊界情境。

症狀	最可能成因	修法	驗證方式
動畫退化成兩張圖淡入淡出	兩狀態圖層名稱不一致，Smart Animate match 為 0	逐一比對圖層面板，名稱、階層順序完全對齊	把滑鼠移到連線上，Figma 會顯示匹配的圖層數量
按鈕寬度抖動、內容左右位移	Auto Layout 未鎖尺寸，文字長度變動撐開容器	勾選固定寬度，或讓文字容器等寬並置中	切換狀態時觀察外框節點是否固定不動
動畫看起來像延遲、不像回饋	時長超過 500ms	壓回 200 至 300ms，Done 收束段可略短	Present 預覽連續點擊，感受是否即時
顏色過渡出現色塊殘影	深淺兩色跨度過大，又用了位移而非純色變化	改用純色彩或透明度過渡，避免同時做位移	逐帧檢視中間帧顏色是否連續
Hover 在手機預覽沒反應	觸控裝置無真正 hover 事件	手機版改用點擊或長按承載同等回饋	用 Figma Mirror 在實機測試
元件套用到新畫面後動畫失效	複製元件時未帶上 Prototype 連線	確認拉出的是含互動的主元件實例	檢查實例右側 Prototype 面板是否有連線

把這張表放回真實專案情境，更能看出排查順序的價值。以一個大約 3 至 6 人的產品設計團隊、同時維護約 20 至 40 個按鈕狀態的典型規模為例，常見的狀況是設計師照教學做出單顆按鈕時動畫很順，一旦套用到 Component Set、再分派給兩三個畫面後，Hover 到 Loading 之間就開始只剩淡入淡出。背後的原因幾乎都是同一個：複製成 Variant 的過程中，某個狀態被多包了一層 Frame 或文字圖層被改名，導致 Smart Animate 的 match 數量掉到接近 0。依這類團隊的典型表現，光是把「為什麼動畫退化成 Dissolve」一條問題定位到圖層命名，幅度大約會耗掉 1 至 3 個工作天的人時，而且常在多人協作時反覆發生，因為每個人命名習慣不同。

這類情境也有一個必須誠實面對的限制：症狀對照表能幫你「快速定位到圖層名稱這一層」，卻無法替你決定整個團隊的命名規範。換句話說，表格治標，命名規範治本。較穩當的決策角度是，把功夫往前挪到專案初期，先固定一套屬性式命名（例如 Icon / Download、Text / Label），並要求所有狀態沿用同一份圖層骨架，把可變的限縮在屬性值本身。實務上常見的狀況是，團隊把命名規範寫進設計系統文件後，Smart Animate 退化的回報次數會明顯下降，幅度約落在每月個位數起跳的修正量。換句話說，這張表真正的價值在於倒逼團隊把命名骨架提早標準化，把事後除錯的時間往前挪到事前規範。

養成「症狀對照表先看、再動參數」的習慣，能省下大量試誤時間。卡頓時直覺反應通常是調時長或換緩動，但這兩個變項只佔成因的一小部分，結構性的圖層與尺寸問題才是大宗。把排查順序固定下來，從圖層名稱、尺寸一致性、時長逐一過濾，效率會比隨手調參數高得多。

Smart Animate 對齊檢查：把「圖層名稱一致」變成可執行的步驟

前面反覆強調「圖層名稱一致」是 Smart Animate 補間的前提，但「一致」兩個字本身仍是模糊的口訣。這裡把它拆成一條可在每次卡頓時逐項打勾的檢查動線，搭配一個下載按鈕的命名範例，讓規則落地為可操作步驟。

檢查項	Default 範例	Done 範例	不符就會發生什麼
圖層名稱逐字相同	Icon / Download	Icon / Download	名稱差一個空格，該層補間失效、退化成淡入淡出
階層（nesting）深度一致	Button / Icon / Download	Button / Icon / Download	某狀態把圖示多包一層 Frame，比對失敗
圖層類型一致	Frame（外框）	Frame（外框）	一邊 Frame、一邊 Group，補間算不出位移
屬性可內插	填色為實色	填色為實色	一邊用實色、一邊用 Image fill，顏色無法內插
同時存在的圖層才算匹配	有 Progress Bar 圖層、隱藏	有 Progress Bar 圖層、隱藏	某狀態直接刪除該圖層，Figma 視為新增／移除而非補間

實作時最容易漏掉的是第四與第五項。許多設計師以為「名稱打對就好」，卻在 Done 狀態把文字圖層刪掉、改放一張打勾 PNG，這時 Smart Animate 會把 PNG 當作全新圖層處理，於是文字會直接消失、再冒出打勾，中間毫無過渡。正確做法是保留同名文字圖層，僅改其內容或用透明度過渡，讓補間有東西可比對。換言之，狀態之間共享的圖層骨架愈穩定，動畫愈能算出連續的中間帧，這也是把四狀態骨架先固定下來、再填內容這個順序背後的技術原因。

緩動曲線的本質，是控制動畫「開始與結束的加速度」。Ease In Out 兩頭慢、中間快，適合大多數狀態轉換；Ease Out 開始快、結束慢，適合需要強調「落定」感的場合，例如 Done 的打勾收束。若想理解更深一層的微互動設計原則，可以從排版設計字體與視覺層次技巧與色彩心理學掌握用戶感受反向思考，動畫其實是把這些靜態層次用時間軸重新展開。

把按鈕動畫素材集中管理會讓後續維護輕鬆很多，配圖與 3D 圖示若用到外部素材，記得匯出時控制檔案大小，原型才不會被圖檔拖慢。

動畫緩動曲線深度解析：從預設值到自訂貝茲曲線

前面提到預設選 Ease In Out、Done 段改 Ease Out，多數情況這樣設定就夠用。但若想把按鈕動態推到更精緻的層次，理解緩動曲線背後的數學與感知原理會讓你做選擇時更有依據。緩動曲線本質上是控制動畫屬性隨時間變化的速率函式，決定開始、中段、結束各跑得多快。

線性（Linear）動畫每單位時間推進等量，聽起來合理，人眼感受卻極不自然。因為真實世界的物體受慣性與摩擦力影響，加減速天生就是漸進的，不會瞬間起停。線性動畫缺乏這層物理感，會顯得機械化、冰冷，這也是為什麼互動設計幾乎全面避開 Linear。Figma 與多數動效工具把 Linear 留給少數特殊用途，例如旋轉的載入轉圈，那類持續循環、本身就需要均勻節奏的元素。

曲線類型	加速度特徵	適用的按鈕狀態	不適用的情境
Linear（線性）	全程等速	載入轉圈、進度條均勻推進	狀態轉換、位移過渡
Ease In	開始慢、結束快	按下後退出畫面、關閉彈窗	需要迎接感的進場
Ease Out	開始快、結束慢	Done 完成收束、進場元素	需要離去感的退場
Ease In Out	兩頭慢、中間快	Default 到 Hover、Hover 到 Loading 等多數轉換	需要明顯落定感的收束
Spring（彈性）	具回彈、過衝	完成打勾、按讚這類情緒性回饋	專業金融、醫療等需克制的介面

除了內建曲線，Figma 也允許自訂 cubic-bezier 控制點，輸入四個數值即可定義一條專屬曲線。自訂曲線的價值在於品牌一致性：當產品的整體調性偏活潑，可以讓曲線帶一點過衝（overshoot）的彈性；當產品偏嚴肅專業，則把曲線拉得更收斂、收束更乾脆。同一套曲線參數套用到按鈕、卡片、選單，整個介面的動態節奏就會一致，這是成熟設計系統的隱形品質指標。

選擇曲線時還要考慮動畫距離。位移距離短的過渡（例如底色變化、陰影浮現），用 Ease In Out 即可；位移距離長的過渡（例如按鈕橫向滑動或展開成面板），則建議搭配略長的時長與較明確的 Ease Out 收束，讓終點落定清楚。距離短卻用長時長，動畫會顯得拖泥帶水；距離長卻用短時長，會有倉促趕場的感覺，這層距離與時長的搭配是手調動畫進階的關鍵。

打包成元件：用 Component Set 與 Variant 重複套用

做好動態按鈕後，把它包成元件才能在大型專案重複使用。做法是先單獨把每個狀態做成 Component，再用 Component Set 統整，每個狀態設一個 Variant 屬性，例如 State 等於 Default、Hover、Loading、Done。之後在任何畫面拉出這個元件，Prototype 互動會跟著套用，改一處全部同步。

不要一開始就四個狀態框起來一次打包，屬性很容易亂掉。先逐個狀態做成 Component，確認各自的互動連線都正確，再組成 Component Set，這個順序能讓你在除錯時有明確的單位，不會牽一髮動全身。一次性把四個狀態打包，往往連哪個 Variant 對應哪條 Prototype 連線都會分不清。

命名採屬性式（如 Button / State=Loading），團隊成員在資產面板直接搜尋狀態名稱，比 Button1、Button2 這類編號命名直覺得多。顏色與圖示抽成 Style 與 Variables 管理，是元件能否真正「改一處全部同步」的關鍵：換配色時只改一個變數值、四個狀態全部更新，不必重做動畫。若想進一步把整套設計資產系統化，可參考Figma 網格系統與響應式排版與網頁版面 RWD 響應式排版。

元件化之後，按鈕的樣式變化也能用 Variant 擴充，例如加上尺寸（Size=Large）、配色主題（Theme=Dark）等屬性。這套做法和Figma 毛玻璃霧面質感效果、Figma 動態環形文字標籤設計這類特效元件是同一個邏輯：把可變的部分抽成屬性，把固定的部分鎖在元件內。

想加速產出，Figma 必裝外掛與Figma AI 功能與設計代理能幫你省下大量重複操作。元件化的動態按鈕可整組 demo 給客戶，也能直接移交開發當互動規格參考。

無障礙與動態偏好：尊重使用者的 reduced-motion 選擇

動畫做得再流暢，對部分使用者來說仍可能造成不適。前庭功能障礙、偏頭痛、光敏感等狀況，會讓某些使用者對位移、閃爍、視差這類動態特別敏感。W3C 的 WCAG 2.3.3「Animation from Interactions」指引就明確要求：由互動觸發的動畫，除非該動畫是傳達資訊所必需，否則應能被使用者關閉。按鈕的 Hover、Loading、Done 過渡屬於裝飾性回饋，正好落在這條規範的適用範圍內。

作業系統層面早已提供相關機制。macOS、Windows、iOS、Android 都有「減少動態效果」「減少動作」的系統設定，瀏覽器透過 prefers-reduced-motion 媒體查詢讀取這個偏好，網頁可據此調整或關閉動畫。設計師在 Figma 規劃階段就該把這個偏好納入考量，並在移交文件裡標明開發端要用 CSS 的 prefers-reduced-motion 媒體查詢，把動畫時長壓到極短甚至歸零，改以即時切換狀態的方式呈現回饋。

• 在移交文件標明 prefers-reduced-motion 的處理方式，讓開發端知道動畫需可被關閉。
• 為開啟減少動態效果的使用者，把過渡壓成即時切換或極短時長，保留狀態回饋但不做位移。
• 載入進度條避免用閃爍或高頻率變化，改用穩定的推進動畫，降低不適風險。
• 確認按鈕的回饋不只靠動畫傳達，顏色變化、文字變化、圖示變化都要獨立成立，動畫關閉時資訊不會遺失。
• 鍵盤焦點狀態（Focus）也要設計清楚，不能只靠滑鼠 hover 的視覺回饋，鍵盤使用者要能看見目前焦點在哪顆按鈕。

這裡有個常被忽略的原則：動畫應該是錦上添花的回饋層，而非資訊的唯一載體。意思是，即使把動畫完全關掉，使用者照樣要能從顏色、文字、圖示看出目前是 Default、Loading 還是 Done。如果某個狀態只有靠動畫才能辨識，那就違反了無障礙原則。顏色對比方面，按鈕文字與底色的對比度依 WCAG AA 標準應達 4.5:1，這項檢查與動畫無關，卻是按鈕可用性的底線。把無障礙檢查當作動態按鈕交付前的固定流程，作品才禁得起放大檢視。

Figma 目前無法直接模擬 prefers-reduced-motion，但設計師可以準備兩組 Prototype 規格：一組是完整動畫版，一組是減少動態版（時長歸零、過渡改成即時切換），在移交文件一併交付。開發端據此撰寫對應的媒體查詢分支，兩種使用者都能得到合適的體驗。這個準備動作看起來多花時間，卻是專業設計與隨手做做最大的分野，也讓作品符合多數公共機構與大型企業標案的無障礙要求。

什麼情況不要把按鈕做成動態：動態決策評分卡

懂得什麼時候做動態，同樣要懂得什麼時候不做。動態按鈕並非萬靈丹，某些情境加了動畫反而拖慢操作、干擾判讀，甚至引發無障礙問題。把常見情境整理成一張決策評分卡，能幫你快速判斷是否該為按鈕加動態。

情境	是否建議動態	理由	建議做法
下載、送出、結帳等需等待回應的按鈕	強烈建議	需要 Loading 與 Done 回饋降低焦慮、防止重複點擊	四狀態全套，時長 200 至 300ms
主要 CTA、報名、購買等高轉換按鈕	建議	Hover 回饋提升點擊意願，Loading 防誤按	至少做 Hover 與 Loading
純導覽連結、選單項目	視情況	過度動態會讓選單顯得花俏、拖慢瀏覽	只做輕量 Hover 顏色變化
大量並列的操作按鈕（如表格每列的編輯鈕）	不建議	動畫數量過多會分散注意力、拖累效能	只做即時顏色回饋，不加過渡
緊急停止、防呆確認等需立即反應的按鈕	不建議	動畫會增加反應延遲感，降低操作確定性	即時切換，不加過渡時長
財務、醫療等嚴肅專業介面	克制使用	過度彈性或活潑動畫會削弱信任感	用 Ease In Out 等克制的曲線，避開 Spring

評分卡的核心觀念是「動態要服務於功能」。當按鈕的功能是等待回應（下載、送出、結帳），動態回饋能明確降低焦慮、防止誤操作，此時加動態是加分。當按鈕的功能是快速導覽或大量重複操作，動畫反而會成為負擔，這時克制才是專業判斷。把動態當成預設值一律套用，會得到一個看起來華麗卻不耐用的介面；把動態當成有條件才使用的工具，才能在對的地方發揮最大價值。

效能也是判斷依據之一。單一頁面上若同時存在十幾顆帶過渡動畫的按鈕，加上每顆都做位移與陰影變化，在低階裝置上容易造成掉幀。這也是為什麼大量並列的操作按鈕建議只做輕量回饋。動畫數量與複雜度要與頁面整體負載一起評估，不能只看單顆按鈕的效果，這個整體觀是進階設計師與初學者明顯的差別。

把評分卡進一步收斂成一條可量化的判斷門檻：若一顆按鈕的任務包含「使用者需要等待系統回應」（下載、送出、結帳、密碼驗證），就值得做四狀態動態；若任務是「點下去立即生效」（導覽、切換分頁、勾選），動畫反而會拖慢感知速度，只做顏色回饋即可。以一個常見的註冊表單為例：送出鈕屬於等待型，要做完整 Loading 與 Done；性別選項的單選鈕屬於立即型，過渡只需 100ms 左右的底色變化。用「是否需要等待」這一個維度切分，就能避開把每顆按鈕都套上完整動態、結果整頁動畫互相打架的常見失誤。

從設計到上線：按鈕動態怎麼移交給開發

Figma 的 Prototype 是互動規格的視覺參考，不是可以直接轉成網站的程式碼。移交時要把每個狀態的設計細節、動畫時長、緩動曲線、觸發條件寫成開發看得懂的文件或 Dev Mode 標註，讓前端用 CSS transition 或微互動程式庫在網站上重現相同感受。

用 Figma Dev Mode 匯出間距、顏色、圓角等數值，能減少開發猜測。但動畫時長、緩動曲線、觸發事件（click、hover、delay）這些資訊，Dev Mode 不會自動給，需要設計端額外標註。這層標註的完整度，直接決定開發還原度。設計端不必自己寫程式，開發端通常用 CSS transition（200 至 300ms、ease）或輕量動畫程式庫實作。

載入進度條在原型裡可以用 After delay 模擬，但在實際網站，進度條的推進取決於後端 AJAX 或 API 回應速度，設計師無法完全掌控。這意味著設計端要預留彈性：進度條不能設成「一定幾秒跑完」，而要能配合真實回應狀態切換。更重要的是，雙方要對齊狀態定義，哪些情況顯示 Loading、請求失敗時按鈕要回到 Default 還是顯示錯誤狀態，這些都比動畫本身更影響成品。這也是為什麼CTA 按鈕與文案提升轉換率會強調，按鈕的成败常常藏在互動邏輯而非視覺裡。

開發還原動畫時，CSS transition 是最輕量的選擇，適合顏色、透明度、位移這類屬性變化；若動畫牽涉到路徑或複雜時間軸，可改用網頁動畫程式庫之類的方案。若網站是用頁面編輯器搭建，Divi、Elementor 這類工具也都內建 hover 與表單互動設定，能省下不少手刻工。

把動態按鈕放進轉換動線

按鈕很少單獨存在。它通常長在 Landing Page 的結尾、表單的送出鍵、或是產品頁的購買按鈕上。動態按鈕的價值，要放在整個轉換動線裡才看得清楚。一個會即時回饋狀態的下載按鈕，配上清楚的Landing Page 高轉換銷售頁結構，能讓使用者從看到、想點、點下去、到確認完成，全程不焦慮。

轉換率的提升，往往不是靠單一個炫炮按鈕，而是動線上每個環節的回饋都到位。按鈕動態能降低重複點擊與中途跳出，但前提是它服務的頁面本身夠清楚。Landing Page 轉換率優化原則與提升網站詢問轉換的方法提供的就是這層更大的框架：按鈕是動線的一個環節，不是主角。

按鈕的回饋速度不只影響體驗，還直接牽動搜尋排名與營收。Google 把 Core Web Vitals 列為網頁體驗排名訊號 [來源：〈Google Search Central Blog (developers.google.com)〉〈https://developers.google.com/search/blog/2020/05/evaluating-page-experience〉〈2020-05-28〉]，其中的 INP（Interaction to Next Paint）衡量的正是使用者與頁面互動後、畫面回應的即時程度，而按鈕點擊正是最常見的互動來源。當按鈕點下去到畫面更新之間卡頓，INP 數值就會惡化。業界已有公開案例顯示改善這類互動回應能帶來實質收益：redBus 在改善網站的 INP 後，銷售提升了 7% [來源：〈web.dev (Google) - Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]；Vodafone 把 LCP 改善 31% 後，銷售增加 8% [來源：〈web.dev (Google) - Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]。這些數字說明，按鈕的即時回饋不只是設計細節，更是會被搜尋引擎與消費者同時計分的轉換變因。

若你還在規劃頁面骨架，先把按鈕在版面上的落點與層級定好，動態效果才有發揮的舞臺。按鈕放的位置、留白、與周圍元素的視覺權重，都會影響它被點擊的機率，骨架清楚了動畫才不會被擠到最後才補做。

動態按鈕是為轉換服務的微互動，不是炫技。它要解決的是「使用者按下去之後，到底發生了什麼」這個焦慮。當你能用四個狀態把這個焦慮逐一接住，按鈕的價值就會自然浮現，而不需要靠過度裝飾的動畫硬撐場面。

常見問題 FAQ

Smart Animate 找不到匹配圖層時會發生什麼事？

當兩個狀態之間沒有名稱相同的圖層、或匹配數量為 0 時，Smart Animate 會自動退化成 Dissolve，畫面只剩淡入淡出、沒有補間。這是 Figma 的官方行為，也是按鈕看起來像切換幻燈片的主因，遇到時第一步是回頭比對圖層命名而非調時長。

Hover 狀態在手機預覽為什麼沒反應？

觸控裝置沒有真正的 hover 事件，所以 Hover 在手機上幾乎不會觸發。行動版為主的按鈕可以省略 Hover，或改用點擊、長按來承載類似的回饋，並用 Figma Mirror 在實機驗證。

自訂 cubic-bezier 曲線什麼時候才值得用？

當產品需要統一的動態節奏時才值得。同一套 cubic-bezier 參數套用到按鈕、卡片、選單，整套介面的動態調性就會一致，這是成熟設計系統的隱形品質指標。活潑調性可讓曲線帶一點過衝彈性，嚴肅專業則拉得更收斂；單顆按鈕還在試做階段時，內建的 Ease In Out 就夠用。

動畫關閉後，按鈕狀態還能辨識嗎？

應該要能。無障礙原則要求動畫只是回饋層，不是資訊的唯一載體，關掉 prefers-reduced-motion 後，使用者照樣要能從顏色、文字、圖示看出目前是 Default、Loading 還是 Done。若某個狀態只靠動畫才能辨識，就違反了原則；按鈕文字與底色的對比度也要符合 WCAG AA 的 4.5:1。

哪些按鈕其實不該加動態？

大量並列的操作按鈕（如表格每列的編輯鈕）、緊急停止或防呆確認按鈕都不建議加動態。前者動畫數量過多會分散注意力並拖累效能，後者動畫會增加反應延遲感。判斷門檻是「是否需要等待系統回應」：等待型按鈕適合加動態，點下去立即生效的導覽或切換按鈕則建議只做顏色回饋。

原型裡的進度條，上線後為什麼節奏不一樣？

原型用 After delay 模擬的進度條是固定秒數，但實際網站的進度取決於後端 AJAX 或 API 回應速度，設計師無法完全掌控。所以進度條不能設成「一定幾秒跑完」，要能配合真實回應狀態切換，並預留請求失敗時回到 Default 或顯示錯誤狀態的分支。