Figma 滑塊與輪播設計完整教學

核心重點　Figma 裡的「slider」其實是兩種完全不同的元件：一種是讓使用者拖曳調整數值的 Range Slider（價格區間、音量、進度），另一種是讓內容自動或手動輪播的 Carousel Slider。這篇我會把兩者拆開來講：先把 Range Slider 的五個零件講清楚，用 Variants 做出一個真正能互動的元件；再回頭幫你判斷到底該不該做 Carousel；最後處理最常被忽略、也最致命的一塊：Figma 原型會動，不等於工程師做得出來。

為什麼你畫得流暢無比的 slider，一到工程師手上就被打槍重畫？PM 丟一句「首頁加一個 slider」，你打開 Figma 開開心心畫了一個漂亮的滑桿，Smart Animate 調得順滑無比，拿去給工程師，對方卻回你一句：「這個用手機拖不到、鍵盤也不能操作，而且值不會跳。」三天的工作就這樣打折，整個元件重畫。

我自己在做電商與後台介面的篩選器設計時，吃過幾次一樣的虧。後來我學會一件事：slider 不是一個視覺問題，是一個互動規格問題。你把規格想清楚，視覺自然就跟上來；反過來只顧漂亮，下游一定出事。這篇就是把我這幾年踩過的坑，整理成一份你可以直接拿來用的設計流程。

換個方式想：slider 是少數「設計師與工程師的認知落差」會直接暴露在使用者面前的元件。按鈕做不好，頂多難看；slider 做不好，使用者會在「選價格」這一步直接放棄結帳。正因為它直接卡在轉換漏斗的關鍵位置，它值得你用比一般元件更嚴格的規格來對待。下面我會從最根本的元件分類講起，一步步帶你把一個能交、能用、能維護的 slider 做出來。

如果你剛接觸 Figma，建議先翻過我寫的 Figma 中文完整教學，把基本操作與 Auto Layout 搞懂再回來，這篇的 Variants 與 Interactive Components 對你才有意義。

「Slider」在 Figma 裡是兩種不同的元件，先分清楚

搜尋「Figma slider design」的人，腦袋裡裝的其實是兩件事，而九成的教學沒有先把這兩件事分開，導致你看完還是不知道自己在做哪一種。我把差異寫成一張表：

面向	Range Slider（數值滑桿）	Carousel Slider（內容輪播）
使用者在做什麼	拖曳一個把手，調整一個「值」	瀏覽一整排內容，往前或往後翻
典型情境	價格區間篩選、音量、進度條、問卷評分	首頁 Banner、商品圖輪播、推薦卡片
核心互動	拖、點擊 track 跳到指定位置、鍵盤方向鍵微調	點左右箭頭、滑動、自動播放、點圓點跳頁
資料本質	一個或多個「數值」	一組「內容項目」
最重要的無障礙要求	鍵盤可調整、值要唸得出來	可暫停、可跳頁、不被自動播放綁架
常見的死法	把手太小點不到、值不顯示	自動播放太快、行動版滑不動、SEO 抓不到內容

分清楚之後，你會發現這兩種元件在 Figma 裡的建構邏輯完全不一樣。Range Slider 重視的是狀態（state）與數值對應，你要用 Variants 把每個狀態做出來；Carousel Slider 重視的是版面約束與內容溢出，你要用 Clip Content 與 Frame 來控制看得到什麼。這也解釋了為什麼很多新手把兩者混在一起做會卡住：你拿 Range Slider 那套「狀態變數」的思維去做 Carousel，會發現根本對不上，因為 Carousel 控制的是「目前顯示第幾張」，Range Slider 控制的才是「目前值是多少」。

這篇文章後續會以 Range Slider 為主軸來拆解，因為它的設計規格密度更高、也更容易踩到 handoff 的雷。Carousel 我會用一個獨立的段落談，焦點會放在「到底該不該做」這個更源頭的判斷，拼裝技術反而是次要的事。原因很簡單：大部分的 Carousel 失敗，真正出問題的往往是它一開始就不該被做，跟拼裝技術好不好幾乎無關。

把 Range Slider 拆成五個零件來想，比一次畫完整還快

很多設計師一打開 Figma 就想直接畫一條漂亮的滑桿，結果每改一個狀態就要重畫一次。比較聰明的做法是先把元件拆解，把每個零件命名好，再用 Component Properties 組合。我把 Range Slider 拆成五個零件：

1. Track（軌道）：把手移動的範圍，是整個 slider 的「邊界」。它的長度決定了數值映射的空間。
2. Fill（已選範圍）：從起點到把手之間那段填色，視覺上告訴使用者「你已經選了多少」。雙把手 slider 會有兩個把手之間的 fill。
3. Thumb（把手）：使用者直接拖曳的那個圓點，是整個元件唯一「可操作」的點。
4. Value Label（數值標籤）：即時顯示目前選的值。沒有它，使用者就是在盲拖。
5. Ticks / Steps（刻度與步進）：可選，讓數值吸附到特定間距，避免出現「$1,237」這種沒有意義的值。

這五個零件對應到前端實作時，每一個都有明確的責任。我把對照列在下面，這是 handoff 時最該講清楚的東西：

Figma 零件	前端對應	設計時要決定什麼
Track	可點擊的容器，點擊會跳到該位置	高度、點擊範圍要比視覺大（hit area）
Fill	依目前值算出的填色寬度	顏色、是否含漸層、是否在 disabled 時變灰
Thumb	可拖曳、可聚焦的元素	尺寸（行動版至少 44px 觸控區）、hover 與 focus 樣式
Value Label	動態文字，需即時更新	顯示格式（整數、小數位、貨幣符號）、位置
Steps	值吸附邏輯（snapping）	最小步進單位、是否顯示刻度

