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

一顆靜態按鈕可能已經具備清楚的文案與對比，但缺少 hover、pressed 或 loading 回饋時，原型仍容易讓人不確定操作是否生效。Figma 的互動組件能把這些狀態先表達清楚，再交給前端實作。

按鈕在畫面上是一個靜態矩形，使用者的手指與滑鼠卻是動態的；兩者之間需要清楚回饋。這篇要帶你從零做出會回應的動態按鈕，而且成品要能交付、能上線，不只在提案當下好看。

快速重點整理：在 Figma 做流暢的按鈕轉場動畫，關鍵是狀態畫清楚、Smart Animate 的圖層對齊，再以約 150 到 300 毫秒作為初始測試範圍，依互動與裝置調整時間與緩動。流暢是克制出來的，不是堆出來的。

動態按鈕在做什麼：把「可點」變成「會回應」

很多人把按鈕動畫理解成「裝飾」，這是第一個要打破的觀念。按鈕會動，本質上是在做三件事：回饋、引導、確認。回饋是告訴使用者「我有收到你的點擊」；引導是讓視線知道「下一步在這裡」；確認是讓操作有一個清楚的開始與結束。把這三件事想清楚，你就會發現很多特效根本是多餘的。

換個方式想：按鈕是介面對使用者講話的最小單位。一個完全不動的按鈕，就像你問店員「這個有現貨嗎」，對方面無表情不回話，你得自己猜。一個有適度回饋的按鈕，則像店員點頭說「有，我幫你包」。互動的品質，決定了使用者對這個產品的信任感。

按鈕動畫的價值在於回應操作、解釋狀態與避免重複提交，不是為了 SEO 排名。做得好時，它是介面裡很小、卻會被反覆觸發的回饋環節。

底下這張表把「靜態按鈕」與「有回饋的動態按鈕」擺在一起，你可以很直接看出差異：

維度	靜態按鈕	有回饋的動態按鈕
滑鼠移過去	毫無反應	底色或陰影微變，暗示可點
點下去的瞬間	畫面直接切換	按鈕先微微內縮，確認收到點擊
送出中的等待	整頁卡住，狀態未知	按鈕變 Loading，告知正在處理
完成後	結果突然冒出	勾選或淡入，給操作一個收尾
使用者的感受	「我剛剛點到了嗎？」	「好，完成了。」

如果你做的按鈕還停留在左邊那一欄，先別急著學動畫軟體，先把「回饋」這件事放進設計思考裡。動態按鈕的核心，從來不是動得多，而是動得有意義。想知道按鈕心理學的更完整脈絡，可以搭配行動呼籲按鈕設計指南一起看，那篇談的是「為什麼要這樣設計按鈕」，這篇談的是「怎麼讓它動得流暢」。

動手前先畫狀態表：一顆按鈕其實有七個分身

按鈕動畫常見問題，往往來自一開始沒把狀態想清楚。在碰原型工具之前，先畫一張狀態表。一顆看似簡單的按鈕，可能有接下來七種狀態：

1. Default（預設）：沒有任何互動時的休息狀態。
2. Hover（懸停）：滑鼠移過去，滑鼠游標所在的狀態。
3. Pressed（按下）：點下去、手指還沒放開的那一瞬間。
4. Focused（聚焦）：用鍵盤 Tab 移到按鈕上時的狀態，常被忽略，卻是無障礙的底線。
5. Disabled（停用）：條件未滿足、不能點的樣子。
6. Loading（載入中）：點擊後、結果還沒回來時的等待狀態。
7. Success 或 Error（成功或失敗）：結果回來之後的回饋狀態。

把這七個狀態列出來，你就會發現「按鈕動畫」根本不是『一段動畫』這麼單純，它其實是七段動畫之間的轉場。每兩個狀態之間，都要回答三個問題：要變動哪些視覺屬性、變動多少、花多少時間。下面是我常用的狀態規格表範例，你可以直接拷貝到自己的設計文件裡：

