Figma 按鈕動畫卡卡的？流暢的關鍵在開始動之前就決定

提案螢幕前，客戶把游標移到「立即購買」上，停了一秒，按鈕毫無動靜。對方回頭問：這顆是不是壞了？同一天，客服信箱裡出現同一筆訂單被送出兩次的信，因為按下之後畫面沒有變化，使用者以為沒點到，又補了一次。先說清楚：這兩個畫面都是為了示範而建構的情境，不是哪家的真實案例，但它們指向的麻煩每天都在發生。

兩個畫面常被歸因於同一句話：動畫不夠順。於是有人急著打開原型工具，調時長、換曲線、加效果。可惜方向多半錯了。決定流暢與否的變因，大部分在按下播放之前就定案：狀態的邊界定義、圖層的結構紀律；時長與曲線只是最外層的微調，調得再細，也救不回沒想清楚的狀態。

接下來不走操作步驟的路線，先走判斷流程：這個問題該不該用動畫解、要做多少狀態、選哪條工具路線、節奏怎麼取捨、怎麼驗收交件。帶著問題進來，離開時手上會是一套可執行的決定，而不是一段照著做卻說不出理由的動畫。

快速重點：按鈕動畫的價值在回饋與防錯，不在裝飾。流暢的主要變因在按下播放之前：狀態邊界先定義、圖層命名有紀律，時長與曲線只是最外層微調。動手前先診斷症狀、盤點狀態、替按鈕分級；轉場以 150 到 300 毫秒起測，交件前用驗收表把「順」變成可檢查的項目。

先判斷，你的按鈕問題真的是動畫嗎？

「按鈕很怪」「按了沒反應」「卡卡的」，這類回饋其實是好線索，麻煩在於它們常被直接翻譯成「去加動畫」。拿到回饋先做一件事：把症狀分類，再看它指向哪一層。看起來沒反應、被重複點擊、流程看不懂，各自對應不同的問題層，解法也不一樣。

「按了沒反應」最值得先拆。它可能是指標回饋缺失，按下去畫面什麼都沒變；但也可能只是對比不足，按鈕和背景幾乎融在一起，游標移上去連指標的樣子都沒換。後者改一個顏色就解決，完全不必打開原型工具。靜態基礎先過關：文案講清楚後果、對比足夠、尺寸好點、位置順著動線。這一關沒過，後面全部不用做。

↔ 左右捲動檢視完整表格

症狀	常見真正原因	問題所在層	動畫是不是解方
看起來沒反應	對比不足、游標沒變化	靜態結構	不一定，先改顏色與游標
按了沒反應	缺少按下回饋	狀態層	是，補 Pressed
被重複點擊	等待沒有被隔離	狀態層	是，補 Loading 並鎖住
流程看不懂	結果沒有被標示	狀態層	是，補 Success 與 Error
動畫閃跳接不起來	圖層命名與階層不一致	結構層	先修結構，再談動畫

「卡卡的」還可以再拆細一步。卡的感受通常來自三個源頭：回饋晚到，按下去要等一下才有反應；節奏不一，進場一種速度、離場另一種速度；屬性打架，文字換了、底色換了、圖示也在轉，眼睛不知道該看哪個。三個源頭對應的修法各不相同，把它們混在一起講，回饋就會變成各說各話。

症狀表背後是一個三層變因模型。結構層的優先順序最高：圖層命名、階層與 Auto Layout 骨架，決定動畫有沒有材料可以補間。狀態層居中：邊界定義，決定動畫該在哪裡發生、為誰發生。參數層最外：時長與曲線，決定發生的當下好不好看。除錯由上而下，先確認結構與狀態，再動參數；順序顛倒，就會在參數層無限試錯，而病根根本不在那裡。

回到開頭建構的結帳情境：按鈕被連點兩次，代價是重複訂單、退款流程與客服成本。用錯誤代價衡量，這顆按鈕的投資順序會自動往前排，因為它動的不只是視覺，還有資料的正確性。動畫在這裡不是裝飾預算，是防錯投資，這也是貫穿全文的判準。

靜態基礎裡的文案與說服層，是另一門功夫：按鈕文字怎麼寫、行動呼籲怎麼設計，CTA 按鈕的設計原則與行動呼籲設計的完整指南兩篇有各自的拆解；這篇處理的範圍放在動之前與動之中的判斷。

按鈕不是一段動畫，是七個狀態之間的邊界