直白地說，這張表就是你跟工程師開會時的議程。你把每一格都填出來，工程師就不會再回來問你「disabled 的時候 fill 要不要保留顏色」這種問題。

這裡的觸控尺寸與間距觀念，跟我之前整理的 CSS Box Model 完全圖解是同一套邏輯：視覺邊界與可點擊邊界本來就該分開設計。差別在於 slider 的觸控區比一般按鈕更敏感，因為它牽涉到「拖」這個連續動作。

用 Variants 打造一個真正能互動的 Range Slider

拆完零件，接下來就是把 Range Slider 做成元件。我用一個最常見的單把手價格滑桿當範例，帶你走一遍。這個流程假設你已經會建立 Component 與 Auto Layout，如果還不熟，可以先看 Figma 網格系統教學把對齊與間距的紀律建立起來。

第一步：列出這個 slider 需要哪些狀態

互動元件的品質，取決於你考慮了多少狀態。一個及格的 Range Slider 至少要有這四個：

• Default：未操作、未聚焦的基本樣式。
• Hover：滑鼠移到把手上，把手通常會放大一點或變色，預告「這裡可以點」。
• Dragging / Active：正在拖曳時，把手最大、fill 顏色最飽和，value label 持續顯示。
• Disabled：不可操作，整體降透明度或轉灰，游標變 not-allowed。

別漏掉 Focus 這個狀態。鍵盤使用者按 Tab 聚焦到 slider 時，必須看得到一個明確的 focus ring，否則他根本不知道現在在哪裡。很多設計稿只畫 hover 不畫 focus，這是無障礙最基本的缺失，也幾乎一定是工程師打槍你的第一個理由。Focus ring 的設計要特別注意：它不能只是把手放大，因為放大很容易跟 hover 樣式混淆；比較好的做法是給 thumb 加一圈外框，或加一層半透明的光暈，讓鍵盤使用者一眼就能跟滑鼠 hover 區分開來。這個區分的用意在於：focus 與 hover 代表的是不同的使用者狀態，兩者混在一起，會讓鍵盤使用者失去「我現在在哪」的回饋。

每個狀態之間的視覺差異，我建議遵守一個原則：差異要大到一眼看得出來，但不要大到像換了一個元件。Default 到 Hover，把手放大個 10 到 15%、顏色加深一階就夠；Hover 到 Dragging，把手再放大一些、fill 變飽和、value label 浮現。整個狀態鏈的視覺是漸進的，讓使用者感覺這是同一個東西在不同強度下的樣貌，像是同一顆按鈕的連續變化。這個漸進性也跟動畫時間有關：狀態之間用 200 到 300ms 的 Smart Animate 過渡，漸進感才會出來。

第二步：用 Component Properties 把數值做成變數

把 Default 狀態畫好後，封裝成 Component。接著關鍵來了：不要只做「視覺上的四個 variant」，還要加入一個 Number 類型的 Component Property，命名為 value。這樣你可以在實例面板直接輸入一個數字，fill 的寬度與 value label 就跟著變。

做法是：把 fill 的寬度、thumb 的 X 位置、value label 的文字，都綁定到這個 value 屬性（透過 variables 或公式算出對應位置）。設好之後，你在 prototype 裡就能模擬「使用者把值從 20 拖到 80」這件事，勝過只放一張靜態圖。

第三步：用 Interactive Components 加上狀態切換

把四個狀態做成同一個 Component Set 裡的四個 variant（命名為 State=Default、State=Hover、State=Dragging、State=Disabled）。然後進 Prototype 面板，用 Interactive Components 設定互動：

• Default → while Hover → 切到 Hover。
• Hover → on Drag → 切到 Dragging。
• Dragging → on Drag end → 切回 Hover。

動畫選 Smart Animate，讓把手的放大與顏色變化有過渡。這裡有一個跟前端效能直接相關的判斷：過渡時間不要設太長。一個小區域的狀態變化，200 到 300 毫秒就夠了，超過這個數字，使用者會覺得元件「黏黏的、反應慢」。這不是憑感覺的數字，而是 Material Design 3 對小面積動效的建議區間（2024）。

第四步：用真實數值範圍測一遍極端值

元件做好之後，拿你的實際資料測三個極端值：最小值、中間值、最大值。最常出問題的是 value label 的寬度。當值是個位數時 label 很窄，當值跑到六位數時 label 會把旁邊的元素擠掉。解法是給 label 一個固定寬度的容器，或讓它置中浮在 thumb 上方，不要佔用排版的水平空間。

如果你做的是雙把手的 Range Slider（例如「價格 $500 到 $3,000」），還要多測一個情境：兩個把手拖到最靠近、甚至重疊時，使用者還能不能各自抓住。我自己的習慣是給兩個把手之間設一個最小間距，低於這個間距就鎖住，避免它們黏在一起分不開。雙把手 slider 在 Figma 裡要多做兩個 variant：左把手 dragging 與右把手 dragging，因為兩個把手的 dragging 樣式雖然看起來一樣，但在原型互動裡是兩個獨立的觸發點，分開做才不會在設定 Interactive Components 時打架。

Slider 不要孤立設計：把它放回整個篩選表單裡想

