2019年設計師必看，UI加載動畫徹底解讀

如下內容由摹客團隊翻譯整理，僅供學習交流，摹客iDoc是支持智能標註和切圖的產品協做設計神器。

 

沒有人喜歡等待。

 

現在，愈來愈多的優秀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

 

理想狀態中，加載動畫也許具備如下特點：

 

一、儘量少地顯示加載動畫

若是你有辦法讓你的工具或網站很是高效的運行，那真的是很是厲害。或者說，至少能夠達到用戶的指望值。即便加載動畫設計地再好，若是加載時間過長，用戶也會失去耐心，或者只顯示加載動畫，不提示用戶等待時長，這也是很是很差的體驗。總之，加載動畫只是一種緩兵之計，解決內容加載的問題纔是根本之道。

 

二、給出加載時間預估

能夠反饋給用戶一個大體的等待時間，或者更直觀地顯示加載進度。好比說，一共須要上傳了多少個文件？軟件更新須要多少時間？已經進行到了哪一個環節？這些用戶體驗細節均可以幫助設定用戶預期，減小心理焦慮

 

 圖片來源

 

三、給出用戶須要等待的緣由

一些APP或工具的加載動畫其實並不能被用戶當即理解，這時候，就須要很是巧妙地提示用戶爲何他們須要等待，加載時軟件背後在作些什麼。

 

圖片來源

 

說回上文提到的反饋工具，由於沒法作到1s內完成內容加載，所以向用戶解釋等待時長就很是重要。動畫會提示用戶軟件正在加載界面，這樣用戶就會知道，軟件不是出bug了，而是在處理請求：

 

圖片來源

 

四、讓等待過程更有趣

放置一個引人入勝的加載動畫吸引用戶注意力。

 

 

圖片來源

 

五、減小用戶等待時間的感知

這與上述觀點很是相關。若是在等待時能夠提供吸引用戶注意力的東西，會減輕用戶心理焦慮。能夠考慮吸引人的顏色搭配，一些新穎的想法等等。

 

圖片來源

 

六、傳遞公司品牌形象

若是用戶在使用你的產品或者網站時，不管如何都須要等待，那爲何不有效利用這個時間呢？並非說非要作一些厲害的加載動畫，或者非要使用什麼心理學技巧，只需將加載體驗與你的品牌形象保持一致便可。

 

圖片來源

 

第三部分：不可忽視的UI細節

 

雖然有人可能認爲加載器只是一個很小的UI細節，但它卻有多種類型和變化。這裏提供了幾種形式——進度條，無限循環加載動畫和骨架圖。

 

一、進度條

若是能夠明確加載時間，可使用進度條，其原理是經過數字或視覺形象來表現，形式也能夠作到多種多樣。

 

數字進度條有時被稱作百分比指示器。它們能夠簡單直接，也能夠極具創意，選取適合的就行。

 

 

圖片來源

 

更有趣的進度條，具備百分比指示的循環動畫：

 

圖片來源

 

進度條的做用就是告知用戶等待時長，而且向用戶展現到目前爲止的進展狀態。根據具體狀況，進度條也能夠只是線性的，不用都具有百分比指示。

 

舉個例子，Gmail。它在加載時，也沒有顯示進度百分比，但用戶卻能夠很清晰地感受到加載進度，如下兩個例子都是很是具備創意的：

 

圖片來源

 

 

圖片來源

 

二、無限循環加載動畫

當加載時間未知時，能夠考慮使用無限循環加載動畫。能夠是默認的循環動畫，也能夠添加一些創意，總之，告知用戶APP「依舊在工做」。

 

具備創意的循環動畫能夠緩解用戶心理焦慮，由於它在向用戶解釋爲何加載須要時間。

 

圖片來源

 

創意循環動畫能夠與產品和業務很好結合，輔助打造品牌形象。

 

圖片來源

 

無限加載動畫提示用戶在程序上傳或執行某些操做時須要等待，但不指定須要多長時間。通常來說，環狀循環動畫是不錯的選擇，能夠簡潔直觀，也能夠精心設計。

 

圖片來源

 

圖片來源

 

不難看出，現在的加載動畫早已不只僅是系統的狀態UI元素，而更像是一種藝術表達。

 

三、骨架圖

骨架圖能夠提供加載界面的漸進過程。你能夠把它想象成頁面佔位符，而後逐步加載圖片，文本和其餘內容。

 

骨架圖這個術語最早出如今Luke Wroblewski的文章中（移動設計細節：避免旋轉器，2013）。盧克建議使用骨架圖來提供更好的加載體驗。這個想法也得到了其餘設計師的支持，並在Facebook，LinkedIn，YouTube，Google Drive等用戶界面中運用。

 

分享一個案例：若是你在使用網頁設計工具Figma，你會看到其頁面頂部有一個漸進加載的進度條，你會先看到項目的佔位符，而後才顯示可用數據：

 

圖片來源

 

第四部分：簡單處理仍是製做精良？

 

拋開一些設計精細的例子和Dribbble的設計概念，在大多數應用程序中，你看到的是默認或簡單的加載動畫。

 

很長時間以來，簡單的加載動畫被普遍運用，並被視爲最佳的加載辦法。使用默認或開源加載動畫不只輕鬆簡單，設計師也不用花費時間來製做自定義動畫，還能夠節省開發人員的開發時間。

 

那麼，加載動畫應該簡單處理仍是精良製做？這個問題其實說法不一。

 

一方面，操做系統的默認UI組件可讓設計師進行原生設計，實現更好的用戶體驗。用戶也更熟悉本機組件，能夠很快弄明白如何使用，而且預期結果。

 

舉個例子，蘋果用戶對於蘋果平臺的標準導航控件，按鈕或圖標都更熟悉，用戶甚至可能在遇到默認加載時，都不會感知到加載的存在。

 

另外一方面，用戶也有可能對默認組件有很差的體驗，尤爲是對於加載器：

 

還有一點，若是一個應用程序使用操做系統的加載指示器而不是自定義加載指示器，用戶可能會抱怨網絡鏈接或者設備速度。- Quora的軟件工程師Yi Gu。

 

關於這個觀點，目前尚未找到相關研究，但確實也是一個有意思的思考點。

 

若是你正在開發MVP（最小可行產品）或者項目的第一個版本，使用簡單、默認或開源加載動畫彷佛更合乎情理。在此階段，即便是使用最有創意的加載動畫也不能解決根本問題，由於根本問題應該是產品自己。

 

圖片來源

 

有趣的是，在2016-2019年之間出現了大量精心製做的加載動畫。究其緣由，細節的重視，設計技術日益成熟，技術環境的改善以及動畫製做工具的出現等等，全部這些都使得加載動畫更具創造性。若是瀏覽Dribbble，能夠找到很是多酷炫的加載動畫。

 

即便咱們是隻有5我的的創業公司，咱們也會考慮更好的用戶體驗，讓用戶的等待體驗更加愉快。不然，咱們的產品只會慢慢失去用戶。

 

以上就是所有分享，感謝閱讀！

 

學習工具，但不受限於某種工具。摹客iDoc，高效協做，從產品到開發，只要一個文檔，讓你的團隊高效協做！