把一顆按鈕想清楚，等於把它的狀態盤點完。多數人打開工具就開始拉時間軸，跳過的正是這一步：狀態沒有邊界，動畫就沒有出發點與目的地，做出來的轉場只是兩張靜態稿之間的猜測。

一張完整的狀態地圖包含 Default、Hover、Pressed、Loading、Success、Error、Disabled 七種：Default 是休息中的樣子，Hover 回應游標停留，Pressed 收下點擊的瞬間，Loading 把等待隔離出來，Success 與 Error 標示結果的兩種走向，Disabled 說明條件還沒滿足。按鈕動畫不是一段影片，而是這七個狀態之間的邊界集合；地圖上少畫一個狀態，實作時就多一個各憑想像的接縫。每一條邊界都要回答四件事：動哪些屬性、變動多少、花多久、反向怎麼退回。

這四件事填進表格，就是先於時間軸的狀態規格表。表格不必精美，但要先填：

↔ 左右捲動檢視完整表格

邊界	動哪些屬性	變動量	起測時間	反向行為
Default 到 Hover	底色、透明度、位移	色階一階、位移一像素級	150 到 200 毫秒	移開即退場，約進場的二分之一到三分之二
Hover 到 Pressed	底色、內縮	色階再一階、縮至 0.98	120 到 180 毫秒	放開退回 Hover 或 Default
Default 到 Loading	文字淡出、旋轉圖示淡入	文字層與圖示層分開換	200 到 300 毫秒	依流程分流，失敗改走 Error
Loading 到 Success	旋轉換勾選、底色換成功色	圖示替換加輕微放大	200 到 300 毫秒	停留依流程決定，不自動重設
Loading 到 Error	底色換錯誤色、訊息出現	顏色與文字同步切換	200 到 300 毫秒	搖晃要克制，並提供減動態版本

表格填完，動畫只是把這些數值串上時間軸的方式。跳過表格直接做動畫，等於邊剪邊量窗簾，成品十之八九要重來。規格表同時是團隊的共同語言：設計端寫下判斷，實作端照著還原，來回修改的次數會直接反映在時程上。

規格表還有一個長期用處：它是活的文件。專案後期要新增狀態，例如行銷要求加一個限時倒數的樣式，先在表上補一列，把四個問題回答完，再進工具補畫；順序對了，新狀態會自然長在原本的結構上，不會多出一個突兀的例外。表格停下來的地方，通常就是之後出問題的地方。

不是每顆按鈕都要七個狀態全做，這是盤點，不是採購清單。送出資料的按鈕，Loading 與 Error 不能省；連往別頁的資訊連結，Default 加 Hover 兩種可能就夠。最常被跳過的是 Error 與 Disabled：前者對應資料正確性，送出失敗沒有畫面，使用者只會再按一次；後者對應期待管理，條件未滿足時按鈕看起來卻跟正常的一樣，點了沒反應，帳會算到產品頭上。

狀態要放進整頁流程檢視，而不是單顆按鈕自嗨。同一顆送出鈕，表單沒填完時是 Disabled，填完切回 Default，這段切換本身就是體驗的一部分；單顆按鈕做得再細，流程斷在別處，使用者記住的還是那個斷點。把狀態放回整條使用者旅程的框架，可以搭配UI 與 UX 的完整解析一起看，會更清楚每個狀態為誰存在。

不是每顆按鈕都值得做到完整轉場

團隊時間有限，把每顆按鈕都做到七狀態，等於沒有一顆做到位。分級用兩個軸：出現頻率乘上錯誤代價。頻率高、錯一次代價大的，做完整狀態轉場並收進團隊庫；頻率高但可逆的，做基本回饋；低頻的工具性操作，最小回饋就夠。

↔ 左右捲動檢視完整表格

層級	判準	必要狀態	建議工法	省略的風險
主要轉換	金流、送出、預約等不可逆操作	全套，含 Loading 與 Error	互動組件加補間轉場	重複送出、失敗無回報
次要行動	與主要並列但可逆	Default、Hover、Pressed	變體加基本回饋	觸感廉價，功能不損
工具性操作	表格列、工具列、內部功能	Default、Pressed	最小回饋	幾乎無風險

把開頭的結帳情境再往前推一步（同樣是建構示範）：結帳主按鈕在一次流程內被觸發十幾次，錯一次的代價是真金白銀；同一個後台裡，表格每列的編輯鈕整頁幾十顆，點錯關掉重來就好。兩者的投資判斷完全不同，工時留給前者，是這套分級最實際的產出。