狀態	底色	邊框	陰影	位移／縮放	文字
Default	主色 100%	無	淺投影	無	白字 100%
Hover	主色加深 8%	無	投影加深	往上 1px	白字 100%
Pressed	主色加深 16%	無	投影收斂	往下 1px 或縮放 0.98	白字 100%
Focused	同 Default	2px 外框	淺投影	無	白字 100%
Disabled	灰階 50%	無	無	無	白字 70%
Loading	主色 70%	無	淺投影	spinner 轉	替換為「處理中」
Success	成功色	無	淺投影	勾選圖示淡入	替換為「完成」

這張表的價值，是讓你在做動畫之前，先把「要變什麼」釘死。沒有這張表，你會在 Figma 裡反覆試顏色、反覆調時間，結果做出一顆每個狀態風格都不一致的按鈕。狀態表先畫好，動畫只是把表格裡的數值，用時間軸串起來而已。對 UI/UX 整體流程還不熟的讀者，建議先讀過UI/UX 設計差異全解析，把狀態放在整個體驗流程裡看，會更清楚每個狀態為什麼存在。

三條動畫路線，挑對的才不會白做工

Figma 做按鈕動畫，主要有三條路線，它們對應不同的目的。很多人把這三條混為一談，結果用了最重的工法，卻只解了最輕的問題。我先把它們拆開給你看。

路線一：Prototype 連線。在 Prototype 面板把兩個 Frame 用箭頭連起來、設一個觸發事件。這是最快展示「按鈕按下去會跑到哪一頁」的方法，但它動的是整個畫面切換，按鈕本身不會變形，也沒辦法被重用。適合用在提案展示流程、或驗證資訊架構的時候。

路線二：Smart Animate。把同一個元件的兩個狀態擺在兩個 Frame 裡，圖層名稱保持一致，Figma 會自動偵測變動的屬性並補上中間的影格。它會動的是元件本身的視覺屬性（顏色、位置、尺寸、透明度），效果接近上線後的過渡動畫。適合用來展示 hover、press、狀態切換這類按鈕自己的變化。

路線三：Interactive Components。把按鈕做成一個 Component Set，每個 variant 是一個狀態，再為每個 variant 綁定 hover、press、click 等事件，指向另一個 variant。做好之後，這顆按鈕在任何地方被使用，都會自帶互動行為，連複製貼上原型連線都不用。這是最接近「上線後真實行為」的做法，也是我最推薦投資時間的路線。

需求	推薦路線	為什麼
只想秀「按了會到哪一頁」	Prototype 連線	五分鐘搞定，不該花更多時間
要展示按鈕自己的 hover 與 press	Smart Animate	自動補間，視覺變化細緻
按鈕要被整個團隊重複使用	Interactive Components	一次做好，到處可用、行為一致
要做完整提交流程（點擊到成功）	Smart Animate 加 Interactive Components	狀態內綁互動、狀態間用補間串
要交付給前端實作	Interactive Components 加 Dev Mode	狀態與參數最完整，工程師看得懂

挑路線的原則很簡單：用最輕的工法，解掉眼前的問題；但如果這顆按鈕會在產品裡重複出現，那就直接投資 Interactive Components，因為它的可重用性會把後面無數次重複勞動省下來。對原型設計整體方法論有興趣的話，UI Prototype 原型設計全解析有更完整的脈絡可以參考。

實作一：用 Component Properties 蓋一顆結構正確的按鈕

動畫要流暢，前提是按鈕的結構要先正確。結構錯了，再厲害的 Smart Animate 也救不回來。我自己在 Figma 裡做按鈕，幾乎都是用同樣的骨架：一個 Auto Layout 容器，裡面放圖示與文字，然後把整組做成 Component，再用 Component Properties 開出變化。

第一步，先用 Auto Layout 把按鈕的內框、外框、間距固定下來。水平置中、垂直置中、內距設定一致，這樣不管文字多長，按鈕都會自己撐出正確的尺寸，不會出現文字黏在邊緣的窘境。

第二步，把按鈕做成 Component，並用四種 Property 開出變化：Variant property 用來切換狀態（Default、Hover、Pressed 等）；Boolean property 用來控制圖示要不要顯示；Text property 用來改按鈕文字；Instance swap property 用來替換圖示。這四個 property 開好，一顆按鈕就能應付幾乎所有使用情境，不必每個情境都重畫一顆。要替換的圖示來源，可以從Figma icon 外掛裡挑一個主家族，搜尋匯入比逐一開網站下載快得多。

