Figma 載入動畫教學：製作流動效果的 Loading 原型互動
Figma 載入動畫是設計師在 Figma 原型裡模擬網頁等待畫面，用 Smart Animate 處理流動視覺、再用 Prototype 設定觸發條件，目的是在開發前就向客戶與工…
Figma 載入動畫是設計師在 Figma 原型裡模擬網頁等待畫面，用 Smart Animate 處理流動視覺、再用 Prototype 設定觸發條件，目的是在開發前就向客戶與工程師示範「使用者等多久、看到什麼」。Nielsen Norman Group 整理的反應時間模型指出，人類對 0.1 秒內的回應視為即時，超過 1 秒才會意識到自己在等 [來源：〈Response Times: The 3 Important Limits〉〈https://www.nngroup.com/articles/response-times-3-important-limits/〉〈2026〉]。載入動畫的核心價值因此在「補償這段感知效能落差」，視覺美感只是附帶效果。
重點先看：單段載入動畫建議控制在 0.3 到 0.8 秒、總等待感不超過 2 到 3 秒，超過這個區間反而放大使用者焦慮。搭配 Smart Animate 疊加 Prototype 觸發，才能把抽象的等待變成可預覽的交付物 [來源：〈Response Times: The 3 Important Limits〉〈https://www.nngroup.com/articles/response-times-3-important-limits/〉〈2026〉]。
Figma 載入動畫到底在做什麼
很多人把載入動畫想成「讓畫面好看一點」的點綴，這個方向從一開始就錯了。載入動畫本質上是一種補償機制，讓使用者在系統還沒準備好時知道「它還活著、正在運作」，降低等待時的不確定感與焦慮。沒有這層認知，做出來的動畫往往會變成炫技，反而拖慢感知速度。
Figma 在這件事上的優勢很具體：它把動畫變成「可互動的原型溝通工具」。純 CSS 或 SVG 動畫只能看到動起來的樣子，而 Figma 用 Smart Animate 處理流動視覺、Prototype 處理觸發與流程，兩者搭配才能還原真實的載入體驗。換句話說，你做的是一份可以點、可以走完流程的載入示範，動畫本身只是這份示範的視覺層。
這也是 Figma 原型跟最終上線版本最大的差別。原型是交付物，用來跟客戶與工程師對齊節奏與視覺；最終真正會出現在網站上的動畫，還是得由前端工程用 網站速度優化實戰與瓶頸診斷 友善的方式重新實作。如果你還沒摸熟 Figma 基本操作，可以先回頭看 Figma 完整教學入門指南 把工具面打底。
載入動畫的判斷題其實只有一條：這個畫面需不需要讓使用者「知道正在等」。常見情境拆開來對照，可以直接看出自己手上的專案屬於哪一種。
| 情境類型 | 是否需要載入動畫 | 原因 |
|---|---|---|
| 內容較多的入口網站、首頁首次進站 | 需要 | 資源量大，等待明確，動畫能安撫並預告進度 |
| 需資料載入的儀表板、報表 | 需要 | 資料來源延遲明顯，動畫提供狀態回饋 |
| SPA 換頁、非同步內容更新 | 需要 | 畫面切換時無完整重整，需要過渡提示 |
| 幾乎瞬開的靜態頁面 | 不需要 | 加動畫反而製造人為延遲，拖慢感知 |
| 純文字說明、無資料請求 | 不需要 | 等待時間極短，動畫只會干擾 |
從這張表可以看出一個反直覺的結論：什麼時候「不該」用載入動畫，比什麼時候該用更重要。這也是多數教學跳過的判斷，實務上往往要等到動畫拖慢瞬開頁面、被使用者抱怨多餘時，團隊才會回頭檢討。如果你對 SPA 換頁的過渡有興趣，可以延伸看 Figma 動態按鈕轉場動畫 怎麼處理點擊後的狀態切換。
把「需不需要」這個判斷再往下挖一層，會牽涉到三個變數：使用者預期、內容結構、實際載入時間。使用者預期決定他們願意等多久，點開一篇深度文章的人可以接受兩三秒的準備，點開一個搜尋結果的人則期待一秒內有反應。內容結構決定你能不能給出進度暗示，固定版面（文章列表、商品卡）可以預告框架，結構未知的全頁載入只能告知「正在跑」。實際載入時間決定動畫的上限，動畫長度永遠該比真實等待短一點，超過反而變成新的等待來源。這三個變數交叉，就會帶出後面幾節要談的長度、類型與交付判斷。
開工前的素材拆解
動畫做不出流動感，十次有八次是卡在素材沒拆好。開始做之前，先把靜態的載入畫面拆成可動的獨立圖層，通常包含四個部分：背景底框、品牌標誌、進度條或流動形狀、以及載入完成後的內容框架。每個元素都必須是獨立 frame 或 layer，否則 Smart Animate 沒辦法比對位移與變化。
拆圖層的原則只有一句話：凡是會動的，都要獨立。把 logo 跟背景合併成一張圖、把進度條跟底框壓在同一個 layer，是新手最常踩的坑，結果就是動畫變成一整張圖在淡入淡出，毫無流動感可言。命名也要乾淨，frame A 跟 frame B 裡對應的圖層名稱必須完全相同，Smart Animate 才認得出來。常見的可動形狀不外乎漸層長條（進度條填充）、波形線條（資料流動或呼吸）、旋轉圓圈（spinner 循環）、品牌標誌變形（logo 筆畫依序填色）這幾種，挑哪一種取決於你要傳達「在推進」還是「在旋轉」。
這些形狀不用自己從零畫，Figma 內建向量就夠用，也可以靠 Figma 免費圖示外掛推薦 裡的外掛快速產生線條與圖示。如果你需要放示意圖或氛圍圖當背景，Figma 免費圖庫素材外掛 能省下不少找圖時間。
尺寸與響應式也不能忽略。手機版跟桌面版的載入畫面比例差很多，建議直接建兩組 frame 對應，而不是做一個再硬縮放。配色方面，動畫主色用品牌色撐辨識度，背景留低彩度色階就好，載入時視覺太刺激反而讓人焦躁。響應式的細節可以對照 Figma 行動版響應式設計 與 響應式網頁版面設計 的做法。
拆圖層這步沒有捷徑，越偷懶合併，後面調動畫就越痛苦。把進度條跟底框合在一起的版本，到最後往往只能整組重畫。這階段多花十分鐘，後面省兩小時。
命名與元件化管理是進階設計師跟新手的分水嶺。建議把每個會動的圖層都收進 component，並用底線標示狀態，例如 logo/idle、logo/filling、logo/done。這樣的好處有兩個：第一，frame A 到 frame B 的同名圖層比對時不會因為手打命名打錯一個字而失敗；第二，同一組 logo 在不同 frame 重複使用時，改一個地方全部同步更新，載入畫面調整時才不會出現「A frame 改了 B frame 忘了改」的對不齊。這套命名習慣也可以直接沿用到後續跟工程師交付的規格標註階段。
Smart Animate 流動效果實作步驟
Smart Animate 的運作邏輯一句話講完：它自動計算兩個同名圖層畫面之間的位移、縮放與旋轉過渡。所以實作關鍵落在你怎麼準備起始與結束這兩個狀態，動畫本身的複雜度反而是次要。Figma 官方文件明確說明，只有圖層名稱完全一致時，Smart Animate 才會比對並產生過渡；選到 Dissolve 則只會做淡入淡出 [來源：〈Create prototype interactions with Smart Animate〉〈https://help.figma.com/hc/en-us/articles/360040711433〉〈2026〉]。
交案時會走的標準流程從空白畫面開始，一路到看到流動動畫跑起來，照著做就能避開九成的初學錯誤。
- 建立 frame A（起始狀態）：例如進度條在最左側、logo 還沒填色、內容框架為空。
- 建立 frame B（結束狀態）：進度條填滿、logo 完成、內容框架就位。frame A 與 B 內的對應圖層名稱必須完全相同。
- 連接 Prototype：在 Prototype 面板把 A 連到 B，trigger 設為 After Delay 或 On Click，動畫類型選 Smart Animate。
- 調整節奏：easing 建議選 Ease In Out 製造流動感，單段時間落在 0.3 到 0.8 秒之間。
- 加入循環：需要不間斷流動時，再加一個中間 frame 讓效果回到接近起始狀態，形成循環。
第四步的 easing 是節奏感的靈魂。Ease In Out 讓動畫開頭慢、中間快、結尾再慢，讀起來像呼吸；如果選 Linear 會有一種機械感，像跑馬燈。單段時間抓 0.3 到 0.8 秒對應人類對短暫動畫的感知門檻，是有實務依據的範圍。開頭慢、結尾慢這個特性特別適合進度條填充，因為它暗示「快完成了」的減速感，符合使用者期待的心理節奏。
進階一點的循環設計要注意一個陷阱：中間 frame 的狀態不能跟起始完全相同，否則會看到明顯的跳針。常見做法是讓進度條走到八分滿再回到兩分滿，製造「持續在推進」的錯覺。如果你想看流動效果怎麼跟其他互動效果搭，Figma 滑鼠追蹤視差互動效果 跟 Figma 毛玻璃霧面質感效果 都是用 Smart Animate 疊出來的，邏輯相通。視覺效果的部分，Figma 環形圓弧文字效果 也能當作 logo 變形的參考。
Smart Animate 只解決「動起來」這件事，它不會自己決定什麼時候該動。真正讓載入動畫像真實網頁一樣被觸發的，是下一節要講的 Prototype 互動。如果你之前做過 Figma 互動式滑塊輪播設計，對 Prototype 觸發應該不陌生，這裡的邏輯是同一套。
Smart Animate 疑難排解：動畫為什麼不流動
實作過程最常出現的狀況是「明明設了 Smart Animate，畫面卻只會淡入淡出」。把這個故障拆成幾個檢查點，逐項排除就能定位問題。
| 症狀 | 最可能原因 | 修正方式 |
|---|---|---|
| 只有淡入淡出，沒有位移 | 選到 Dissolve 而非 Smart Animate | 重新點開 Prototype 連線，動畫類型改選 Smart Animate |
| 進度條沒動，整張圖一起淡入 | 進度條沒拆成獨立圖層，或 A、B 命名不一致 | 把進度條獨立成同名圖層，確認兩 frame 拼寫完全相同 |
| 動畫瞬間結束，沒有過渡 | 時間設成 0 秒或極短 | 把單段時間調到 0.3 到 0.8 秒 |
| 循環時看到明顯跳針 | 結束 frame 與起始 frame 完全相同 | 讓結束 frame 回到接近但不同於起始的狀態，例如八分滿退回兩分滿 |
| 圖層數量過多導致預覽卡頓 | 單 frame 內嵌太多會動圖層，比對運算過重 | 把不會動的靜態元素合併成一張圖，只保留會動的圖層獨立 |
| 顏色過渡不平滑 | 兩 frame 的填色模式不同（實色對漸層） | 統一兩 frame 的填色類型，或改用透明度過渡 |
這張表的重點在於「症狀先分類、再對原因」。多數 Smart Animate 的故障都可以歸到命名、動畫類型選擇、時間設定這三個範圍，逐項檢查比重灌重畫快得多。一個小技巧是：在 Prototype 預覽前先框選 frame A 與 frame B，肉眼比對兩邊的圖層清單是否數量一致、名稱對得起來，這個十秒鐘的動作能擋掉大半的命名錯誤。
Prototype 互動設定：讓載入動畫可被觸發
Smart Animate 動起來之後，問題才剛開始：它什麼時候該跑？真實網頁的載入動畫有兩種觸發方式，一種是進站時自動播放、一種是某個動作後才啟動。這兩種都得靠 Prototype 的 interaction 來設定，光有 Smart Animate 沒有 Prototype，你做的是一支展示影片，不是可互動原型。
自動播放的做法是：在首頁 frame 設 After Delay，延遲設成 0 秒（或極短延遲）直接觸發載入動畫，模擬首次進站的體驗。點擊觸發則是：在按鈕上設 On Click，連到 Navigate 或 Change to 載入 frame，模擬 SPA 換頁時的載入狀態。最貼近真實 SPA 行為的是混合觸發：首次進站自動播放、後續換頁改用點擊觸發，讓使用者每次等待都有對應的觸發來源。
流程串接的小細節：載入完成的那個 frame，記得再用 After Delay 自動導向內容頁，別讓它停在那裡。否則客戶預覽時會以為動畫做完就卡住了，這是展示時最容易翻車的地方。展示技巧上，用 Figma Mobile App 或分享原型連結給客戶，在實機上預覽載入節奏最接近真實感受，勝過你在電腦上演給他看。
實機預覽這一步比多數人以為的重要。桌機預覽看到的節奏，跟手機上的實際感受往往有落差，原因在於行動裝置的運算與網路條件不同，動畫在手機上可能更慢、也可能因為效能限制而掉格。把原型連結傳到自己的手機上點一次，再決定動畫長度，能避免「桌機看起來很順、上線後手機端卻卡頓」的尷尬。
原型本身的品質會直接影響客戶對設計能力的判斷。如果你常做客戶 demo，可以順手把 UI 原型設計與 Wireframe 差異 釐清，並用設計思考的角度把載入動畫包進整個使用者旅程。想更貼近使用者真實想法，Persona 目標受眾輪廓建立 能幫你判斷這群人對等待的容忍度在哪。
互動設計不只是載入動畫的事。按鈕怎麼回饋、表單怎麼過渡、圖片怎麼輪播，都會影響整體節奏感，可以搭配 Elementor 彈跳視窗互動設計 一起看。如果你做的是品牌或作品集網站，作品集網站高轉換設計對首屏載入體驗的要求會更細。
動畫做多長剛剛好
長度判斷是整篇最關鍵的一環。載入動畫的單次循環建議控制在 1 秒以內、總等待感不超過 2 到 3 秒，超過這個區間動畫會從「安撫等待」翻轉成「放大焦慮」[來源：〈Response Times: The 3 Important Limits〉〈https://www.nngroup.com/articles/response-times-3-important-limits/〉〈2026〉]。使用者開始懷疑是不是卡住了，這時動畫越華麗，反效果越強。
感知效能的門檻是這套判斷的根據。研究普遍認為，人類對 0.1 秒內的回應視為即時、1 秒內感到流暢、超過 1 秒才開始意識到自己在等待 [來源：〈Response Times: The 3 Important Limits〉〈https://www.nngroup.com/articles/response-times-3-important-limits/〉〈2026〉]。這組數字是 UX 研究的公認共識，雖然不同研究細節略有出入，但量級大致如此。把它對應到載入動畫，就能推導出：動畫本身不該是等待的來源，而該比真實載入時間短一點。
| 回應時間（感知門檻） | 使用者感受 | 動畫設計建議 |
|---|---|---|
| 0.1 秒以內 | 視為即時 | 不需要載入動畫 |
| 0.1 到 1 秒 | 感到流暢 | 可加輕量過渡，單段 0.3 到 0.5 秒 |
| 1 到 3 秒 | 意識到等待 | 加進度暗示，循環單段小於 1 秒 |
| 超過 3 秒 | 開始焦慮 | 改用骨架畫面或百分比，別只放 spinner |
循環設計有個實用原則：當實際載入時間未知時，比起放一個無限旋轉的 spinner，加上進度暗示（例如百分比數字或進度條）能明顯降低焦慮。原因是進度暗示告訴使用者「正在往前推進」，純旋轉只告訴它「還沒好」，兩者對焦慮的安撫效果在實務測試中差距明顯。反效果的警訊很明確：動畫太華麗、循環太久，使用者會懷疑是不是卡住了。簡潔的流動永遠優於複雜特效。
這裡要承認一個限制：上述門檻是感知研究的共識值，每個專案適用的數字會因使用者族群與內容類型而浮動。實際上，動畫長度應該配合真實網頁的載入效能。如果你的網站 LCP 偏高，與其加動畫掩蓋慢速，更該優先把圖片壓縮、主機效能、快取這些根本問題處理好。這部分的優化方向可以看 網站速度優化核心技巧 與 網站載入慢的速度瓶頸診斷，載入動畫只能補償，不能取代真正的效能改善。
更根本的提速手段往往在載入動畫之前。圖片太大就找 圖片壓縮工具加速載入；WordPress 站用 WordPress 圖片優化提升速度；需要延後載入非必要資源就參考 Lazy Loading 延遲載入做法。主機與分發層面，CDN 對 LCP 的改善通常比任何動畫都直接。動畫是症狀治療，效能才是治本。
效能與商業成果的關係，有公開案例可以佐證「治本比症狀治療值得」。Google web.dev 整理的案例顯示，改善 LCP 與 INP 這類 Core Web Vitals 指標對營收有直接帶動：電商 Vodafone 把 LCP 改善 31%，帶來 8% 的銷售成長；redBus 改善 INP 後銷售成長 7% [來源：web.dev（Google）〈Why does speed matter?〉https://web.dev/articles/why-speed-matters 2026]。這組數字說明一件事：使用者感受到的快慢，最終會換算成留存與轉換。載入動畫是這條鏈上的補償件，真正的槓桿還是實際載入效能。把預算花在主機、快取、圖片壓縮，通常比花在更華麗的動畫特效回收更高。
把上述判斷放進一個具體的典型情境，會更容易看出該怎麼取捨。以一個首頁含大量商品圖、月流量約數萬到十幾萬的內容或電商站為例，這類站常見的狀況是桌機端實際載入約落在 1 到 2.5 秒、行動端在中等網路條件下往往拉長到約 2.5 到 4 秒，兩者落差明顯。設計師在 Figma 桌機預覽裡把單段動畫抓在 0.5 到 0.8 秒、看起來節奏順暢，但同一段設定移到手機實機預覽時，因為裝置運算較慢、動畫本身就會再多耗約 0.2 到 0.4 秒，加上真實載入時間更長，總等待感很容易就跨過 3 秒的焦慮門檻。這種「桌機順、手機卡」的落差，是這類網站做載入動畫時最常見的失誤點，光靠調整動畫秒數解決不了。
依這類站的典型表現幅度，實務上較穩妥的決策是分兩層處理。桌機端保留品牌化動畫或輕量進度條，單段約 0.5 到 0.8 秒即可；行動端則因為真實等待多落在 2.5 秒以上，與其放大 spinner，不如改用骨架畫面預告商品卡版面，讓使用者預期被滿足、感知速度明顯改善。要誠實指出一個限制：動畫長度再怎麼調，都補償不了首圖過大或主機回應偏慢這類根本問題，若 LCP 本身已經偏高，正確的順序是先把圖片壓縮、快取、主機這幾項處理到合理區間，再回頭決定動畫該補在哪、補多長，否則再精緻的動畫也只是把慢速包裝得好看。
節奏配方：把長度判斷變成可重用的設定
把上面的感知門檻轉成可以直接套用的設定值，會得到幾組常見的「節奏配方」。這些配方對應不同等待長度，設計師可以直接照搬，再依專案微調。
| 等待情境 | 單段時間 | Easing | 循環 | 搭配元素 |
|---|---|---|---|---|
| 按鈕點擊後的微過渡 | 0.2 到 0.3 秒 | Ease Out | 不循環 | 按鈕狀態切換 |
| SPA 換頁的輕量過渡 | 0.3 到 0.5 秒 | Ease In Out | 單次 | 淡入內容框架 |
| 首屏首次載入 | 0.5 到 0.8 秒 | Ease In Out | 循環，單段小於 1 秒 | 品牌 logo 變形加進度條 |
| 儀表板資料載入 | 0.6 到 1 秒 | Linear（資料流動感） | 循環 | 波形線條或骨架畫面 |
| 長時間背景作業（超過 3 秒） | 不建議純動畫 | 無 | 無 | 改用百分比或進度條明確標示 |
這組配方的用意是讓節奏判斷有個起點，不需要每次都從零推算。把單段時間、easing、循環、搭配元素四個欄位填好，一份載入動畫的規格就成型了一半，剩下的就是視覺細節。長時間背景作業之所以被標成「不建議純動畫」，是因為當等待超過 3 秒，使用者的問題已經從「它還活著嗎」變成「到底還要多久」，這時只有明確的進度數字能回答。
載入動畫的類型選擇：一份決策矩陣
確定了長度，接著要決定用哪一種載入動畫。常見的選項有四種：spinner 旋轉圈、進度條、骨架畫面、品牌化動畫。把它們擺進一個二維矩陣，判斷會更清楚。兩個維度分別是「等待長度」（短對長）與「內容結構是否已知」（已知對未知）。
| 短等待（1 秒以內） | 長等待（1 秒以上） | |
|---|---|---|
| 內容結構已知 | 輕量過渡或直接顯示，可省略動畫 | 骨架畫面（預告版面） |
| 內容結構未知 | spinner 或流動形狀 | 進度條加百分比 |
矩陣的四個象限對應不同組合。左上「短等待加結構已知」是最寬容的情境，動畫可以極輕量甚至省略，因為使用者幾乎不會感覺到等待。左下「短等待加結構未知」適合用 spinner 或流動形狀，快速告知「正在跑」。右上「長等待加結構已知」是骨架畫面的主場，因為結構固定，可以先畫出灰階佔位框讓使用者預期。右下「長等待加結構未知」最棘手，這時 spinner 會放大焦慮，唯一解法是盡量提供進度暗示，哪怕是粗略的百分比都比純旋轉好。
品牌化動畫（把 logo 拆成可動零件）是一個獨立的加分項，它不專屬於任何一個象限，而是疊加在既有的動畫類型上。它的價值在於把一段被迫的等待，轉成一次品牌曝光機會。判斷要不要用品牌化動畫的標準是頻率：如果使用者每次進站都會看到，那麼精緻的品牌動畫值得投資；如果是偶發的錯誤重試畫面，過度裝飾反而顯得輕浮。
四種類型在實作成本與感知效果上也有差異。spinner 實作成本最低、感知效果中等；進度條成本略高、但對長等待的安撫效果明顯更好；骨架畫面成本最高（需要先設計佔位版面）、感知速度最快；品牌化動畫成本看精緻度而定，能同時兼顧辨識度與等待安撫。資源有限的專案，可以從 spinner 起步，等載入效能穩定後再升級到骨架畫面或品牌化動畫。
載入動畫 vs 骨架畫面：什麼時候該用哪個
很多人把載入動畫跟骨架畫面（skeleton screen）當成二選一的選項，這又是另一個常見誤解。載入動畫適合全頁首次載入或等待時間較短的情境，骨架畫面則適合內容區塊漸進載入、需要預告版面結構的情境。兩者不是對手，進階設計會依等待長度與內容類型混合使用。
差別在於它們給使用者的「預期」完全不同。載入動畫（spinner 或流動形狀）只告訴使用者「正在載入」，資訊量低，但實作簡單、適合無法預測內容結構的時候。骨架畫面用灰階佔位框預告即將出現的版面，讓使用者預先看到框架，感知速度更快，代價是你得先知道內容會長什麼樣，這也是骨架畫面通常只用在結構固定頁面的原因。
| 比較項目 | 載入動畫（spinner/流動） | 骨架畫面（skeleton screen） |
|---|---|---|
| 適合等待長度 | 短等待，約 1 秒以內 | 較長等待，內容漸進載入 |
| 資訊量 | 低，只告知「載入中」 | 高，預告版面結構 |
| 適用內容 | 結構未知或全頁載入 | 結構固定，如文章列表、商品卡 |
| 實作成本 | 低 | 中，需先設計佔位版面 |
| 感知速度 | 中等 | 較快，因預期被滿足 |
進階搭配的做法是：首屏先用骨架畫面穩住版面結構，避免內容載入完成時畫面跳動造成 CLS；局部資料載入時再用小型載入動畫提示。這種混合策略在內容多的網站特別有用，因為它能同時處理「整體結構」與「局部狀態」兩層等待。CLS 跳動的問題可以對照 Core Web Vitals LCP INP 優化 一起看，骨架畫面對降低 CLS 有直接幫助。
在 Figma 裡，這兩者都可以做，而且可以放在同一個原型裡示範。骨架畫面用灰階佔位 frame，載入動畫用 Smart Animate，你可以在原型裡同時展示「骨架出現、內容漸進填入」的完整流程。這種原型對工程師特別有價值，因為它清楚交代了優先載入哪些區塊。響應式站的骨架畫面也得對應不同斷點，可以參考 響應式網頁設計 RWD 觀念。
版面結構的設計細節，Figma 響應式網格排版設定 是實作層。把骨架畫面跟排版梳理清楚，載入動畫才知道自己該補在哪個位置。
骨架畫面要發揮效果，關鍵在於佔位框的尺寸必須跟最終內容高度一致。如果骨架畫面先畫了一個 200 像素高的佔位區，實際內容載入後變成 400 像素，畫面就會劇烈跳動，CLS 反而惡化，這比不放骨架還糟。所以在 Figma 裡設計骨架畫面時，要先用真實內容的平均尺寸打底，再把骨架框對齊到這個尺寸。對於會動態增長的列表，骨架畫面至少要預留足夠的項目數，讓使用者預期的版面跟最終版面接近。
載入動畫的無障礙考量
載入動畫再好看，如果讓某些使用者不舒服，就失格了。這一節談的是常常被設計教學略過、卻會直接影響上線品質的無障礙議題。最核心的一條原則是：尊重使用者的動態偏好設定，也就是 prefers-reduced-motion。
prefers-reduced-motion 是作業系統層級的設定，使用者可以在系統裡宣告「我要減少動態效果」，通常是有前庭功能敏感、偏頭痛或癲癇傾向的人會開啟。網頁前端可以用媒體查詢偵測這個設定，收到訊號後把動畫降級成淡入淡出，或直接顯示靜態內容。載入動畫的設計端雖然不直接處理這個開關，但在規格標註時要明確寫出「當使用者開啟減少動態時，動畫應降級為 X」，讓工程師知道要做這條分支。
除了動態偏好，還有幾個無障礙檢查點值得放進設計流程。第一，動畫不能是唯一的狀態指示：載入動畫旁邊最好搭配文字（例如「載入中」或百分比），讓使用螢幕閱讀器的人也能知道現在的狀態。第二，避免高頻閃爍，每秒閃爍超過三次的內容可能誘發光敏性癲癇，載入動畫就算要循環，也要讓循環之間有明顯的靜止間隔。第三，對比度要足夠，載入畫面的文字與背景對比度建議符合 WCAG 的 AA 標準，讓視力較弱的使用者也能讀到進度資訊。
把這幾條整合進交付規格，會讓你的原型從「視覺正確」升級成「可上線且負責任」。無障礙不是額外負擔，它跟效能、響應式一樣是基礎品質門檻。一份會主動標註減動態分支與對比度的載入動畫規格，在工程師眼裡的專業度會明顯高一截。
從 Figma 原型到可上線的網頁動畫
這是新手最容易踩雷的一節。Figma 原型本身不能直接變成網頁動畫，它是一份示範用的互動文件，不是可上線的程式碼。正確的交付方式是提供原型連結作為節奏與視覺規格參考，再由前端工程師用 CSS、SVG 或 Lottie 重新實作。直接把 Figma 原型錄影成 GIF 放上網頁，是最常見也最糟的錯誤交付，問題會在正式上線後才逐一浮現。
GIF 之所以是地雷，原因有三：檔案大會拖慢載入、無法互動所以跟實際載入狀態脫鉤、解析度固定所以在高 DPI 螢幕會糊。GIF 唯一合理的用途是 demo 給客戶看個大概，正式網頁絕對不能用。幾種常見交付與實作路線整理在表格裡。
| 交付/實作路線 | 用途 | 適合場景 |
|---|---|---|
| Figma 原型分享連結 | 節奏與視覺規格參考 | 所有專案的基本交付 |
| 匯出 SVG + CSS animation | 向量動畫實作 | 流動形狀、進度條、簡單過渡 |
| GSAP 實作 | 精細時間軸控制 | 多段串接、複雜節奏 |
| After Effects 匯出 Lottie | 複雜向量動畫 | 角色動畫、品牌標誌變形 |
| 錄影成 GIF | 僅客戶 demo | 不建議上線使用 |
交付時設計師能做的最有價值的事，是標註規格。每段動畫標上秒數、easing 類型、觸發時機，讓工程師有明確依據，避免憑感覺猜節奏。規格標註越清楚，前後端來回修改的次數就越少。複雜動畫需要精細控制時，可以走 Lottie 路線，在 After Effects 製作後匯出，Figma 原型當作視覺草圖參考 [來源：〈Lottie Documentation〉〈https://airbnb.io/lottie/〉〈2026〉]。Lottie 跟 CSS、SVG 動畫的關係是互補，Lottie 負責複雜向量動畫，CSS 與 SVG 負責輕量過渡。
規格標註具體要寫哪些欄位，有一組現成的欄位可以照著填。這組欄位對應工程師實作時最常回頭問的問題，把它們一次寫清楚，等於把來回溝通的時間前置掉了。
- 觸發時機：頁面載入時自動觸發、或某個動作（點擊、提交）後觸發。
- 持續時間：單段動畫的秒數，例如 0.5 秒。
- Easing 類型：Ease In Out、Ease Out 或 Linear，並標註是否要自訂貝茲曲線。
- 循環行為：單次播放或無限循環，循環時是否有靜止間隔。
- 結束條件：動畫何時結束（載入完成事件），結束後導向哪個畫面。
- 減動態分支：使用者開啟 prefers-reduced-motion 時的替代呈現。
- 效能預算：動畫檔案大小或主執行緒佔用的上限，避免拖垮 LCP。
交付物的選擇也牽動整體視覺一致性。品牌色還沒定下來時，品牌色彩挑選實務指南 能幫你決定動畫主色，配色工具可用網頁配色工具神器推薦。字體與視覺層次對齊到排版設計字體與視覺層次技巧。
交付物之外，設計師與工程的協作可以靠 ChatGPT 輔助 UIUX 設計指令 加速規格整理。UIUX 設計自學資源地圖 則適合想系統性補強基礎的人。
載入動畫交付前檢查清單
把前面的判斷濃縮成一份檢查清單，交件前逐項打勾，能擋掉大部分的低級錯誤。這份清單分四個區塊：素材、動畫、互動、交付。
| 區塊 | 檢查項目 | 通過標準 |
|---|---|---|
| 素材 | 會動元素是否獨立成圖層 | 每個會動的元素都是獨立 frame 或 layer，沒有跟靜態元素合併 |
| 素材 | frame A 與 frame B 圖層命名是否一致 | 對應圖層名稱逐字相同 |
| 素材 | 是否有手機版與桌面版兩組 frame | 兩個斷點各有獨立的載入畫面，未用硬縮放 |
| 動畫 | 動畫類型是否選 Smart Animate | 不是 Dissolve，能產生位移與縮放過渡 |
| 動畫 | 單段時間是否落在感知門檻內 | 0.3 到 0.8 秒，循環單段小於 1 秒 |
| 動畫 | 循環是否避免跳針 | 結束 frame 與起始 frame 狀態不完全相同 |
| 互動 | 是否設定觸發方式 | After Delay 或 On Click 已設定，不是只會自動跑 |
| 互動 | 載入完成是否導向內容頁 | 完成 frame 後有 After Delay 或導向，不停在原地 |
| 互動 | 是否有減動態替代方案 | 規格標註 prefers-reduced-motion 的降級呈現 |
| 交付 | 是否提供原型連結與規格標註 | 連結加上秒數、easing、觸發時機書面規格 |
| 交付 | 是否避免 GIF 上線 | 正式網頁走 SVG、CSS 或 Lottie，GIF 僅用於客戶 demo |
| 交付 | 是否確認真實載入效能可負荷 | LCP 與圖片壓縮先處理，動畫不掩蓋慢速 |
清單的精神在於「把隱性判斷顯性化」。很多載入動畫的問題不是做不出來，而是在交付前沒人想到要問。逐項打勾的過程，等於把整個專案團隊對齊到同一份標準，新手設計師不會漏掉減動態分支，工程師不會漏掉觸發時機，客戶預覽時也不會遇到動畫做完卡住的尷場。
常見問題 FAQ
載入動畫什麼時候不該用？
頁面幾乎瞬開、等待時間在 0.1 秒以內時不需要載入動畫，加了反而製造人為延遲。純文字說明、無資料請求的頁面也屬於這類。判斷標準是：動畫是補償等待的工具，等待不存在就不需要補償。
網頁載入動畫對 SEO 有影響嗎？
動畫本身不直接影響排名，但若拖慢實際載入效能，會間接影響 LCP、CLS 等 Core Web Vitals 指標與使用者留存。輕量動畫配合效能優化才安全，別為了視覺犧牲載入速度。
Figma 動畫可以匯出成 Lottie 嗎？
Figma 本身不直接匯出 Lottie。Lottie 通常在 After Effects 製作後匯出，Figma 原型作為視覺草圖參考。需要精細時間軸控制的複雜向量動畫，Lottie 是常見選擇；簡單過渡則用 SVG 加 CSS 即可。
載入動畫怎麼做才不會引發無障礙問題？
三個重點：在規格裡標註 prefers-reduced-motion 的降級呈現、避免動畫成為唯一狀態指示（搭配文字或百分比）、控制對比度與閃爍頻率。這幾條寫進交付清單，工程師才知道要做減動態分支。
怎麼判斷該用哪一種載入動畫？
用「等待長度」與「內容結構是否已知」兩個維度判斷。短等待加結構已知可省略動畫或用輕量過渡；短等待加結構未知適合 spinner；長等待加結構已知適合骨架畫面；長等待加結構未知則用進度條加百分比。品牌化動畫可疊加在任何類型上，依曝光頻率決定投資程度。
GIF 為什麼不能拿來當正式上線的載入動畫？
GIF 檔案大會拖慢載入、無法跟實際載入狀態連動、解析度固定在高 DPI 螢幕會糊，三個缺陷都會在正式上線後才浮現。它唯一合理的用途是 demo 給客戶看個大概，正式網頁應走 SVG、CSS 或 Lottie。
把這幾件事串起來看：素材拆乾淨、Smart Animate 處理流動、Prototype 處理觸發、節奏壓在感知門檻內、骨架與動畫依情境搭配、交付走規格標註而非錄影。做到這些，交出去的會是一份客戶和工程師都能看懂載入體驗的原型，而不是一支只會跑的炫技動畫。等待這件事本身不會消失，動畫能做的是讓它變得可預期。想往上一層檢驗效果，可以搭配 網站跳出率與使用者體驗 看等待有沒有真的吃掉留存。
整體自學路徑，網頁設計自學路線圖 把載入動畫放進更完整的學習地圖。