分級也不是一次定終身。活動頁的臨時按鈕被留下來變成常態功能、內部工具開放給客戶使用，都會讓原本的工具性操作升級成次要甚至主要；升級的訊號通常來自使用者回饋或行為數據，鮮少出自設計端的主觀意願。固定的做法是每隔一陣子回頭看一次分級表，把升級的補做、降級的簡化，讓投資持續對準真實的使用頻率。

分級結論還可以直接拿到排程會議上用。主要級的完整轉場要估多少工時、次要級的基本回饋怎麼併進既有元件庫，這些問題在分級表上已經有答案；比起「動畫要不要做」這種各執一詞的討論，把問題換成「這顆屬於哪一級」，會議會快很多。

明說不做，也是合法輸出。反向決策清單：

• 內部工具、活動臨時頁、已排在汰換的流程：不做，做了也是丟進垃圾桶的工。
• 立即生效的導覽切換：顏色回饋就夠，動畫反而拖慢節奏。
• 緊急停止與防呆確認類操作：寧可搶眼，不要優雅；辨識速度優先於質感。

主要級的成果要收進團隊庫，三件事不能省：變體預覽與轉場參數文件化，讓人看得到每個狀態的長相與規格；do 與 don't 對照，把判斷理由視覺化；改動留紀錄，出問題時追得到是哪次調整。分級結論也要放回整頁轉換脈絡檢視，按鈕只是轉換鏈上的一環，文案怎麼影響行動、著陸頁怎麼承接流量，CTA 優化的做法與著陸頁轉換的完整攻略兩篇各自展開。

連線、Smart Animate 或互動組件，先問目的再挑工具

Figma 做按鈕動畫有三條常見路線，對應三種問題：要展示「按了會到哪一頁」，用 Prototype 連線；要演示按鈕自身的狀態變化，用 Smart Animate；要交付給全案重用，把按鈕做成互動組件。選擇軸是你要向誰回答什麼問題，不是工法難度；用最重的工法解最輕的問題，是浪費工時的主要來源。

↔ 左右捲動檢視完整表格

目的	路線	時間成本	產出物
提案展示流程	Prototype 連線	最低	可點擊的流程稿
演示按鈕狀態變化	Smart Animate	中	狀態間的補間動畫
交付與全案重用	互動組件	最高	自帶互動行為的元件
完整提交流程	互動組件加補間	高	可重用的全套轉場

三條路線也不是互斥的三選一。連線上可以把轉場設成 Smart Animate，讓兩個畫面裡相符的圖層補間；完整的提交流程，常是互動組件撐住狀態、補間負責轉場的組合。把它們當成一條光譜，別當成三個互斥的格子，選擇會靈活很多。

互動組件的能力範圍，官方文件寫得直接：在同一個元件集合裡，可以在變體之間設定原型轉場，讓單一實例自己回應滑鼠與觸控（見Figma 說明中心對變體互動組件的說明）。文件同時劃出邊界：Figma 原型是設計與開發之間的溝通介質，正式產品裡的按鈕行為，仍要由前端實作和測試才算數。

想看實際操作的節奏，官方也留了一支教學影片，示範在變體之間建立互動的完整過程（Figma 官方的互動組件教學，2021 年 10 月出品）。影片介面比現在的版本早，設定名稱與操作以現行說明文件為準；這個新舊差異本身就是提醒：工具細節會改，文件的效期比影片長，卡住時先查文件。

按下與放開的對應關係，官方按鈕教程有明確定義（Figma 的互動按鈕設計教程）：Mouse down 與 Touch press 進入 Pressed，Mouse up 與 Touch release 處理放開，While pressing 指的是按住期間的暫時狀態。分清這三個觸發時機，按下該有的回饋才不會遲到，也不會重複。

互動組件換到別的情境還要補課：拖曳調值的滑桿、自動輪播的內容，除了狀態，還得交代數值怎麼對應、斷點上行為怎麼變，滑桿與輪播的規格細節有完整拆解。原型方法的整體輪廓，UI 原型設計的全解析補齊前提，先有方法再挑工具，順序不會錯。

三條路線有個共通的練習法：挑一顆按鈕，同一顆，分別用三條路線各做一次。做完之後，什麼場合該用什麼路線會變成身體記憶，不必回頭翻對照表；成本一個下午，受用的時間比想像中長。

動畫閃一下、跳一下，問題多半出在圖層命名