第三步，也是最容易漏掉的一步：把 variant 的命名寫清楚。我的命名慣例是「屬性＝值」的組合，例如 State=Hover、Size=Large、Icon=True。這個慣例不是美觀問題，是 Smart Animate 能不能正確運作的生死線。下面會解釋為什麼。

這裡的關鍵觀念是：variant 不是「另一個版本」，而是「同一個按鈕的不同狀態」。所以每個 variant 的內部圖層結構必須一致，圖層名稱也必須一致。Default 裡那層文字叫 Label，Hover 裡那層文字也要叫 Label，不能一個叫 文字、一個叫 Text。Smart Animate 是靠圖層名稱比對來決定「這是同一個東西在變化，還是兩個不同的東西」，名稱不一致，動畫就會「閃一下」就過去了，沒辦法順順銜接。排版與網格的紀律同樣適用在這裡，如果你還沒建立 Figma 網格的習慣，可以先看視差效果教學裡對元件結構的處理方式，觀念是相通的；若連 Figma 的基本操作都還不熟，Figma 完整教學會是更合適的起點。

實作二：Smart Animate 與緩動曲線，決定流暢的兩個參數

結構顧好了，接下來是真正決定「流暢」的兩個參數：時間與緩動曲線。這兩個參數調對，按鈕就會活起來；調錯，再精美的設計都會顯得廉價。

時間可先從 150 到 300 毫秒附近測試，但這不是通用黃金區間。Hover 與 Pressed 通常較短，Loading 或 Success 的視覺切換可以稍長；實際值要看變化距離、裝置輸入方式、品牌動態語言與使用者測試。功能狀態不能因動畫尚未完成而延後生效。

再講緩動曲線。ease-out（開始快、結束慢）常用於元素出現或進入，ease-in-out（兩頭慢、中間快）適合兩個穩定狀態之間的過渡。Linear 適合持續旋轉等需要等速的動作，不是一般 hover 的預設答案；Spring 則要控制回彈幅度，並提供減少動態版本。曲線選擇應服務動作含義，不只追求「有生命力」。

底下這張對照表是我實際工作時常用的參數組合，直接拿去用：

互動類型	推薦時間	推薦緩動曲線	備註
Hover 進入	150 到 200 ms	ease-out	減速收尾，滑鼠移開逆向
Pressed 按下	120 到 180 ms	ease-out	越短越好，確認感優先
顏色狀態切換	200 到 250 ms	ease-in-out	兩頭穩、中間順
Loading 切換	250 到 300 ms	ease-in-out	給使用者時間意識到變化
Success 圖示淡入	200 到 300 ms	ease-out	可加輕微 scale 放大
錯誤抖動	300 到 400 ms 起測	Spring 或自訂曲線	避免引發不適，並提供減少動態版本

還有一個細節：Smart Animate 會依圖層名稱與階層比對要補間的物件。剛剛實作裡強調過的命名規範，在這裡就會發揮作用。兩個 Frame 裡若有對應圖層名稱或階層不一致，可能改用淡入淡出或無法如預期補間。把名稱與結構對齊，是流暢的隱形地基。

實作三：互動組件讓按鈕自己回應 hover 與點擊

Smart Animate 雖然強，但它有一個限制：要觸發動畫，你得到 Prototype 面板手動拉一條連線，指定「點了這個按鈕，跳到那個 Frame」。這在展示單一場景時沒問題，但如果這顆按鈕出現在二十個畫面裡，你就要拉二十次連線。這就是 Interactive Components（互動組件）要解決的問題。

做法是這樣：先有一個 Component Set，裡面包含 Default、Hover、Pressed 等 variant。然後在 Prototype 面板，選到 Default 這個 variant，按「While Hover」，Trigger 設為「Change to」，目標選 Hover variant；同理，按「While Pressing」，目標選 Pressed variant。設定完之後，這顆按鈕在 Prototype 模式下，就會自己回應滑鼠與點擊，完全不需要再拉連線。

更棒的是，只要這顆按鈕被發佈到 Team Library，團隊任何人在任何檔案使用它，都會自帶這些互動行為。設計系統的價值就在這裡：一次定義，到處一致。我把這種按鈕稱為「會自己照顧自己的按鈕」，它把互動的責任從每個使用情境，收回到組件本身，設計師不用再擔心某個畫面的按鈕忘記加 hover。

