Loading…當使用者只能等待，如何優化等待的體驗
因為工程師分享感覺很精華，不記下來實在可惜，稍作整理分享出來給大家參考。系統跑太慢/效能太差/Loading太久，不只是工程師的問題，設計師也有可以做的事！
這篇文章紀錄了前陣子開發處理 Loading 問題時收集的資訊。
大約有一半彙整 UX loading pattern 的討論，另一半用白話(?)整理後端可以控制拿取資料量的方法。適合近期產品有效能問題的設計師閱讀。
“No matter what, faster is better and less is more.”
Jubo 多數產品線 2B，相較於 2C 跳出率影響沒那麼大，但頻繁且長時間的 loading 仍然困擾我們的使用者。
設計訪談、了解使用情境、繪製UJM、釐清每一個步驟的資訊需求 ，盡力在工程限制下設想一個又一個「不拿取那麼多資料」的方案 — — 系統效能還是會有跟不上的一天。
作為設計師，我們還能多做一點。
載入中的回饋（Loading feedback）
提示使用者「載入中」的狀態是必要的，隨手一查就有 Loading Spinner, Progress Indicator, Skeleton screen, etc. 等諸多提示方法。但可想而知，設計等待頁面或流程並不是挑一種放進 Figma 就可以了事。
回饋的演化
“好的載入體驗需要與時俱進”
- Spinner — 提示使用者程式正在運作
- 趣味畫面 — 讓等待變得（稍微）可以忍受
- 解釋等待原因 — 讓使用者理解等待的價值（我等待是為了換來這個！）
- 顯示剩餘時間 / 完成度 — 讓使用者評估等待成本
- Skeleton / 分區載入— 加速使用者的時間感（有東西跑出來了！應該很快就好了吧！）
- Shimmer / Skeleton 顏色 — 給使用者一些東西去「看」
- ……持續嘗試吧！
核心概念
查找了一些討論（歡迎查看文章底部的參考資料），對於 Loading feedback 的目的各有不同的解讀。我綜合成兩個通用的設計方向：
一、建立使用者對於「等待」的期待
- 這是一個「載入中」的狀態
- 為何需要你等待
- 你（可能要）等多久
- 你等待後可以得到什麼
- 等待期間你可以做什麼
這是一個他如常使用軟體程式時的過程？或是他認為這是系統需花較多時間進行的任務？
在畫面增加一個載入按鈕、建立排程執行 — 讓使用者不必在原地等待 — 完成後通知的流程、挑選等待過程提示的字詞……我們盡可能讓使用者的期待符合程式運作的方式。
二、控制使用者的時間感
- 全部載入前預先顯示內容— 讓使用者感受到「載入進度」
- 拉長載入時間 — 讓使用者感覺「重要資料被仔細地處理」🧐
Skeleton 就是前者最經典的例子，下一段討論的分段呈現也是一種方式；後者比較少見，但開發 2B 產品或是處理金融資訊等服務時或許就需要注意（腦中浮現電影中浮誇的解鎖動畫）。
評估載入的呈現
“最花時間的事情就是拿資料”
設計 Loading feedback 之前，我們可以先了解「載入資料」本身到底是怎麼回事。當一個頁面需要拿越多資料，就需要載入越久，跟統計資料或判斷前端如何呈現無關。
當設計師想縮短載入時間感，可以依資料類型考慮不同的呈現，透過分段呈現或分段載入，減少「拿取資料 — 看到資料」等待時間。
分段呈現
一次載入大量資料時，如果等待資料全部載入完畢會花更多時間，可以在已經載入部分內容時，就先呈現資料。
一、優先呈現拿完的資料
整個畫面中的資料彼此獨立，可以逐一呈現、讓使用者盡快看到內容。
二、優先呈現重要資料
排序使用者最在意的內容，其他次要資訊後續再顯示。
分段載入
英文是 Lazy Loading，概念是優先拿目前畫面上需要的資料，等使用者需要時再去拿取更多資料。
這個方法可以直接減少單一次拿取的資料量，除了可以有效降低載入時間，也可以減輕系統負擔。
⚠️ 必須注意的是，因為資料並沒有全部拿取完成，建議需與工程師討論篩選、排序等操作，避免還沒有拿出的資料無法出現在篩選結果中。
一、Infinite Scroll
原理是預先載入「比畫面所需更多一點」的預備資料，在使用者滑到預備資料時，再去載入新一批資料。多數社群平台會採用這樣的操作，讓使用者不斷地往下滑，永遠都有新的資料可以看。
舉例：螢幕一次可以呈現 10 筆，那麼第一次拿取資料時拿出 20 筆，當使用者滑到第 11 筆時，就再去拿出 20 筆。
二、「載入更多」按鈕
同樣限制單一次拿的資料量，只是在使用者滑完時，需手動點選按鈕載入新資料。
三、分頁
與前者差不多，但使用者比較能透過頁數預期資料有多少。
延伸閱讀：Pencil & Paper 的這篇研究列出不同載入時間對應的 Pattern，非常推薦大家點進去看看
▪️ < 0.1s 完全不會被使用者察覺，可直接顯示資料
▪️ 0.1s~1s 幾乎不會被察覺，但也不要試圖置入 Loading Indicator，一閃即逝的提示可能會讓使用者困惑
▪️ < 1s顯示 Indeterminate Loading Indicator
▪️ 2s~10s 顯示 Determinate Loading Indicator 或是時間
▪️ > 10s 顯示完成度、時間，或是允許使用者離開這個頁面進行其他事
謹慎更新資料
當頁面所需的資料量太大，或是分段呈現無法符合使用者的需要，我們可以更仔細地檢視「如何拿取資料」。事實上，除了將大批資料分階段載入，工程端可以非常精細地控制「什麼時候」拿取「哪些資料」。
如果做一件事情會耗費許多時間，我們就會避免在不必要的時候反覆執行，拿取資料也是如此。當這批資料量很大，並且耗費了使用者許多耐心，設計師們想必不會想讓他們反覆等待。
儘管聽起來有點道理，但這並不一定會在建構系統時優先考量。
因為使用者總是期待最新、最準確的資料，導致我們頻繁且大量更新；當更新拖慢效能，就會產生許多不愉快的等待體驗。
“當資料太多、效能太少，更新就是一把兩面刃”
更新範圍
你進到一家餐廳，耐心等待了許久第一道菜終於上桌，你吃了幾口，接著服務生把你的碗筷收走，抱歉地表示：「這副碗筷在桌上已經放了半小時，恐怕不太新鮮，我重新換一個給你。」
你想必會傻眼。
哈囉？這是碗耶？哪有新不新鮮的問題？與其浪費時間換碗筷，不如早點把第二道菜端上來啊！
套用到 Jubo Core 產品上的例子：機構設定、人員檔案等等內容更動頻率都不高，那麼我們就不需要在每次更新，都重新從資料庫拿出全部的資料。
我們可以評估資料的性質，分別判斷它們適合的更新頻率。
更新頻率
讓我沿用食物的概念舉例。我們可以幫資料定義「保存/賞味期限」，減少重複拿取資料。
一、過期不可用的資料
已經不能吃了，直接丟掉吧。我再買新的給你。
當資料過期，直接重新拿新的。
此時畫面通常會是空白或有一個 Spinner 的蓋板畫面，但使用者不會看見任何資料（因為已經被捨棄不使用了）
二、不太新但堪用的資料
不是很新鮮但還可以吃，你先吃點墊墊肚子。我再買新的給你。
當資料還堪用，可以先顯示出來讓使用者看，同時在背景重新拿新的資料，拿取完成後再替換上來。如果是使用者高度在意的資料，還可以註記「上次更新時間」和「自動更新頻率」。
此時使用者可以在畫面上看到資料，資料呈現方式也與平時相同，只是在資料拿取完成後，會主動更新或是跳出提示讓使用者點擊更新。
三、可用資料
這很好吃，給你吃(?)。
此時畫面基本上不需做處理。
但保險起見，也可以在頁面呈現「上次更新時間」，提供使用者評估是不是要重新整理。部分無法經常性拿取的資料，別無他法也會有這樣的標注。
更神奇的事情來了！
「到期」可以分別套用不同的定義！
- 時間
最簡單的就是幫資料定義有效期限，依據資料拿來的時間決定它們是「過期/堪用/可用」
舉例：資料剛拿到的 10 分鐘內保證(?)不會有其他人同時更新，只要呈現上次拿到的資料即可；到了 30 分鐘內就可能有（但不一定）其他人也登打資料，但還是可以先擋著用，同時趕快去拿新的資料回來；過了 2 小時的資料就不可信了，使用者看到的已經跟資料庫大相徑庭，千萬不要顯示舊資料以免被嫌棄有 bug (?)
- 行為
除了時間，也可以依據特定的行為來決定資料是否到期。
如果預期使用者要進行高度精準的操作，需盡可能保持資料在最新狀態，那麼可以指定開始/結束這些操作時，必須更新頁面上的資料。
具體哪些行為適用可以找工程師討論，但原則上使用者手動操作的都還行。畢竟設計師也不會想看到、使用者在非自己預期時突然被更新資料。
舉例 1：護理師給藥時，如果用藥計畫不夠新，可能會給錯藥、導致住民生命危險，因此不管用藥計畫是什麼時候拿的，護理師「進入給藥頁面時」都會重新拿取用藥計畫
舉例 2：同一瀏覽器登入不同 NIS 帳號時，開啟舊帳號的分頁會在「切換回該分頁」的時候立刻過期。（沒錯！切分頁也是一種行為）
小結
我們討論了資料的呈現、載入方法，以及如何減少載入內容卻維持資訊品質。這些方式可以同時使用、發揮組合技。
舉例：
班表管理載入過程 — 總共同時應用了- 優先呈現「班表月曆」，需要更多資料判斷「異常提示」稍晚一點出現
- 分頁：週總表，每頁 20 人
- Infinite Scroll：日總表，每次多拿取畫面以外 10 人的資料
（因月曆形式不適合逐一顯示，也怕造成客戶誤會，故無分段呈現）— — — 以上是現有的 ，以下近期正在優化— — —
重新定義更新範圍
A. 機構檔案、人員檔案、個人服務設定為一組，採用低頻率
B. 照顧計畫、班表管理為一組，採用高頻率重新定義更新頻率
1. A資料延續 Global 更新機制（重整頁面、切換模組、重新登入），會在蓋板 Loading 時重新拿
2. B資料拿滿 1 小時後過期，頁面蓋版重整
3. B資料在模組內「切換 date picker、切換 tab、切換檢視人員/個案」會過期，頁面蓋版重整
4. B資料在「新增、編輯、刪除」排班或打卡時，會視為堪用，頁面上呈現既有資料，但同時在背景拿新資料（因使用者習慣在更新班表後立即檢視異常，需避免資料不夠新導致遺漏）*Pending，待calendar元件優化
5. B資料在「Drag & Drop 行為」和「切換瀏覽器分頁」時會視為可用
參考資訊
- Fanny Vassilatos, Ceara Crawshaw（2022）。Ux Pattern Analysis — Loading Feedback。Pencil & Paper。
- Scarlett Payne（2021）。Your Loading Spinner Is a UX Killer! Here’s an Alternative。Boldist。
- Bill Chung（2018）。Everything you need to know about skeleton screens。UX Collective。
- Ramprakash Ravichandran（2020）。Connect, No Matter the Speed。Google Design。
- 李珩（2023）。工程處理 Loading 的方式分享(???)。217 Room4 (???)。