很多 slider 教學只講元件本身，但真實專案裡，slider 幾乎從來不是單獨存在。它通常是一個篩選表單、一組設定面板的一部分。如果你只把 slider 當成一個獨立的小東西做完，沒有想它跟旁邊元件的關係，上線後一定出問題。我把幾個「整體脈絡」的判斷列出來，這些是比元件本身更決定成敗的事：

即時更新還是按下才套用

價格 slider 一拖，下面的商品清單就要跟著變嗎？還是要等使用者按下「套用」才更新？這兩種做法各有支援者，但你要明確選一個，並在稿上標出來。即時更新的好處是回饋直接，壞處是如果每次拖動都重新查詢，會把伺服器與使用者的耐心一起耗掉；套用式的好處是可以把多個條件一次送出，壞處是回饋慢。我的偏好是：若結果計算很快（純前端篩選），就即時更新；若牽涉後端查詢，就套用式，並在 slider 旁邊給一個明顯的「查看結果」按鈕。

重設與清空

使用者調了半天 slider，想回到預設值，他要怎麼做？很多設計忘了給「重設」這個出口，使用者只能手動把兩個把手拖回原位，體驗很差。一個小小的「清除」或「重設」連結，往往比 slider 本身的視覺更影響滿意度。這個元件層級的思考，跟我做 Figma 圖示外掛整理時的體悟一樣：真正提升效率的，常常是那些不起眼的小元件。想開始替自己累積這類基礎工具的人，可以從新手必備的 Figma 外掛清單裡挑幾個來試。

無結果狀態

slider 拖到一個太窄的範圍，篩選出零個結果時，畫面要長怎樣？這是篩選器設計最常被遺漏的狀態。一個好的無結果狀態會告訴使用者「目前條件下沒有結果」，並建議放寬範圍；一個差的無結果狀態就只是一片空白，讓使用者以為網站壞了。你在 Figma 裡要為這個狀態單獨畫一個 frame，不要假設它「之後再說」。

載入狀態

套用篩選、等待結果的那幾秒，slider 區塊要做什麼？凍結不能再操作、還是顯示一個 loading 樣態？我的習慣是讓互動元件在查詢中暫時 disabled，並在結果區顯示載入動畫，避免使用者在結果還沒回來時又改條件，造成查詢打架。這個細節跟 Figma 視差效果教學裡提到的「互動回饋要即時且明確」是同一個道理：使用者在等待時，最怕的是「不知道發生了什麼」。

輪播 Slider 到底該不該做？用三個問題先自我審查

Range Slider 幾乎永遠是該做的，因為它解決的是「輸入數值」這個明確需求。Carousel Slider 就不一定了。老實說，我在專案裡看過太多「為了讓首頁看起來有動態」而硬塞的輪播，它們共同的命運是：第一張之後沒人看、轉換率比靜態版面還低、還被使用者抱怨自動播放很煩。

所以動手做 Carousel 之前，我建議你先問自己三個問題：

問題	如果答案是「否」
這些輪播內容，使用者「真的」需要同時存在於這個畫面嗎？	改成靜態排版，例如 Bento Grid 或網格狀陳列
使用者會主動想翻到第二張以後嗎？	實務上多數輪播第一張之後的點擊率會明顯下滑，挑一張最強的單圖，效果通常更好
自動播放是為了使用者，還是為了「讓老闆覺得網站很熱鬧」？	後者的話，拜託拿掉自動播放，或至少給一個明顯的暫停鈕

這三個問題的目的，是讓你帶著理由去做輪播，全盤否定它也沒必要。電商商品頁的多角度商品圖輪播，是合理的需求，因為使用者要「看清楚這件商品」。首頁塞五個促銷 banner 輪播，通常是沒想清楚 IA（資訊架構）的逃避方案。

這裡我要特別提醒一個常見的誤判：很多人把 Carousel 當成「解決首頁空間不足」的工具，以為只要把十個促銷塞進輪播，就等於十個都展示了。但從使用者行為的角度看，輪播的第九、第十張，幾乎沒有人看到。你以為在曝光，其實只是在心裡曝光。如果這些內容真的重要，就應該重新規劃版面讓它們同時可見；如果沒那麼重要，那連做輪播的工都不必花。這個判斷跟你做 Wireframe 線框圖時的取捨是同一套：先決定資訊層級，再決定互動形式；順序顛倒了，互動形式只會掩蓋資訊層級的混亂。

如果你評估過後確定要做 Carousel，那麼設計上有幾個我會堅持的底線。第一，一定要有明確的導航：左右箭頭加上頁面指示器（那些小圓點或進度條），讓使用者知道總共有幾張、現在在第幾張。第二，自動播放必須可以暫停，而且滑鼠 hover 或觸控時要暫停，這是無障礙與體驗的基本要求。第三，每一張的內容都要能被搜尋引擎讀到，不能把文字做成圖片然後指望 alt 解決一切。

Carousel 的進階互動（例如視差、3D 翻轉）在 Figma 原型裡可以用 Smart Animate 模擬，但真正上線時這類動效通常得靠前端框架或動畫庫。如果你的專案需要這類輕量動畫，Lottie 動畫完全指南是比 GIF 或連續圖片好太多的選擇，檔案小、可縮放，工程師整合也容易。

還有一個我會特別盯的細節：輪播的切換方向與節奏。左右切換是大家熟悉的隱喻，但切換動畫的時間與方向要一致，不要有的張數往左滑、有的往右滑，那會讓使用者失去方向感。切換動畫一樣落在 200 到 300ms 區間最自然（見 Material Design 3 的 Duration 建議，2024），太快像抽獎、太慢像幻燈片教學，都會傷害體驗。