要驗收成果，點右上角的 Present（展示）按鈕，把滑鼠移到按鈕上、按下去，看看動畫是不是如預期。若沒有反應，先檢查 variant 之間的圖層名稱、互動 Trigger 與按鈕是否為 Component instance。載入狀態可搭配Figma 載入動畫教學的 spinner 做法一起看。

連續狀態轉場：從點擊、載入到成功的完整動畫敘事

單一狀態的動畫不難，真正考驗功力的是連續狀態轉場。一個送出表單的按鈕，會經歷這樣的旅程：使用者點下去（Pressed）、按鈕變成 Loading 轉圈、等後端回應、最終變成 Success 打勾、再回到 Default。這整段旅程，就是一個微型的動畫敘事，每一站之間都要有順暢的轉場；這種圍繞單一操作、把狀態與回饋串成一段完整流程的做法，正是微互動設計的核心。

我的做法是用 Smart Animate 把每兩個狀態之間補間，再用 Interactive Components 在 Pressed 狀態綁一個「After delay → change to Loading」的事件，讓點擊後自動進入載入。Loading 狀態裡放一個旋轉的 spinner，這個 spinner 本身用一個獨立的 component 做循環動畫；等到要展示 Success 時，再用 Smart Animate 把 spinner 換成勾選圖示，搭配 200 到 300 毫秒的 ease-out 淡入與輕微放大。

文字與圖示可分層處理：文字「送出」在 Loading 階段淡出、被「處理中」取代，圖示位置留給 spinner，避免視覺重心跳動。Success 是否自動回到 Default，則要看真實產品流程；原型展示可以用 After delay 模擬，但上線後應由後端結果與下一步操作決定，不能一律在 1500 毫秒後重設。

如果你打算把這段連續動畫真正上線，會碰到一個選擇：用 CSS 與 JavaScript 在瀏覽器裡寫，還是匯出成 Lottie 動畫檔。CSS 適合簡單的顏色與位移過渡，效能好、可控性高；Lottie 適合複雜的路徑動畫（例如勾選圖示的筆畫動畫），跨平台一致。兩者的取捨與匯出細節，Lottie 動畫完全指南講得很清楚，建議交給前端之前先讀過一次。

把動態按鈕收進設計系統：讓一次用心變成團隊資產

一顆做得很到位的動態按鈕，如果只活在單一 Figma 檔案裡，價值就很有限。把它收進設計系統，能讓團隊在不同畫面重用已驗證的狀態與參數，減少重複設計與實作落差。

收進設計系統，第一件事是文件化。一顆動態按鈕的文件，至少要涵蓋四個區塊：所有 variant 的預覽、每段轉場的時間與緩動參數、do 與 don't 的視覺範例、以及反向動畫的說明。很多團隊只放了 variant 預覽，參數與反向動畫卻沒寫，結果工程師實作時各憑想像，每個產品線做出來的按鈕都長得不一樣。文件不是寫好看的，是拿來消除歧義的；少寫一行參數，下游就多一個猜測空間。

第二件事是版本管理。設計系統裡的按鈕遲早會被改，可能是調整品牌色、微調時間參數，也可能是新增 Success 之外的 Error 狀態。改的時候要有紀律：每一次改動都要記錄改了什麼、為什麼改、影響哪些使用端。可以在 component 的 description 留一個簡短 changelog，標註日期與原因；出現異常時，團隊就能沿著紀錄縮小範圍，不必把整個月的工作攤開來找。

第三件事是命名與發佈的紀律。前面提過的 variant 命名慣例，在設計系統層級要更嚴格，因為它會被很多人引用。命名一旦改了，所有引用端都要同步更新，成本很高，所以一開始就要想清楚，盡量用穩定、語意清楚的屬性名（State、Size、Icon、Type），避免用短期促銷或專案代稱。發佈到 Team Library 之前，先在測試檔案裡跑過一輪互動，確認 hover、press、loading、success 全部如預期，再正式發佈。這個動作就像寫程式要跑測試一樣，花五分鐘驗收，可以替整個團隊省下幾小時的除錯。

