畫面空白超過一秒,使用者就會開始懷疑「是不是壞掉了」。這是所有載入狀態設計要解決的第一個問題,而 Skeleton Screen(骨架屏)、Spinner(轉圈圈)、Progress Bar(進度條)其實對應到三種完全不同的等待情境,選錯工具比不做設計還糟。
很多團隊把載入狀態當成「反正先擋一下」的收尾工作,隨手丟個轉圈圈就上線。但 Nielsen Norman Group 和 LogRocket 的研究都指出,載入指示器直接影響「感知效能」(perceived performance)——也就是使用者「覺得」等了多久,而不是系統實際跑了多久。同樣是等 2 秒,骨架屏會讓人覺得「快好了」,空白轉圈圈卻讓人覺得「卡住了」。今天就把這三種載入狀態的差異、適用時機、跟實際做法整理清楚。
📖 學(核心)
骨架屏是什麼、為什麼有效
骨架屏是用灰色色塊模擬頁面最終結構的載入畫面——標題的地方放一條長灰條,圖片的地方放一個灰色方塊,清單的地方重複排列相同的骨架列。NN/G 的文章《Skeleton Screens 101》指出,骨架屏專門用在「整頁載入」的情境,它同時做到兩件事:第一,讓使用者確認系統還活著、沒有當機;第二,提前揭露頁面的資訊架構,讓大腦先建立「等一下畫面長怎樣」的心智模型。
這個「先看到骨架、再看到血肉」的漸進過程,會製造出一種畫面「正在逐漸成形」的錯覺,即使實際載入時間沒有變,使用者主觀上會覺得等待時間變短了。這也是為什麼 Slack、YouTube、Facebook、Pinterest 這些大型產品幾乎都用骨架屏取代傳統的空白畫面或轉圈圈,LogRocket 的文章特別點出這幾個案例。
骨架屏也有搭配動畫的版本,例如常見的「shimmer」光影掃過效果,或色塊明暗交替的脈動效果,用來持續提醒使用者「系統還在動作」,避免骨架畫面本身變成另一種形式的假死狀態。
三種載入指示器的分工:看「等待時間」跟「是否可預測」
選擇哪種載入狀態,關鍵不是喜好,是兩個變數:等待時間長短,以及系統是否知道還要多久。UX Movement 跟 NN/G 對進度指示器的研究整理出清楚的時間帶:
- 1 秒以下:什麼指示器都不要放,使用者根本來不及感知,反而變成畫面雜訊。
- 1 到 3 秒:適合用 Spinner 或骨架屏這類「不確定型」(indeterminate)指示器,單純告訴使用者「處理中,快好了」。
- 3 到 10 秒:應該換成「確定型」(determinate)的進度條,讓使用者看到剩餘量,而不是一直轉圈圈。
- 10 秒以上:只能用進度條。像是下載檔案、上傳影片、安裝更新這類已知總時長的任務,一定要讓使用者看見具體進度,否則等待會迅速變成挫折感。
這裡的核心原則是:Spinner 適合「不知道要多久、但很快就好」的任務;Progress Bar 適合「知道大概要多久、時間較長」的任務;骨架屏則適合「整頁內容正在陸續填入」的任務。三者不是互相取代,而是分別對應不同情境,很多產品其實會混用——例如切換頁面用骨架屏,頁面內某個元件重新整理用 Spinner,檔案上傳用進度條。
轉圈圈的陷阱:為什麼 Spinner 用久了會反效果
Spinner 的問題不在於它「不好看」,而在於它完全不透露任何資訊——使用者不知道還要等多久,也看不出系統有沒有在前進。當等待時間拉長到 10 秒、30 秒以上,無止盡轉動的 Spinner 反而會強化使用者的無力感,因為畫面給出的訊號是「這件事沒有終點」。這也是為什麼長時間任務不該用 Spinner 撐場面,而是要換成進度條,把「未知的等待」轉換成「可預期的等待」。
同樣的邏輯也適用在骨架屏上:骨架屏最適合用在等待時間中短(通常建議 10 秒以內)、而且畫面結構已知的情境,例如清單、卡片、個人頁面這類版面固定的頁面。如果拿骨架屏硬套在結構會大幅變動、或載入時間非常長的頁面,骨架屏帶來的「快好了」錯覺反而會在使用者發現「怎麼還沒好」時,造成比空白畫面更大的落差感。
🧠 記
- 骨架屏用灰色色塊模擬頁面最終結構,專門用在整頁載入情境。
- 骨架屏的效果來自「提前揭露資訊架構」+「漸進成形的錯覺」,兩者一起降低感知等待時間。
- 1 秒以下不放指示器;1–3 秒用 Spinner 或骨架屏;3–10 秒換進度條;10 秒以上一定要用進度條。
- Spinner 適合「不知道多久、但很快好」;Progress Bar 適合「知道大概多久、時間較長」。
- 長時間任務用 Spinner 會放大挫折感,因為使用者看不到終點。
- Slack、YouTube、Facebook、Pinterest 都用骨架屏取代空白畫面或轉圈圈。
- 骨架屏動畫(shimmer、脈動)的作用是持續證明系統還在運作,避免變成另一種假死畫面。
✍️ 實踐
花 10 分鐘,檢查自己手上或常用的一個 App/網站的載入狀態:
- 打開一個你熟悉的產品(自己做的專案或常用 App 皆可),故意切到慢速網路模式(瀏覽器 DevTools 的 Network throttling,或手機切飛航模式再開一半),觀察它載入時出現的是骨架屏、Spinner、進度條,還是完全空白。
- 用碼表抓一下這個等待大概幾秒,對照上面「1 秒 / 1–3 秒 / 3–10 秒 / 10 秒以上」的分級,判斷目前用的指示器是否用對了。
- 如果是自己的專案,挑一個目前用 Spinner 撐場、但頁面結構固定(例如清單頁、卡片頁)的地方,寫下把它換成骨架屏需要改動哪些元件,列 3 個具體步驟就好,不用真的動工。
🔗 延伸學習
- Skeleton Screens 101 - NN/G
- Skeleton loading screen design — How to improve perceived performance - LogRocket
- Progress Indicators Make a Slow System Less Insufferable - NN/G
- Progress Bars vs. Spinners: When to Use Which - UX Movement
💬 問 AI
1. 我的產品有一個頁面載入常常超過 5 秒,應該用骨架屏還是進度條,為什麼?
2. 幫我設計一個清單頁的骨架屏結構,列出需要幾個色塊、分別對應哪些真實元素。
3. Spinner 動畫要多快轉才不會讓使用者覺得煩躁,有沒有建議的秒數或圈數?
4. 骨架屏的 shimmer 動畫效果,用 CSS 要怎麼寫最簡單?
5. 如果同一個頁面裡有多個非同步資料源,各自載入速度不同,載入狀態要怎麼設計才不會畫面很亂?