商品輪播還有一個常被低估的點：第一張圖的選擇。多數輪播第一張的曝光率遠高於後面幾張，所以第一張必須放最強、最有吸引力的內容，不要按上傳順序隨便排。這個判斷跟你做首頁視覺、挑主圖時的邏輯是同一套：最顯眼的位置，要放最值得被看見的東西。選圖的品味是另一門學問，建議從合法、高質感的來源下手，避免用低解析或風格混亂的圖把整個輪播的質感拉低。

決定要做 Carousel 之後：用三層結構把它拼起來

前面幫你判斷過「該不該做 Carousel」，這一節假設你已經決定要做，接下來講怎麼把它拼出一個能交、能動的版本。很多人一開 Figma 就直接拉一個 Frame、丟幾張圖進去，然後開始煩惱動畫——這個順序錯了。你應該先把 Carousel 在腦海裡拆成三層，每一層職責分清楚，動手時才不會把動畫、狀態、版面全糊在同一個 Frame 裡，最後改一個地方就全炸。我固定的拆法是三層：容器層、投影片層、控制項層。

容器層是整個輪播的「視窗」，它只負責一件事：框出可視範圍，並把超出範圍的內容裁掉。在 Figma 裡你用一個 Frame 加上 Clip content 來實作，寬高就等於一張投影片的大小。投影片層是一條橫向軌道，把所有投影片並排放進去，這條軌道整體左右位移，投影片就跟著滑動。控制項層則是箭頭、圓點指示器、進度條這些東西，它們浮在容器上方，獨立處理點擊與狀態。換句話說，輪播之所以「會滑」，是因為你只動了投影片層的水平位置，另外兩層都不動。把這個機制記住，後面所有細節都會合理。

層級	負責什麼	最常見的錯誤
容器層	框出視窗、裁切溢出內容	忘記開 Clip content，投影片溢出跑到隔壁區塊
投影片層	承載所有投影片、整體水平位移	每張投影片各自淡入淡出，導致沒有「滑動」感
控制項層	箭頭、圓點、拖曳提示的互動與狀態	圓點跟目前位置不同步，點擊無回饋

把這三層分乾淨還有一個附帶好處：之後要把它包成可重複使用的元件時，結構會很清楚，不會出現「改了箭頭顏色結果投影片也跟著跑位」這種災難。容器與投影片層都用 Auto Layout 包，間距自動一致，改一張其他全部跟上。

用 Smart Animate 接手過場，但九成的人用錯它

三層結構搭好之後，過場交給 Smart Animate。它的邏輯很直觀：當你從一個 Frame 跳到另一個 Frame 時，Figma 會去找兩個 Frame 裡「同名」的圖層，然後把屬性差異補上動畫（機制說明見 Figma Help Center 的〈Add animations with Smart Animate〉，2026）。聽起來簡單，但九成的人錯在同一個地方：圖層命名不一致。

最常見的悲劇是這樣：你在 Frame A 把投影片層叫做 track，到了 Frame B 因為複製貼上的關係變成 track copy 或 Frame 23。Smart Animate 找不到同名圖層，於是默默退回它最保險的 fallback，也就是 dissolve（交叉溶解），你的輪播就變成圖片淡入淡出，完全沒有橫向滑動的感覺。很多人以為是 Figma 動畫不夠強，其實是命名紀律不夠。紀律很無聊，但它是免費的，做完它你什麼都不用花就贏過一半的人。

這個退回行為很陰險，因為 dissolve 看起來「也有動」，你很容易誤以為自己做對了。除錯的方法很樸素：在 Present 模式跑過場時，盯著看投影片是「整條往左滑」還是「兩張圖交叉淡入淡出」。前者代表 Smart Animate 命中了，後者代表命名出問題、它退回 dissolve 了。這個 30 秒的檢查，可以幫你省下反覆調動態參數卻徒勞無功的尷尬。

正確的做法是：準備 N 個 Frame，每個 Frame 代表「投影片停在第幾張」這個狀態，投影片層在每個 Frame 裡水平位移一張投影片的寬度，圖層名稱在所有 Frame 裡完全一致。Smart Animate 還有一個「Match layer names only」選項，勾了之後它只會對齊同名圖層、不同名的一律用溶解帶過。在輪播這個場景我建議勾起來，因為你只希望 track 這層被補間，投影片內部的圖片文字應該跟著 track 一起平移、不要各自有獨立的過場。一句話原則：Smart Animate 補的是「同圖層、不同屬性」，你的工作是確保想動的東西名字一致、不想動的東西也名字一致。

Carousel 的動態曲線：emphasized decelerate 與「尾勁」

輪播切換可以先用約 250–350ms 作為測試起點，再依移動距離、內容密度、裝置效能與品牌節奏調整；重點是讓使用者看得懂狀態變化，又不必等待過久。較長距離或資訊較多的轉場，通常需要更長時間才能維持可讀性。我固定用 300 到 350 毫秒搭配 emphasized decelerate（開始快、結束慢），這跟物理世界的慣性一致——投影片被推出去時有速度，到定位時自然減速停下，視覺上讀起來舒服。Linear（等速）是最廉價的選擇，投影片像輸送帶一樣勻速到底、到定位硬停，那個硬停就是廉價感的來源。