設計系統收納動作	常見漏掉的點	後果
variant 預覽	只放 Default，漏放 Loading 與 Success	下游不知道這些狀態存在
轉場參數	只標時間，漏標緩動曲線	工程師用預設 linear，動起來僵硬
反向動畫	只標進入，漏標離場	hover 離開時硬切，細節崩掉
版本紀錄	改了不寫原因	出問題時追不出是哪次改動
無障礙註記	沒標示減動態模式的處理	前端不知道要支援 prefers-reduced-motion

把動態按鈕收進設計系統，本質上把你個人的判斷轉成團隊的標準。這也是我會建議的取捨：與其花心力在每個專案重做一顆新按鈕，不如把一顆按鈕做到位、文件寫清楚、發佈出去。前者解一個問題，後者解一百個。設計系統的成熟度，往往就反映在這種『把一次性用心，變成可重複資產』的紀律上。想延伸看設計系統如何跟響應式排版搭配運作，可以參考Figma 響應式設計教學。

交付不翻車：把動畫參數翻譯成前端能讀的規格

在 Figma 裡把按鈕動得再漂亮，如果沒辦法讓前端工程師重現，交付仍不完整。除了視覺，還要提供時間、緩動、觸發條件、狀態來源與減少動態時的替代行為。

Dev Mode 能協助查看樣式、間距與變數，但動畫資訊在不同檔案與 Figma 版本中的呈現可能不同。不要依賴它自動補齊規格；在 component 的 Description 或 Annotations 裡，明確寫出每個狀態轉場的參數：

Hover 過場：背景色由 #2563EB 過渡到 #1D4ED8，時間 180ms，緩動 ease-out。
Pressed 過場：scale 由 1 縮到 0.98，時間 140ms，緩動 ease-out。
Loading 切換：文字淡出、spinner 淡入，時間 250ms，緩動 ease-in-out。

對應到 CSS，工程師看到的就是 transition: background-color 180ms ease-out、transition: transform 140ms ease-out 這樣清楚的規格。transform 與 opacity 通常較容易維持流暢；background-color 需要重繪，但短促的小面積顏色過場通常仍可接受，應以實機效能分析為準。

交付時還有一個容易被放過的點：狀態之間的「反向動畫」。滑鼠移開按鈕，Hover 要退回 Default，這個退回也要有時間與緩動，通常是進入時的一半到三分之二長。多數設計師只標進入、忘記標退回，結果前端做出來，移開時是硬切的，整個按鈕就會「進場柔順、離場僵硬」，細節就崩了。把這些交付細節想成設計的一部分，別丟給工程師自己看著辦，你的按鈕才會真的如設計稿那樣流暢。想更全面地檢視一個網頁作品該具備哪些元素，可以參考網頁設計必備的 8 個關鍵元素。

動畫的兩條紅線：效能與無障礙

按鈕動畫有兩條不能踩的紅線，一條叫效能，一條叫無障礙。踩了任一條，再漂亮的動畫都會變成傷害。

動畫卡頓常和版面重新計算、繪製及合成成本有關。transform 與 opacity 通常較容易保持流暢；width、height、top、left 等可能觸發版面計算，但實際成本仍取決於頁面。設計時可優先採用能對應 transform 的縮放與位移，並以瀏覽器效能分析驗證。速度會影響使用體驗與商業成果（見 web.dev 的〈Why does speed matter?〉，2026），但頁面體驗只是搜尋系統考量的許多面向之一（見 Google Search Central Blog 的〈Evaluating page experience〉，2020 年 5 月）。

再講無障礙，這條紅線更常被忽略。有一部分使用者（約有一定比例的人口，例如前庭功能較敏感的人）對動態畫面會產生暈眩或不適，作業系統因此提供了「減少動態效果」（prefers-reduced-motion）的設定。一個負責任的按鈕動畫，必須在前端實作時配上媒體查詢，偵測到這個設定就把動畫關掉或大幅縮短。設計端能做的事，是標註「動畫是增強體驗、不是必要資訊」，讓前端知道這個動畫可以安全地被關掉，而不會影響功能理解。

