沒有人喜歡等待。
如今，越來越多的優秀iOS應用程序、MacOS工具和網站爭相出現，用戶對產品質量的要求也水漲船高。在用戶心中，真正優秀的產品必然是要能夠快速響應他們的需求。
分享一個真實案例：我們最近發佈了一款工具，為iOS應用程序提供用戶反饋，不出所料，第一個版本並不完美，加載也會延遲2-3秒。
你猜怎麼著？
用戶以為這3秒加載延時是一個bug。在實際開發環境中，總是會有諸多問題，網絡遲緩，代碼不優化，操作時間長或者數據太多等等，因此，App運行的速度很難做到用戶期望的那麼快。雖然最早期的忠實用戶可能會稍有耐心，但絕大多數用戶會選擇立即關閉。
要是產品界面可以為用戶立即提供明確的反饋信息，那結果可能就很不一樣了。剛才發生的操作是一個bug？還是隻是在等待服務器請求？用戶需要等待多長時間？用戶為什麼要等待？
要弄明白以上問題，不妨一起深入地研究一下吧。為了方便理解，今天主要從以下幾個方面講解加載動畫：
- 加載動畫的由來
- 加載動畫：101
- 不可忽視的UI細節
- 簡單處理還是製作精良
第一部分：加載動畫的由來
有這樣一類反饋形式，設計師使用進度條，加載指示器，預加載器或旋轉器等來告知用戶什麼時間發生了什麼或者加載了什麼，從而減少用戶心理焦慮。
這種類型的反饋是什麼時候開始使用的呢？
無意中看到一篇關於Nielsen Norman的文章，原來在1993年就已經提到過有關於響應時間和加載動畫的描述。（參考1985年的文獻資料）
如果計算機無法提供快速響應，則應以百分比進度指標的形式向用戶提供持續反饋 [Myers 1985，“計算機 - 人機界面百分比進度指標的重要性。”]。
進度指標有三個用途：首先，提示用戶系統沒有崩潰而是正在解決問題；其次，告知用戶最大等待時長，因而用戶可以在等待期間做點其他的事情；最後，為提供用戶了界面視覺內容，減輕用戶心理焦慮。- 雅各布尼爾森，1993年1月1日
Web 1.0後，幾乎每個網站都採用了預加載器。用戶的注意力很可能被那些移動的動畫吸引，與此同時，頁面的其餘內容在進行加載。
在2007年，網站預加載器長這樣：
那時候，還有專門的指南幫助你使用Fireworks（2007）或Flash（2008）創建加載動畫，還有一些工具，比如“加載GIF生成器”（2009）。
到2010年，CSS3技術運用到加載動畫的製作中來，出現了大量的教程教授如何製作CSS3動畫和加載動畫包。設計師也可以在Photoshop CS5中製作加載動畫，這在十年前是非常流行的。
在那時，加載動畫更偏重於web端問題，加載動畫本身也是一個非常嚴重的問題。在2010年的時候，很多Flash網頁開始製作一些更具創意的加載動畫：
一直以來，進度條和旋轉器在Skeleton屏幕備受爭議（移動端設計細節：不要使用旋轉器 2013）。顯然，簡單的進度條和旋轉器已經不能滿足需求，在2014年至2016期間，設計師也開始花費更多精力在這一領域，更多優質的加載動畫教程，設計資源，插件，開源項目也爭相出現。
儘管設計趨勢和設計技術不斷變化，但向用戶提供界面反饋的需求卻始終不變。
第二部分：加載動畫：101
理想狀態中，加載動畫也許具有以下特色：
1、儘可能少地顯示加載動畫
如果你有辦法讓你的工具或網站非常高效的運行，那真的是非常厲害。或者說，至少可以達到用戶的期望值。即使加載動畫設計地再好，如果加載時間過長，用戶也會失去耐心，或者只顯示加載動畫，不提示用戶等待時長，這也是非常不好的體驗。總之，加載動畫只是一種緩兵之計，解決內容加載的問題才是根本之道。
2、給出加載時間預估
可以反饋給用戶一個大致的等待時間，或者更直觀地顯示加載進度。比如說，一共需要上傳了多少個文件？軟件更新需要多少時間？已經進行到了哪個環節？這些用戶體驗細節都可以幫助設定用戶預期，減少心理焦慮
3、給出用戶需要等待的原因
一些APP或工具的加載動畫其實並不能被用戶立即理解，這時候，就需要非常巧妙地提示用戶為什麼他們需要等待，加載時軟件背後在做些什麼。
說回上文提到的反饋工具，因為無法做到1s內完成內容加載，因此向用戶解釋等待時長就非常重要。動畫會提示用戶軟件正在加載界面，這樣用戶就會知道，軟件不是出bug了，而是在處理請求：
4、讓等待過程更有趣
放置一個引人入勝的加載動畫吸引用戶注意力。
4、減少用戶等待時間的感知
這與上述觀點非常相關。如果在等待時可以提供吸引用戶注意力的東西，會減輕用戶心理焦慮。可以考慮吸引人的顏色搭配，一些新穎的想法等等。
5、傳遞公司品牌形象
如果用戶在使用你的產品或者網站時，無論如何都需要等待，那為什麼不有效利用這個時間呢？並不是說非要做一些厲害的加載動畫，或者非要使用什麼心理學技巧，只需將加載體驗與你的品牌形象保持一致即可。
第三部分：不可忽視的UI細節
雖然有人可能認為加載器只是一個很小的UI細節，但它卻有多種類型和變化。這裡提供了幾種形式——進度條，無限循環加載動畫和骨架圖。
1、進度條
如果可以明確加載時間，可以使用進度條，其原理是通過數字或視覺形象來表現，形式也可以做到多種多樣。
數字進度條有時被稱做百分比指示器。它們可以簡單直接，也可以極具創意，選取適合的就行。
更有趣的進度條，具有百分比指示的循環動畫：
進度條的作用就是告知用戶等待時長，並且向用戶展示到目前為止的進展狀態。根據具體情況，進度條也可以只是線性的，不用都具備百分比指示。
舉個例子，Gmail。它在加載時，也沒有顯示進度百分比，但用戶卻可以很清晰地感覺到加載進度，以下兩個例子都是非常具有創意的：
2、無限循環加載動畫
當加載時間未知時，可以考慮使用無限循環加載動畫。可以是默認的循環動畫，也可以添加一些創意，總之，告知用戶APP“依舊在工作”。
具有創意的循環動畫可以緩解用戶心理焦慮，因為它在向用戶解釋為什麼加載需要時間。
創意循環動畫可以與產品和業務很好結合，輔助打造品牌形象。
無限加載動畫提示用戶在程序上傳或執行某些操作時需要等待，但不指定需要多長時間。一般來講，環狀循環動畫是不錯的選擇，可以簡潔直觀，也可以精心設計。
不難看出，如今的加載動畫早已不僅僅是系統的狀態UI元素，而更像是一種藝術表達。
3、骨架圖
骨架圖可以提供加載界面的漸進過程。你可以把它想象成頁面佔位符，然後逐步加載圖片，文本和其他內容。
骨架圖這個術語最先出現在Luke Wroblewski的文章中（移動設計細節：避免旋轉器，2013）。盧克建議使用骨架圖來提供更好的加載體驗。這個想法也獲得了其他設計師的支持，並在Facebook，LinkedIn，YouTube，Google Drive等用戶界面中運用。
分享一個案例：如果你在使用網頁設計工具Figma，你會看到其頁面頂部有一個漸進加載的進度條，你會先看到項目的佔位符，然後才顯示可用數據：
第四部分：簡單處理還是製作精良？
拋開一些設計精細的例子和Dribbble的設計概念，在大多數應用程序中，你看到的是默認或簡單的加載動畫。
很長時間以來，簡單的加載動畫被廣泛運用，並被視為最佳的加載辦法。使用默認或開源加載動畫不僅輕鬆簡單，設計師也不用花費時間來製作自定義動畫，還可以節省開發人員的開發時間。
那麼，加載動畫應該簡單處理還是精良製作？這個問題其實說法不一。
一方面，操作系統的默認UI組件可以讓設計師進行原生設計，實現更好的用戶體驗。用戶也更熟悉本機組件，可以很快弄明白如何使用，並且預期結果。
舉個例子，蘋果用戶對於蘋果平臺的標準導航控件，按鈕或圖標都更熟悉，用戶甚至可能在遇到默認加載時，都不會感知到加載的存在。
另一方面，用戶也有可能對默認組件有不好的體驗，尤其是對於加載器：
還有一點，如果一個應用程序使用操作系統的加載指示器而不是自定義加載指示器，用戶可能會抱怨網絡連接或者設備速度。- Quora的軟件工程師Yi Gu。
關於這個觀點，目前還沒有找到相關研究，但確實也是一個有意思的思考點。
如果你正在開發MVP（最小可行產品）或者項目的第一個版本，使用簡單、默認或開源加載動畫似乎更合乎情理。在此階段，即使是使用最有創意的加載動畫也不能解決根本問題，因為根本問題應該是產品本身。
有趣的是，在2016-2019年之間出現了大量精心製作的加載動畫。究其原因，細節的重視，設計技術日益成熟，技術環境的改善以及動畫製作工具的出現等等，所有這些都使得加載動畫更具創造性。如果瀏覽Dribbble，可以找到非常多酷炫的加載動畫。