這裡分享一個讓輪播更有質感的小技巧，姑且叫它「尾勁」。在投影片快要到定位時，讓它稍微越過目標位置一點點（大約 2 到 3% 的寬度），再回彈到正確位置。這個微小的過衝（overshoot）就是讓人下意識覺得「這個互動很細緻」的關鍵。Figma 沒辦法直接設 overshoot，但可以在 variant 之間多插一個「過衝」的中間 Frame，搭配 Smart Animate 補出這段回彈。這個手法要節制，過頭會變彈跳球，但拿捏得宜就是那種別人說不出哪裡好、就是覺得你東西比較精緻的差距。

把動態規格整理成一張表交給工程師，是最不容易走樣的做法。以下是我輪播專案慣用的規格，你可以依專案微調，但結構照抄就好。

項目	手機版	桌面版	備註
過場時長	300 毫秒	300 到 350 毫秒	中範圍位移，別低於 250
緩動曲線	emphasized decelerate	emphasized decelerate	cubic-bezier(0.2, 0, 0, 1) 近似值
過衝幅度	2% 寬度	2 到 3% 寬度	用中間 Frame 補
箭頭 hover	無（觸控為主）	150 毫秒、透明度變化	hover 不該改變尺寸
圓點切換	瞬切	瞬切	避免圓點自己也有動畫搶戲

四種導覽互動的取捨：以拖曳為主、箭頭為輔

輪播怎麼被操作，直接決定它在手機上是順手還是反人類。常見的導覽互動有四種：箭頭、圓點指示器、拖曳滑動、自動播放。很多人以為「四種都做上去最保險」，結果四種互相打架，使用者反而不知道該怎麼操作。老實說，每一種都有自己的地雷，你要做的是有意識地挑選組合，而不是四種全包。

互動方式	優點	地雷	適合場景
箭頭按鈕	明確、好學	放在左右兩側邊緣，手機上拇指搆不到	桌面版、投影片數量少
圓點指示器	顯示進度與總數	點太小難點擊，常被當裝飾	搭配箭頭或拖曳使用
拖曳滑動	最貼近直覺、手機最自然	需要在原型設 Click vs Drag，否則拖不動	行動裝置優先
自動播放	不用操作也會動	搶走使用者控制權，無障礙爭議大	少用，或必須能暫停

我的建議是這樣：以拖曳為主、箭頭為輔、圓點標示位置，自動播放除非有強烈商業理由否則不做。為什麼這樣排？因為桌面版使用者習慣點箭頭，但手機使用者幾乎 100% 用手指滑，把箭頭放在螢幕邊緣他們根本懶得點；圓點在桌面上勉強可點，到手機上太小，所以它的角色是「告知」而不是「操作」；自動播放是最危險的，它會在使用者正在讀某張投影片時強制切走，這在無障礙規範裡是被明確點名的問題。

在 Figma 裡實作拖曳有一個關鍵：prototype 連線的觸發類型要選 Drag 而不是 Click。很多人設成 Click 結果怎麼滑都沒反應，以為 Figma 壞掉。Drag 互動會讓 Smart Animate 跟著手指放開觸發，這才是手機上「滑一下就過去」的真實感受。這個細節在桌面預覽時看不出差別，一定要用 Figma 行動版 app 在實機上測過才算數。

響應式斷點：以投影片編號為準，不要以畫面格為準

輪播不能只在桌面上測，這件事我在前面行動版段落講過。具體到斷點策略，我固定用三段：手機一次顯示一張投影片（滿版），平板一次顯示一到兩張，桌面一次顯示一到三張，並讓前後露出一點邊緣（edge-peek），暗示「還有更多可滑」。為什麼桌面要露出邊緣？因為一次只顯示一張的輪播在寬螢幕上看起來像一個被孤立的方塊，使用者不知道旁邊還有內容可滑；露半張出來等於視覺上的「邀請手勢」，引導他往兩側滑。這個手法在電商商品推薦輪播特別有效，能明顯提升往旁邊探索的點擊。

斷點之間的過渡也要想清楚。使用者從手機轉到桌面的瞬間，投影片數量從一張變三張，目前的位置要怎麼對應？最保險的做法是：記住使用者目前看的是「第 N 張投影片」這個邏輯位置，不能把它記成「第 N 個畫面格」。這樣斷點切換時，他看到的主體內容不會突然跳掉。這個細節在 Figma 原型裡很難完整模擬，但你在標註時寫清楚「以投影片編號為準、不以畫面格為準」，工程師就知道該怎麼處理。

一張投影片只傳遞一個訊息，三到五張是甜蜜點

前面全部在講「怎麼讓輪播動得對」，這一節講一個更根本、卻很少被放進輪播教學的事：投影片裡到底該放什麼。我看過太多輪播敗在內容，動態反而是次要問題——一張投影片塞了標題、副標、三個賣點、兩顆按鈕，使用者三秒鐘根本讀不完，於是整個輪播變成沒有人會停下來看的裝飾。動態做得再漂亮，也救不了沒有層次的內容。

我自己守一條很硬的規矩：一張投影片只傳遞一個訊息。結構上最多就是「一個主標、一個視覺、一個行動呼籲」，超過這個量就要拆成兩張。判斷的方式很樸素——你問自己：如果使用者只看到這張投影片三秒鐘，他必須帶走哪一句話？那句話就是這張投影片的主角，其他都是配角，配角的份量不能壓過主角。這個練習會逼你做取捨，而取捨正是設計的價值所在。