焦點狀態（Focused）是無障礙這條紅線裡另一個容易被忘記的底線。很多設計師做了漂亮的 hover，卻忘了鍵盤使用者根本沒有滑鼠可以 hover。Focused 狀態要有一個清楚的外框，讓只用鍵盤 Tab 的人也能看到自己目前在哪顆按鈕上。這不是裝飾，是讓產品能不能被更多人使用的關鍵。行動裝置上還要額外注意：hover 在觸控螢幕上沒有意義（手指點下去就是 pressed），所以別把重要回饋只綁在 hover 上。響應式與行動版的整體處理，可以搭配響應式網頁設計 RWD一起思考。

我踩過的坑：五個讓按鈕動畫變災難的常見錯誤

教了這麼多觀念，老實說，多數按鈕動畫的問題往往不出在技術，主因是幾個反覆出現的壞習慣。底下這五個，是我自己在工作中、以及陪別的設計師檢查稿件時，一再看見的坑。把它們列成檢查表，你做出的按鈕動畫會立刻成熟一截。

坑一：variant 命名不一致，動畫永遠閃一下。這個問題前面提過，但值得再講一次，因為它發生的頻率最高。Default 的圖層叫 背景，Hover 的同一層叫 Rectangle 12，Smart Animate 比對失敗，動畫就變成溶解切換。解法很無聊但有效：每畫一個新狀態，先把圖層名稱逐一核對一遍，再開始調動畫。

坑二：短促操作的過場拖得太久，按鈕看起來像卡住。Hover 若慢到讓回饋落後於指標移動，使用者可能誤以為按鈕沒有反應。150 到 300 毫秒可作為常見起始範圍，再依狀態、距離、裝置與實機感受調整；它不是所有按鈕都必須遵守的硬門檻。

坑三：動到 width 或 height，上線後一頓一頓。這個坑在 Figma 裡看不出來，因為 Figma 的即時運算夠快；但上了瀏覽器、特別是手機瀏覽器，就會現形。按鈕放大如果用改寬高來做，滾動加上動畫同時發生時就會掉幀。能換成 transform 就換成 transform，這是設計階段就能決定的事。

坑四：忘了設 Focused 狀態，鍵盤使用者迷路。這個坑最容易被原諒，也最不該被原諒。你只要在 Figma 多畫一個 variant、多標一行參數，就能讓一批使用者不被排除在外。設計的成熟度，常常就顯現在這種「多做一步」的地方。

坑五：動畫打斷點擊，使用者氣到點第二下。點擊後按鈕進入 Loading，但 Loading 動畫太複雜、或覆蓋了點擊區域，使用者以為沒點到，又點一次，於是表單被送出兩次。連續狀態轉場設計時，務必保留按鈕的點擊區域不被遮蔽，Loading 期間也要把按鈕設為不可再點（對應 Disabled 的視覺），避免重複送出。這條特別重要，因為它直接影響資料正確性。

這五個坑的共同特徵是：它們的破口在「沒想到」，技術上其實都做得到。把這份清單貼在螢幕旁邊，每次交件前跑一遍，你會省下無數次與工程師、與客戶來回的時間。

培養判斷力：怎麼用眼睛看出一顆按鈕順不順

參數背得再熟，最終把關的還是眼睛。一顆按鈕順不順，數值只是線索，真正決定它能不能上線的，是你看著它時的那個直覺反應。這個直覺可以訓練，而且訓練的方法比你想的簡單，重點是把動畫『拆開來看』，而不是只看它跑完一遍的感覺。

第一個練習是放慢。Figma 的 Prototype 預設是真實速度，動畫一閃即過，很難看清細節。你可以把動畫時間暫時乘以三（原本 180 毫秒故意設成 540 毫秒），反覆播放，觀察按鈕在每個影格的變化。看久了，你會開始察覺哪些屬性變化太突兀、哪些過渡其實可以再柔一點。這個放慢觀察的習慣，是培養品味最快的路，因為它強迫你看見那些在正常速度下被掩蓋的瑕疵。

第二個練習是對比。把你的按鈕跟幾個你公認做得很成熟的產品擺在一起，同樣做 hover、同樣做 press，逐影格比對。你會發現成熟產品的按鈕，動的屬性通常很少（往往只有陰影、底色、transform），但每一個都精準；業餘的按鈕則甚麼都想動，邊框、字距、連圖示角度都要跟著轉，反而顯得浮躁。這個對比會幫你建立『少即是多』的直覺，知道哪些屬性是真正必要的回饋，哪些只是設計師的自我感覺良好。