Smart Animate 的補間不是魔法，是比對。它靠圖層名稱與階層判斷兩個畫面裡哪些圖層是同一個東西：名稱與階層一致的圖層做屬性補間，比對不到的就退化成溶解淡切（見Figma 對 Smart Animate 圖層比對的說明）。效果類屬性也在邊界外：同一份官方文件寫明，帶陰影或內陰影效果的圖層不做補間，整層退回溶解；hover 想換陰影時，寧可當靜態切換處理，層次感交給透明度與位移。動畫閃一下、跳一下，多半是比對失敗，不是參數沒調好。

溶解淡切本身不是缺陷，它有合理的用途：兩個畫面之間沒有對應關係的內容替換，例如整段文字換成完全不同的段落，用溶解反而誠實。要避免的是「明明是同一顆按鈕，卻被當成兩個沒關係的東西」；判斷的標準始終是內容有沒有延續，不是效果看起來高級與否。

常見的破壞源有三種：

• 拷貝狀態後順手改名，同一層在兩個畫面裡名字不同，比對直接落空。
• 群組多包一層，階層深度變了，即使名稱相同也對不上。
• 文字層命名中英混用，一個畫面叫標籤、另一個叫 Label，補間就斷在這裡。

一個常見誤解要分開講：變體的屬性命名，像 State=Hover 這種寫法，是給團隊選狀態用的；圖層配對看的是各狀態內部圖層的名稱與階層。兩件事都重要，但不可混為一談；把屬性命名當成補間成功的保證，是除錯時最常繞的遠路。

把紀律落地，靠的是一份命名慣例加上一個檢查時機。命名慣例不用長，一頁就夠：容器怎麼叫、文字層怎麼叫、圖示層怎麼叫，中英文擇一。檢查時機更重要：每新增一個狀態，先逐層核對名稱與階層，核對完才開始調動畫。把檢查放在新增的當下，成本是一分鐘；放到動畫怪了才回頭找，成本是整個下午。

骨架的搭建順序，決定之後全部的紀律：

1. Auto Layout 容器先固定，內距與對齊一致，文字再長也撐得出正確尺寸。
2. 圖示與文字各佔一層，狀態之間才能分開替換、分開淡換。
3. 整組做成 Component，讓它成為可以被引用的單位。
4. 開四種 Properties：variant 切狀態、boolean 控制圖示顯示、text 改按鈕文字、instance swap 換圖示，一顆按鈕應付大多數情境。

圖示從Figma 的圖示外掛挑單一主家族匯入，狀態之間的風格才不會漂移。這套結構紀律也能遷移到其他動效：視差效果的圖層管理用的是同一套肌肉；基本操作還不熟，先從Figma 的完整教學打底，再回來談動態。

150 到 300 毫秒是起測範圍，不是標準答案

時長的判斷起點是知覺，不是美感。回饋要跟得上指標與手指，所以偏短；等待要能被解讀，所以稍長。曲線跟動作含義走：進入用 ease-out，收尾減速像落地；穩態之間的過渡用 ease-in-out，兩頭穩、中間順；linear 只留給等速旋轉，拿來做 hover 會有機械感。實際值依變化距離、輸入方式與實機感受調整。

↔ 左右捲動檢視完整表格

互動	起測時間	曲線	判斷理由
Hover 進入	150 到 200 毫秒	ease-out	要跟上游標移動，慢了像沒反應
Pressed	120 到 180 毫秒	ease-out	確認優先，越短越乾淨
顏色切換	200 到 250 毫秒	ease-in-out	兩頭穩，中間不搶注意力
Loading 切換	250 到 300 毫秒	ease-in-out	給眼睛時間意識到狀態變了
Success 圖示	200 到 300 毫秒	ease-out	收尾要被看見，但不搶戲

這些數字全部是起測值，不是規格。表格真正的用處，是把判斷理由寫下來：換專案時知道哪些該調、哪些是底線；被問為什麼是這個數字時，答得出「跟上游標」，不會只答「看起來順」。

兩個變因會拉動數字。變化距離是第一個：位移或縮放幅度越大，時間要跟著放寬，同樣 150 毫秒，移動兩像素很從容，移動兩百像素就像閃現。輸入方式是第二個：手指的接觸面積大、精準度低，回饋要更明確，觸控情境下的按下回饋常常要比滑鼠稍長也稍大，才跟得上手指的感知。起測之後，在實機上感受幾輪，比照抄任何別人的參數表都可靠。