投影片數量也是。三到五張是甜蜜點，超過七張使用者的耐心就會崩潰，圓點也會多到失去導覽意義。如果你發現自己想塞十張投影片，先回頭問是不是其實需要的是一個一次看盡的網格版面，不必逼使用者一張一張滑。選對呈現形式，比把輪播做到極致更重要。

把輪播的動態與無障礙規格寫進 Dev Mode

你精心調的 300ms、emphasized decelerate、那 2% 的過衝，如果沒有明確寫下來，工程師八成會用套件預設值，你的精緻感就歸零。根據 Figma 官方的 Dev Mode 指南（2026），Dev Mode 能交付尺寸、間距、顏色，甚至片段程式碼，但動態規格特別容易在交接時消失。所以交付時，我會在 Dev Mode 的註解裡把四件事寫死：過場時長、緩動曲線名稱（給出 cubic-bezier 數值最保險）、每個斷點下的行為差異、以及 reduced-motion 的備援方案。

第四項特別重要。無障礙規範要求尊重使用者的「降低動態」系統設定，當使用者開啟 prefers-reduced-motion 時，你的輪播應該停止自動播放、並把過場改成瞬切。這個設定不寫清楚，工程師通常不會主動做，結果就是對動態敏感的使用者被你的輪播折磨。鍵盤可及性也是輪播最容易漏的一環：左右箭頭必須能用 Tab 取得焦點、焦點樣式要清楚可見（不能只靠變色，要加上明顯的 outline）、按 Enter 或方向鍵也能切換投影片。這些在 Figma 原型裡同樣無法完整模擬，但只要你在標註寫明白，工程師就知道這些都是基本規格，不能當成可有可無的裝飾。把無障礙當成交付清單裡固定的一條，別等到上線後被客訴才回頭補洞。

什麼時候你不該用 Slider？跟其他輸入元件的取捨

到這裡我都在教你「怎麼把 slider 做好」，但更成熟的判斷其實是「這個場景到底該不該用 slider」。Range Slider 看起來很酷，但它並不是所有「讓使用者輸入數值」情境的最佳解。有時候一個普通的數字輸入框、一個步進器、或一組選項按鈕，反而比 slider 好用得多。

我列一張取捨表，這是我在做表單與篩選器設計時，每次都會拿出來對照的：

情境	首選元件	為什麼不用 slider
精確金額（例如預算 $25,000）	數字輸入框	使用者要的是精確值，拖曳無法快速到位
選項很少（3 到 5 個區間）	選項按鈕或分段控制	選項少時 slider 的彈性反而是負擔
使用者需要直接看到所有選項	下拉選單或卡片	slider 隱藏了選項總數
連續且可粗略調整（亮度、音量、價格區間）	Range Slider	這才是 slider 真正發揮價值的場景
小幅度整數微調（商品數量 1 到 10）	步進器（stepper）	slider 在窄範圍內比按鈕難操作

這張表背後的原則很簡單：slider 適合的是「連續、粗略、視覺化」的調整，不適合「離散、精確、需要逐項檢視」的選擇。當你發現自己硬要把一個其實只有三個檔位的設定做成 slider，那就是設計的訊號了，退一步，換個元件。

我也看過反過來的錯誤：明明是連續範圍（例如地圖的縮放、影片進度、問卷的滿意度評分），卻硬做成一堆按鈕讓使用者點「25%」「50%」「75%」。這種時候 slider 不只是比較好看，而且真的比較符合那個調整動作的本質。問卷與評分這類情境，slider 還有一個額外好處：它強迫使用者做一個「相對位置」的判斷，避免被既定的選項綁架，這對滿意度調查的資料品質其實是有幫助的。

五個我反覆看到的 Slider 設計反模式

除了取捨，有些錯誤是反覆出現的。下面這五種 slider 反模式，是我這些年看過的，每一種都附上修正方向，你在 review 自己或同事的稿時可以直接對照：

• 隱形把手：thumb 顏色跟 track 太接近，使用者根本找不到要拖哪裡。修正：thumb 與 track 之間至少要有足夠的明度或飽和度對比，這跟 色彩學指南裡談的對比原則是一致的。
• 盲拖：沒有 value label，使用者拖了半天不知道選了多少。修正：永遠顯示目前值，或至少在拖曳時顯示。
• 點不到的細軌道：track 為了美觀做得很細（例如 2px），行動版根本點不準。修正：視覺軌道可以細，但可點擊區域要夠大，用透明 padding 撐開。
• 無止盡的自動播放：Carousel 不看內容資訊量、兩三秒就換一張，使用者讀不完就被切走。修正：依單張內容需要幾秒讀完來定間隔、hover 時暫停、或乾脆拿掉自動播放。
• 鍵盤孤兒：整個 slider 只支援滑鼠，鍵盤使用者完全動不了。修正：落實方向鍵、Home/End、Page Up/Page Down 的支援，並補上 focus 樣式。

這五個反模式，前面幾乎都對應到我講過的設計規格。直白地說，反模式不是「想不到」，而是「規格沒寫清楚」。你把後面的六步清單走完，這五個雷大概都不會踩。

原型能動不等於做得出來：Handoff 最容易漏的三件事

這是我整篇文章最想讓你記住的一節。Figma 的 Smart Animate 很會騙人，它讓你以為「拖曳→值改變→label 更新」這整串互動已經完成了，但實際上 Figma 原型只是在 variant 之間做視覺切換，它並沒有真的計算任何數值。真正上線時，這一切都要由前端的 JavaScript 重新實作。