第三個練習是看邊界。按鈕動畫最容易出現破綻的地方，是狀態切換的銜接點：hover 進入與離開是否對稱、pressed 結束後是否乾淨回到 Default、Loading 出現時是否壓到原本的文字。把注意力放在這些接縫，而非動畫的主體，你會看到完全不同的問題。一顆按鈕的質感，往往就藏在這些銜接的零點幾秒裡。底下這份自我檢查表，是我每次交件前一定會跑的清單：

檢查項目	通過標準
Hover 進入與離開	都有過場，時間與曲線大致對稱
Pressed 收尾	放開後乾淨回到 Default，不殘留
Loading 銜接	文字與 spinner 不疊在一起
Success 停留	依產品流程決定保留、導頁或重設，不套固定秒數
Focused 外框	鍵盤 Tab 能看見，不依賴滑鼠
減動態模式	關閉動畫後仍能理解按鈕狀態
觸控裝置	沒有滑鼠也能完成主要回饋

這份清單的用途，是讓『順不順』這件主觀的事，變成可以一項一項打勾的客觀檢查。當你能夠在沒有任何參數提示下，光看動畫就判斷出哪裡卡、哪裡跳、哪裡該加一點緩動，你的按鈕設計就脫離了套參數的階段，進入真正用判斷力做設計的層次。色彩與排版也有類似的『眼睛把關』訓練，想延伸可以看色彩心理學設計攻略，那篇談的是顏色如何影響感受，跟這篇談的動態回饋是同一套『為感受而設計』的觀念。

把這些觀念變成你的下一步

讀到這裡，你手裡應該已經有完整的藍圖：狀態表、三條動畫路線、Smart Animate 與緩動曲線、Interactive Components、連續狀態轉場、交付規格、效能與無障礙紅線，以及五個常見坑。接下來，就是把它們一個一個變成你肌肉記憶裡的東西。我幫你把行動收斂成五個具體步驟：

1. 挑一顆你手邊正在做的按鈕，畫出它的狀態表。不用七個全做，先把 Default、Hover、Pressed、Focused 四個釘出來，底色、陰影、位移各是多少，寫下來。
2. 用 Component Properties 重新搭這顆按鈕。Auto Layout 加 Variant 加 Boolean 加 Text，把結構調正，圖層命名統一。這一步做好，後面全部輕鬆。
3. 用 Smart Animate 加上 hover 過場。可先用 180 毫秒與 ease-out 試做；不順時，依序檢查圖層名稱、階層、對應屬性與元件連線。
4. 把按鈕升級成 Interactive Component。綁好 While Hover 與 While Pressing，發佈到 Team Library，讓它以後到處可用。
5. 在交件文件裡補上動畫參數與無障礙註記。時間、緩動、transform 屬性、prefers-reduced-motion 對應，全部寫清楚，前端會感謝你。

這五步走完，你做出來的就不只是一顆「會動的按鈕」，而是一顆有結構、可重用、能交付、對所有使用者友善的成熟元件。這中間的差別，正是業餘與專業的分野。如果你還想進一步把按鈕放進完整的轉換流程裡思考，CTA 行動呼籲設計指南會告訴你按鈕文案與心理學怎麼跟動畫搭配；想把這些設計真正變成能帶來詢問的網站，Landing Page 轉換率優化全攻略則有更完整的轉換視角可以接著讀。

還有一件事值得放在心裡：按鈕動畫是會被無數次重複觸發的細節，它的成本與效益都會被放大。一個 180 毫秒的 hover，單看一次微不足道，但一個使用者走完一次結帳流程，可能會碰到十幾顆按鈕；一個月的累積下來，就是幾萬次互動。正因如此，我會反覆強調克制，因為每一毫秒、每一個不必要的屬性變化，都會在這個規模下被放大成真實的體感差異。把按鈕動畫做好，很難在第一天就被看見，卻會在產品被用了半年之後，沉澱成別人難以模仿的競爭力。

動畫的流暢，說穿了就是一份對使用者的體貼：在對的時機、用對的力道、回應他剛剛做的事。把這份體貼放進每一顆按鈕裡，你的產品自然會有一種說不上來、卻讓人想一直用下去的質感。