反向動畫最常被漏。退場時間沒有官方定值，實務上常以進場的二分之一到三分之二當起測點，再依實機感受調整；只標進場，前端做出來就是進場柔順、離場硬切，質感剛好斷在收尾一格。規格表上每一行都該有反向欄位，空白就等於把決定丟給實作端猜。

功能優先的三條底線：

• 狀態生效不等動畫播完，確認型點擊越短越好，回饋不能擋操作。
• Spring 回彈要控制幅度，並提供減動態版本，彈跳不是每個人都受得了。
• 動的屬性少而準；工作上的經驗門檻是一次不超過三個屬性，超過這個數字，回饋常淪為眼睛追不上的噪音，這是便於檢查的判準，不是量測出來的定律。

Loading 的節奏與旋轉圖示的循環是另一門手工，載入動畫的完整做法那篇接手，這裡只留一句：等待狀態的動態要有韻律，但不要喧賓奪主。

送出那一刻，從點擊到結果的每一段都是轉場

送出類按鈕的旅程可以拆成四站：點擊先被收下，按鈕進入 Pressed；接著切到 Loading，把等待隔離出來；結果回來，依真實回應顯示 Success 或 Error，不是只有成功一條路；要不要退回 Default、何時重設，由產品的真實流程決定，不是固定的秒數。每一段都是轉場，串起來才構成完整的回饋。

這條旅程同時是防線。Loading 期間把按鈕鎖住，視覺上對應 Disabled 的樣子，再點擊不生效；點擊區不被動畫元素遮蔽，旋轉圖示轉得再好看，也不能蓋住熱區。開頭那筆被送出兩次的訂單，缺的就是這兩道鎖；把等待隔離、把結果講清楚，能壓低連點的動機與流程的困惑，但前端回饋不是保證，重複訂單的最後一道防線，仍要靠後端的冪等或防呆機制守住。

把視野拉高一點，這種圍繞單一操作，把觸發、回饋與結果收攏成一段緊密流程的做法，就是微互動設計的骨架。微互動的價值不在單格動畫好看，而在每一段回饋都回答使用者心裡的問題：點到了嗎、正在處理嗎、成了沒。按鈕是體積最小的微互動載體，也是被反覆觸發最多的一個，把旅程走完整，比把單格做得華麗重要。

Error 畫面常被做成一句「發生錯誤」加個叉，這其實浪費了整段防線。錯誤出現時，使用者需要的下一個動作要一起給：重試的入口、修改資料的連結，或至少一句講得出原因的訊息。按鈕的復位時機跟著這個走：允許重試就回到可點的狀態，要修改資料就保持停用直到條件補齊。錯誤處理的深度，常常就是產品可信度的分界。

Success 之後的去向同樣依流程分岔：留下來讓使用者確認的，停留到下一個動作發生；任務完成即導頁的，轉場就是流程的一部分；需要連續操作的，回到 Default 等下一輪。三種都合理，混用才傷；把該導頁的做成自動重設，使用者會不確定剛剛到底成了沒。

細節上，文字與圖示分層淡換：「送出」淡出、「處理中」淡入，位置不動，視覺重心就不跳。原型裡的 After delay 只是等待的模擬，展示用可以，別讓它混進規格；上線後的等待時間由後端決定，設計端能承諾的是每個結果都有畫面。

上線時的取捨：簡單的顏色與位移交給 CSS 過渡；複雜的路徑動畫，像勾選圖示的筆畫，用 Lottie 換跨平台一致。兩者的分界與匯出細節，Lottie 動畫的完整指南講得清楚，交給前端之前值得讀一次，再決定哪些效果值得寫進程式碼。

什麼會讓再順的按鈕動畫，上線後變成傷害？

兩條紅線。一是動到會觸發版面計算的屬性，讓動畫本身成為卡頓來源；二是忽略減少動態、鍵盤聚焦與觸控情境，讓一部分人根本看不到這些設計。共同的判準是：動畫是增強層，不是資訊層；狀態資訊在完全不動的版本裡，也要讀得出來。

屬性選擇上，transform 與 opacity 通常較易維持流暢；width、height 類屬性的實際成本依頁面而定，以實機效能分析為準。設計階段能做的，是優先把動態對應到 transform 表達得了的縮放與位移。速度對體驗與商業成果的影響，web.dev 的 Why does speed matter 有專文整理；頁面體驗在搜尋系統裡的份量，Google 在2020 年 5 月對頁面體驗的說明講得明白：它只是諸多面向之一。這兩份來源支持「別讓動畫拖慢頁面」的謹慎，不支持任何排名承諾。