所以 handoff 時，這三件事你一定要在設計稿裡講清楚，否則就是丟一個半成品給工程師：

一、把手與軌道的「可操作範圍」不等於「視覺範圍」

你的 thumb 在畫面上可能只有 16px，但行動裝置上手指的觸控區建議至少 44px。這代表工程師要幫 thumb 加一個透明的、更大的可點擊外框。你必須在稿上標註「視覺尺寸 16px、觸控區 44px」；只給一個 16px 的圓，然後指望工程師自己會想到，幾乎一定出事。這個觸控尺寸的觀念，跟做按鈕是同一套，你可以參考 CTA 行動呼籲按鈕設計裡對點擊區的討論。

二、值要如何「吸附」與「顯示」

slider 的值如果不是連續的，就要定義吸附（snapping）規則。例如價格區間 slider，步進通常是 100 或 500，極少是 1。你必須告訴工程師：最小值、最大值、步進值這三個數字，以及 value label 的顯示格式（要不要加貨幣符號、要不要千分位、小數點幾位）。這些不講，工程師只會用預設的整數，然後你的價格 slider 就會出現「$1,237」這種讓 PM 崩潰的值。

三、鍵盤操作與無障礙屬性

這是台灣設計圈最普遍的盲區。一個及格的 Range Slider 必須能用鍵盤完整操作：Tab 聚焦、方向鍵微調（一次一個步進）、Page Up / Page Down 大幅跳躍、Home / End 跳到頭尾。這不只是「nice to have」，而是 W3C WAI 的 ARIA Authoring Practices Guide（Slider Pattern）裡明確的要求。

前端實作時，slider 的根元素會帶 role="slider"，並透過 aria-valuenow、aria-valuemin、aria-valuemax 把目前值與範圍唸給螢幕閱讀器聽。這些屬性對應的，正好就是我前面講的 value、min、max 三個 Component Property。所以你在 Figma 裡把這個屬性做好，不只是為了 prototype 好看，而是直接幫工程師把無障礙規格也準備好了。

鍵盤操作這件事不能只靠口頭交代「要支援鍵盤」，你要把每一個按鍵對應的行為寫成規格，工程師才有依據。我把 W3C 對 slider 的鍵盤互動建議整理成一張表，這是 handoff 時可以直接附上的：

按鍵	行為
方向鍵右 / 上	增加一個步進值
方向鍵左 / 下	減少一個步進值
Page Up	大幅增加（通常是一次跳數個步進）
Page Down	大幅減少
Home	跳到最小值
End	跳到最大值

這張表的價值在於：它讓「鍵盤可操作」從一個模糊的要求，變成一張可勾核的清單。你拿這張表跟實作出來的 slider 對照，逐一按、逐一驗，合格就是合格，不合格就回去改。設計與前端之間最常見的摩擦，就是這類「你以為對方知道、對方以為你會講」的灰色地帶；用一張表把灰色地帶消除掉，協作效率會差很多。

鍵盤可操作這件事，背後的源頭是 Web Content Accessibility Guidelines（WCAG）2.1.1 這條 Level A 等級的要求：所有功能都必須能從鍵盤操作（見 WCAG 2.1.1 Keyboard 條目）。Level A 是無障礙的最低門檻，連這個都過不了，等於直接把一部分使用者擋在門外。

我自己對無障礙的態度很實際：它不是政治正確，而是生意。一個連鍵盤都不能操作的篩選器，等於把用鍵盤的進階使用者、把暫時受傷只能用鍵盤的人、把用螢幕閱讀器的視障者，全部排除在轉換漏斗之外。你花了大力氣把商品頁做到第一頁、把流量導進來，結果使用者在「選價格」這一步卡住離開，那前面的 SEO 投入就全白費了。從這個角度想，無障礙不是額外成本，是保護你既有投資的防線。

Slider 上線後的 UX 與效能：動多久、能不能鍵盤操作、會不會卡

設計完、交出去了，故事還沒結束。slider 上線後的表現，會直接影響你的轉換與 SEO，這部分是我作為行銷顧問最在意的。我把幾個關鍵判斷整理出來。

動畫時間要短，但不要短到沒有感覺

前面提過 Material Design 對小面積動效的建議（2024）是 200 到 300 毫秒。這個區間是有根據的：太短（低於 100ms）使用者會覺得畫面「閃了一下」，根本沒察覺發生了什麼；太長（超過 500ms）又會讓人覺得元件反應遲鈍。slider 的把手放大、顏色變化這類狀態切換，落在 200 到 300ms 是最舒服的。

互動元件不能成為效能與體驗的負擔

頁面速度會影響使用者的停留與轉換，這是已經被各種研究重複驗證的事實（見 web.dev 的〈Why does speed matter?〉）。slider 雖然體積不大，但 Carousel 如果塞了一堆高解析圖片又沒有做延遲載入，往往就是拖垮 Core Web Vitals 與首頁速度的元兇之一。設計階段你就能做的事：指定圖片的合理尺寸（不要把手機版也載入桌機的兩倍大圖）、要求輪播第二張以後延遲載入、把圖片格式壓成 WebP 或 AVIF。

選圖本身也是學問。輪播或商品 slider 用的圖，建議從合法、可商用的來源取得，商用免費圖庫網站總整理裡整理了一批可信任的來源，省得你日後收到侵權通知。

行動版的 slider 是另一個世界

桌機上滑鼠很精準，行動版上手指很粗、又會擋住畫面。所以行動版的 slider 有幾個調整：thumb 要更大或維持較大的觸控區；value label 不要放在 thumb 正上方（會被手指擋住），改放在 slider 上方固定位置；Carousel 要支援手勢滑動（swipe），不能只靠左右箭頭，因為行動版使用者直覺就是用滑的。

行動版的響應式調整，在 Figma 裡可以用 Constraints 與 Auto Layout 模擬，完整的設定邏輯我寫在 Figma 響應式設計教學。slider 元件本身要做手機與桌機兩個版本，不要指望一套樣式走天下。

一張表看懂 Slider 設計決策與前端實作的對照

下面這張對照表把前面散落各處的設計決策濃縮起來。這張表你可以直接複製進 design doc 或 handoff 文件：

你在 Figma 決定的	前端要實作的	漏掉的後果
四個狀態（Default/Hover/Dragging/Disabled）	對應的 CSS 與事件監聽	互動死板、使用者不知道能不能點
Focus 樣式	:focus-visible 樣式	鍵盤使用者找不到游標、無障礙不及格
thumb 視覺 16px、觸控區 44px	透明外框擴大 hit area	行動版點不到、使用者放棄操作
min / max / step 三個值	值的計算與吸附邏輯	出現無意義的值（$1,237）
value label 的格式與位置	動態文字節點	使用者盲拖、不知道選了多少
動畫 200 到 300ms	transition-duration	太黏或太閃，體驗不佳
Carousel 自動播放可暫停	hover/focus 暫停、暫停鈕	無障礙違規、使用者反感
圖片合理尺寸與格式	響應式圖片、延遲載入	首頁速度被拖垮、轉換下降

這張表的精神只有一句話：你多寫一格，工程師就少猜一次，使用者就少踩一個坑。

我給 Slider 設計的六步檢查清單

講了一大堆，最後給你一份我在每個 slider 專案收尾時都會走一遍的檢查清單。你可以把它存進自己的 Figma 模板，或貼在 design doc 結尾：

1. 先分類：這是 Range Slider 還是 Carousel？兩者的設計重點完全不同，不要混在一起做。
2. 列狀態：至少 Default、Hover、Dragging、Disabled 四個，外加 Focus。少一個就回去補。
3. 標尺寸：把視覺尺寸與觸控尺寸分開標。行動版觸控區至少 44px。
4. 定數值：寫清楚 min、max、step，以及 value label 的顯示格式。這三個數字是工程師最需要的規格。
5. 測極端：用最小值、中間值、最大值各跑一次，看 label 會不會爆框、雙把手會不會黏住。
6. 驗鍵盤：把手放上 slider，用 Tab 聚焦、方向鍵調整、Home/End 跳頭尾，確認每一個都有效。過不了，這個 slider 還沒做完。

這六步走完，你的 slider 才算是一個「可以交出去」的元件，一張漂亮的截圖還不能算數。

把 Slider 當規格來想：先決定再動筆

回頭看這整篇文章，其實我只在講一件事：slider 是一個互動規格，不是一個視覺裝飾。你把它當裝飾，就會陷入「畫得很漂亮但交不出去」的迴圈；你把它當規格，從零件、狀態、數值、無障礙一路想清楚，視覺自然就會長對。

這個「先規格、後視覺」的原則，其實就是 設計思考裡強調的同理心：你站在使用者與實作者的角度，把會卡住的地方先想清楚，避免把自己關在 Figma 裡一味追求像素完美。從更源頭的角度，UI/UX 設計的價值，從來都在於你能不能讓一個元件同時好看、好用、又做得出來，畫得多炫反而是末節。

我自己在帶設計與開發協作時，常講一句話：一份好的設計稿，不是「什麼都畫了」，而是「什麼都決定了」。slider 是檢驗這句話最好的試紙，因為它的每一個細節，從觸控區到步進值到鍵盤行為，都有一個明確的「對的答案」等著你寫下來。你寫得下來，這個元件就過關；你寫不下來、只能說「就⋯⋯看感覺」，那它就還沒做完。把這個標準內化成習慣，你做出的就不只是 slider，而是一整套可以重複使用的互動設計紀律。

載入狀態的設計也別忘了，slider 在資料還沒回來時需要一個合理的 loading 樣態，這部分可以參考 Figma 載入動畫教學，避免使用者對著一個空白的 slider 發愣。如果你的網站是用 WordPress 架的，Elementor 圖片輪播教學裡也有從設計走到實際上線的完整流程，可以對照著看「設計端的決策」如何對應到「上線後的設定」。

如果你看完這篇，回頭看自己之前做的 slider，發現「對，我那時候就是只畫了 Default 然後被工程師念」，那這篇就值了。下一次開新的 slider 元件，照著上面的六步清單走一遍，你會發現整個協作流暢很多，下游也不再把你當麻煩製造機。

設計這件事，換句話說，就是把別人會踩的坑先踩過一遍。slider 只是其中一個例子，但這個「先想清楚規格」的肌肉記憶一旦建立起來，你做任何互動元件都會受用。

給你一個可以今天就做的下一步：挑一個你最近做的 slider 元件，把它的四個狀態補齊、把 min/max/step 三個值寫在旁邊的註解裡、再用鍵盤實際操作一次。光是這三個動作，就能讓你下次 handoff 的來回溝通少掉一半。設計的進步，來自把每一個基本元件做到沒有模糊地帶，做更多花俏的東西反倒幫助有限。