動畫與資訊的分離，可以用灰階檢驗：把畫面截圖轉成黑白看一眼，如果回饋只靠顏色深淺或紅綠差異，部分色覺使用者拿到的資訊就少了一半。把顏色配上圖示或文字，成功是勾、失敗是叉加訊息，狀態在任何感知組合下都讀得到，動畫才站得住「增強層」的位置。這個檢驗不需要工具，幾秒鐘就能做。

可及性有三件常被漏：

• 減少動態的替代版本：prefers-reduced-motion 是設計端就要標註的交付項，不是前端自由發揮的選項。
• 聚焦外框：七狀態地圖沒有列 Focused，因為它屬於操作方式的差異；鍵盤使用者靠 Tab 移動，外框讓目前位置被看見，在這裡補齊。
• 觸控沒有 hover：手指接觸的當下就是按下，重要回饋不能只綁在 hover 上。

減少動態通常有兩級做法：縮短與移除。幅度小的位移、顏色過渡，多數情況縮短就夠；會持續移動、旋轉或彈跳的元素，傾向直接移除或換成靜態等效。設計端交件時講清楚每個動畫屬於哪一級，前端實作時才有依據，不用逐案來回確認。

上線前的自我檢查，模擬極端條件比反覆看正常情境有用：把網路限速，看等待動畫在慢速下的表現；只用鍵盤走完送出流程，確認聚焦外框全程可見；把動畫關掉，確認狀態仍讀得出來。三個動作各花幾分鐘，涵蓋的卻是動畫最常翻車的三種情境。

行動版的整體思考不只這三件：斷點上的按鈕行為與版位變化，是響應式設計的課題，RWD 響應式網頁設計與Figma 裡的響應式做法兩篇接手，把單顆按鈕放回整頁的尺寸策略裡看。

把時間乘以三再看一次，用驗收表決定能不能交件

主觀的「順」可以被拆成可打勾的項目。做法有兩步：先把每段動畫暫時放慢到三倍，觀察屬性變化；再用驗收表逐項檢查，把時間、曲線、屬性寫成前端能直接照做的規格。前者練眼睛，後者定標準，缺一個都會退回憑感覺。

放慢是品檢法。180 毫秒暫設成 540 毫秒，逐影格看狀態接縫，原速播放時被蓋住的缺失會一一現形：進場是否突兀、換字是否疊影、收尾是否殘留。注意力放在接縫，不是動畫主體；按鈕的質感，斷在銜接的零點幾秒，不是高峰的特效。第二個練習是對比：跟公認成熟的產品擺在一起，數它們動的屬性，通常很少，但每個都準。同樣為感受把關的訓練，也存在色彩心理學的設計攻略，道理相通：先把可觀察的項目定義出來，感受才有得討論。

↔ 左右捲動檢視完整表格

檢查項	通過標準
Hover 進出對稱	進離場都有過場，時間與曲線大致對稱
Pressed 收尾乾淨	放開後回到原狀態，不殘留
Loading 不疊字	文字與旋轉圖示不同時佔位
Success 停留依流程	保留、導頁或重設由流程決定，不套固定秒數
聚焦外框可見	鍵盤 Tab 看得到位置
減動態可關	關閉動畫後狀態仍可辨識
無滑鼠也完成主回饋	觸控與鍵盤都走得通

驗收表跑三輪：自己做完跑一輪，抓初稿的硬傷；設計評審跑一輪，用同一張表對頻標準；交件前跑一輪，確認修改沒有引入新問題。三輪用同一張表，累積下來的勾選紀錄就是這顆按鈕的品質履歷，後手接手時有跡可循。

交付格式就寫在組件的 Description 或 Annotations：每段轉場的屬性、起訖值、時間、曲線與反向行為，語意上對應前端的 transition 寫法。工具不會自動補齊規格，這段文字就是設計的一部分；少寫一行，實作端就多一次猜測。

整套流程收斂成五步：診斷症狀、盤點狀態、替按鈕分級、依目的選路線、用驗收表交件。走完一輪，動畫順不順不再是運氣問題，而是可以被檢查、被重製的結果。按鈕是網頁裡最小的工作單位，卻是被觸發次數最多的元件；把判斷流程建立起來，比多學十個特效划算。整頁還缺什麼，對照網頁設計該具備的關鍵元素做一次體檢，把這顆按鈕放回它該在的位置，也把資源留給下一個更值得的問題。