国产欧美一区二区精品婷婷,曰韩精品一区二区,亚洲伊人网站

設計移動端應用產品時，我們絕大多數的精力和時間都會花在各個頁面的設計上。但與此同時，網絡環境的復雜性，會造成在網速偏慢、弱網、無網的條件下，用戶相當一部分停留時長會用在Loading上——無論頁面最終呈現出來的狀態我們設計得多么精美，它的加載總是需要一個過程。

而頁面打開和跳轉時的加載過程，很多時候會在設計中被嚴重忽視，最后在項目上線前倉促、隨意地進行設計，甚至任由開發找一個「菊花」放上去轉一轉就完事了。

Loading過程的設計缺失對用戶體驗的傷害無法量化，但長此以往，猶如一劑慢性毒藥，總有突破用戶忍耐極限，導致用戶流失的一天。

本文將簡單梳理移動端應用設計中常見的加載模式，并結合一些國內外應用的實例，探討如何針對場景特點選用合適的加載方式。

一. 模態加載

提到加載方式的分類，最明確的一個界限應該就是模態加載和非模態加載。而說起模態加載，可能有人會根據一些經典書籍中的觀點認為模態一定是不好的，非模態才是正義。

但事實上，選用模態加載還是非模態加載，首先要做的是問自己一個問題，這個加載是否出現在不可逆流程？

1. 模態加載與「不可逆流程」

這里說的「不可逆」并非表達平日語境下「無法挽回」的含義，只是指一些單向通行的線性流程。典型如注冊類（注冊、登錄、找回密碼）、交易類（下單、支付、轉賬)流程，比如下圖易信的注冊流程和微信發紅包的流程。

在不可逆流程中，一個步驟加載時如果允許用戶隨意觸發其他行為，極易導致各種分支和異常。為了防止用戶犯錯，也為了設計和開發時減少異常流數量，在這類流程中使用模態加載是很正常的選擇。

2. 其他場景下，避免模態阻斷

而在無關不可逆路徑的情況下，確實如經典論述所說的，應該減少模態阻斷的使用。

采用模態加載則會讓用戶在等待期間無所事事，等待時間較長時會加劇焦躁情緒的產生。尤其是一些APP直接在啟動頁采用模態加載，這會導致用戶感覺與產品每次見面都有一道無法逾越的鴻溝。

在國內，這種情況已經比較少了。不過少數金融類的APP仍然會直接在啟動頁進行阻斷式的模態加載，考慮到金融類APP需要保障資金安全，這樣的處理方式可能有一些行業特殊性。

一貫傳統的日本，時至如今，很多APP仍然保留了在登錄頁就模態加載的習慣。即使是毫無阻斷必要的。

電商類APP和交通查詢類APP也是如此，以服飾電商ZOZOTOWN和東京メトロ為例。

當然，這兩個APP實際上內部的設計質量已經非常不錯了，有許多細節是值得借鑒的，這里只是就事論事討論它們的啟動加載問題。

它們在啟動加載中使用了蒙層式的模態加載，即使東京メトロ設計了極富特色的加載指示符（9個代表不同線路的小圓圈），仍然改變不了一種將用戶拒之門外的隔閡感。

如果說電商APP的啟動多是在用戶較為閑暇、安靜的場景，模態登錄帶來的傷害相對較小。那么交通查詢類APP就不一樣了，啟動場景多是在戶外移動，急于知道結果以確定下一步往哪走的情形之下，更不適合使用模態加載。地鐵查詢APP更為特殊，很大比例的場景是用戶正在地鐵中查詢換乘信息，在信號不佳的情況下直接模態阻斷，這樣的體驗是致命的。

綜上，我的判斷是，除了不可逆流程外，基本上沒太大必要去使用模態加載。

百度地圖在搜索地點中使用了模態，相比之下，而iOS自帶的地圖，搜索地點就沒有采取模態加載，用戶可以在不耐煩時隨時嘗試其他操作，體驗上的差別顯而易見。

3. 模態阻斷要有「取消」選項

即使確信模態加載是正確的，最好也給用戶一個「取消」的選項，避免用戶只有殺掉進程以結束漫長的等待。

上面例子中，百度地圖的搜索采用模態或許必要性不大，但至少設計師意識到了「取消」選項的重要性，用戶在加載過程過慢時可以隨時點擊「×」終止行為。

反例是EBAY的登錄頁，上面有一個「×」，會讓用戶誤以為是「取消」，但實際上是關閉登錄頁的按鈕，在登錄加載過程中是無法點擊的。弱網環境下的用戶唯有漫長的等待，唯一能做的就是殺掉進程。用戶被卡住后不停地點擊「×」卻毫無反應，帶來的焦躁和挫敗感可想而知。

二. 整屏加載

另一類常見的加載嚴格來說不屬于模態，因為對于產品整體來說，用戶可以自由選擇執行其他操作，但對當前正在瀏覽的內容層而言卻又是一種阻斷性的加載。準確的描述應該稱為「局部模態」或者「內容層模態加載」，這里為了敘述方便，簡稱為「整屏加載」。

1.?整屏加載

原生應用的整屏加載，常見的做法是內容區整體保持空白，中間或內容區頂部有加載提示符（多數是Spinner，就是我們俗稱的轉菊花）告知用戶耐心等待，直至所有數據請求就緒，再整體展示整個頁面。

整屏加載是最簡單的一種加載處理方法，適用于頁面中所有數據，每次查看都需要重新請求、不存在本地數據的情況。在知乎、Behance、Airbnb、網易云音樂、ENJOY、熊貓直播等各類型的APP中都有廣泛應用。

整屏加載的本質是內容層的模態加載，因此和模態加載一樣，需要一個明確的超時判斷，在超過指定時間數據仍未請求成功時，告知用戶可能存在的原因和下一步行動點，避免一直卡在加載進程中。

告知加載失敗的結果時，融合一些品牌特征和情感化設計，可以有效緩解用戶加載失敗的挫敗情緒，甚至會在心底給產品設計的用心加分。

2. 瀏覽器加載

瀏覽器加載，是瀏覽器APP中最常見到的加載呈現方式——在地址欄下方以線性進度條的形式告知用戶當前加載進度。

同時，許多原生APP中也有加載Web頁面的場景。在調用內置瀏覽器內核的時候，就會自然而然地繼承很多瀏覽器的交互形式。例如微信內置的是QQ瀏覽器內核，所以在加載公眾號、朋友圈文章等Web頁面時，會在頂欄下顯示迷你進度條。

3. 為什么整屏加載不像瀏覽器加載一樣展示具體進度？

這里稍微延伸一個問題。

關于Loading的很多論述中都提到，加載提示符如果有進度提示，可以更好地讓用戶對等待時間有一個預期，有效地減輕等待的未知感和焦躁情緒。

這句話本身毫無疑問是有道理的。但我們回想一下，除了瀏覽器加載之外，無論是一個普通應用，還是以重視設計、關心用戶體驗著稱的應用中整屏加載時，為什么都很少見到帶進度信息的加載提示符，而是廣泛地使用Spinner和它各式各樣的衍生形式？

我個人的判斷是，移動端應用需要讓用戶忽略等待時間，減少具體進度帶來的壓迫，所以通常都要求速度極快（在網速正常的情況下），這種情況下進度條連看都看不清，自然沒有必要一閃而過。原生頁面的加載，通常情況下也比一個Web頁面從DOM開始加載的速度要快，所以無論于目標于能力，都不需要也不適合具體進度的展示。反觀Web頁面的加載，一方面平均耗時較長，另一方面也有繼承PC端遺留習慣的因素，所以展示進度條就成了一個不成文的慣例。

其次，告知用戶真實加載進度的愿望很美好，而現實很骨感，絕大多數情況下，資源的加載時間都是不固定且無法預知的。預先判斷需要請求的數據量并迅速折算出真實進度，對開發來說并不是一件容易的事。即使做到了，真實的加載進度實際上是「一卡一卡」非常不流暢的過程。

所以，在瀏覽器加載中，我們所看到流暢推進的進度條，多數都是假的，所以會經常出現進度條走到99%，頁面實際加載完畢還遙遙無期的情況。

瀏覽器的進度判斷是通過監聽加載狀態實現的。而在大量結構標簽和內容數據的加載中，只有為數不多的節點會有事件產生，最容易想到的自然是開始和結束兩個節點。很多情況下，會在DNS解析和資源下載完成時就讓進度條跑到90%甚至99%，但后續的加載過程有時遠比下載過程更耗時，所以卡節點的情況在所難免。

這里補充一個設計上的小技巧，兩個節點之間同樣的進度條，相比勻速前進、按真實節點前進，先快后慢地前進能讓用戶產生加載更快的錯覺。雖然是種假象，但用戶需要的就是這樣的假象。

三. 非模態加載

1.?標題欄加載

IM、郵箱這類應用在內容加載上特點非常鮮明。首先，這類應用的大量數據都是存在本地的；其次，本地數據的瀏覽在任何情況下都不應該受制于網絡速度。試想，沒信號的時候連歷史聊天記錄都看不了是一件多么可怕的事情。

因此，在這類應用中通常會在頂欄（也有在底欄）顯示加載提示符（通常是以文字+Spinner的形式），這里簡稱為標題欄加載。這種方式的優勢在于不妨礙用戶在內容區點擊查看任何已有消息。

2. 遞進加載

預先設計整體的內容加載順序，可以讓核心信息優先被加載出來，讓用戶知道任務正在持續進行的同時，通過優先加載的內容吸引用戶注意力，緩解等待的焦躁感。

多數情況下，所有的整屏加載都可以通過合理的設計優化為遞進加載。當然，有些頁面有整體性要求（如金融類APP中的各類表單），所有信息一定要整體顯示、否則會導致歧義，這種情況自然不適合采用遞進的方式。

A. 文字+占位符優先

同時，對首頁各類分流List、Timeline來說，及早透出的文字內容吸引用戶興趣，有可能在頁面完整加載前就完成導流的任務。而在此期間用戶進行判斷的思考，則更加淡化了他們等待的感覺。

比如電商平臺ZOZOTOWN預先加載的價格和打折標，就可以讓用戶在加載過程中，根據自己心里預設的價格區間和折扣期望，進行基本的判斷和篩選。

根據內容資源性價比（資源傳達的信息價值÷資源體積），最先考慮加載的自然是文字，而圖片、動圖、視頻在此期間則用占位符表示。最簡單的占位符就是一個純色塊，用于讓用戶對即將呈現的內容尺寸有一個基本的心理預期。

占位符上可以通過icon告知用戶資源類型是圖片和視頻，也可以借此展示產品或品牌的標志性icon。

B. 低清圖片優先

圖片資源的分級加載可以讓這一過程更加平滑，首先加載低清版（甚至模糊版）的縮略圖，在保證內容完整呈現后，再加載高清資源。

同理，占位符的色值直接選取圖片的主色值也是一個有效的過渡手段。

C. 結構占位符優先

遞進加載的思路不限于信息資源，結構元素同樣可以考慮遞進加載。

在文字加載之前，預先將結構占位符（Skeleton Screen，直譯是「骨骼頁」）顯示出來，可以從形到體地提前告知用戶接下來將要看到的東西，避免加載中的大忌——「驚喜感」，讓加載過程更加自然。

結構占位符一般是類似于線框圖形式的灰階色塊圖，將各個模塊的典型結構元素展示出來，通常不代表真實情況——這意味著無法點擊，所以實際上在這一階段仍然類似整屏加載。但結構占位符的核心目的也不是真實內容，而是銜接空白和載入成功的狀態。簡述和抖音的消息頁都采用了結構占位符作為遞進加載的中間態。

這樣非功能性的優化或許很多開發并不愿意去做，但對微小細節的用心，可以讓整個產品體驗的順滑程度、品質感都提高很多。用戶的眼睛是雪亮的，隨之而來口碑上的收獲會讓團隊覺得付出都是值得的。

D. 業務優先

此外，還可以綜合考慮資源體積和模塊價值，可以考慮不按從上到下的順序，而是對業務目標最有利的模塊順序加載資源。

四. 啟動加載

討論了很多應用內頁面的加載，再單獨把啟動加載拎出來聊聊。

1.?空白框架加載

國外許多APP都采用了非常輕的啟動頁，首先展示一張與實際首頁的結構非常近似的空白框架作為啟動頁，在此基礎上加載框架內的具體元素。讓用戶在點擊APP后就有一種「馬上就啟動了」的錯覺。iOS的自帶應用中這樣的例子比比皆是，這正是iOS規范所建議的一種啟動方式。

更加用心的一些產品，在此基礎上設計了更細分的遞進加載過程。在加載空白框架的基礎上，首先加載全局性元素（頂欄、底欄），最后加載中間內容層的具體內容。

如家裝社區Houzz，首先加載的是由頂欄、底欄構成的空白框架，其中頂欄已經預先透出了用戶頭像和搜索框的占位符；第二步加載了頂欄、二級頂欄和底欄的icon、搜索框等全局性元素。第三步才開始加載內容區。

體育直播平臺ESPN也同樣采用了這樣的三步啟動，首先加載只有底欄的空白框架，由于ESPN的產品框架會根據用戶關注的國家不同而有較大差異，頂欄結構和底部Tab會完全不同，所以在第二步請求到用戶關注的國家后，才會依次加載底欄Tab、頂欄和內容區。

當然也并非所有的國外APP都認可iOS這一套極簡的加載過程，商業環境下，品牌表達的訴求是天經地義。在Airbnb、Instagram等公認設計比較優秀的APP中，他們的做法是在空白框架的基礎上，很克制地打上很輕的品牌標識。從而在強化品牌心智的同時，仍然保證主體內容是在空白框架上自然呈現的。

個人角度還是蠻喜歡這種更純粹的啟動方式的，可惜國內的APP由于習慣問題，采用空白框架加載的例子少之又少。

2.?啟動頁

國外也有許多APP選擇設計與首頁結構框架無關、獨立的啟動頁，以實現更為強勢的品牌透出，比如食譜平臺Yummly和閱讀推薦平臺Medium，都設計了與首頁框架無關的啟動頁，極具辨識度且不會輕易更換。

這點上，國內最好的例子就是微信，「孤獨遙望地球」的畫面使用之久、辨識度之高，僅僅是地球照片換成國產就能引發全網熱議?！高@個世界是孤獨的」的故事，即使沒有slogan寫在啟動頁上，也早已深入人心。同樣，網易云音樂和其他一些APP的啟動頁也在品牌認知效果上做得不錯。

相比之下，滴滴、B站、豆瓣等許多國內APP的啟動頁采用了更簡化的做法——白屏+底部LOGO，通常會以小字體附上slogan或者版權信息。

關于這種設計的判斷見仁見智，可以認為它是一種品牌宣導與「不打擾用戶」的折中。但我仍然保留個人觀點，在這一問題上的折中，可能導致兩頭不討好。

對用戶體驗，這種設計不像空白框架加載一樣有一個銜接非常自然的啟動體驗。

對品牌曝光，又不像微信啟動頁一樣具有極強的品牌認知價值。

在底部放一個小LOGO，難道用戶點擊APP時沒看到么，為什么一定要以進入APP的體驗流暢度為代價去讓用戶再看一遍？

至于一閃而過的slogan或是版權信息，字體非常小的情況下連看都看不清，其實有多少用戶會留意到呢。

簡而言之，既然要設了一道屏障，為什么不讓這個屏障更有價值？

3.?一言難盡的廣告頁

國內APP還有一個似乎約定俗成的習慣——在啟動頁后插入廣告，甚至直接把廣告作為啟動頁，雖然多數都在角落提供了跳過的選項，但仍然有可能會引起用戶的反感甚至流失。

不可否認這是價值不菲的一個黃金廣告位，尤其當這種做法無論對產品方還是用戶都已經司空見慣的時候，似乎體驗上的風險也就沒那么大了。

所以，這里不再去糾結國外APP的做法與「國情」之間的優劣。還是那句話，用戶體驗也是植根于市場和文化習慣的。

在這樣的背景下，設計師可以體現價值的地方，應該在于去思考怎么把啟動廣告做得不那么讓人反感，甚至用精良的設計給用戶帶來獨特的期待。

五. 提升加載體驗的其他技巧

1.?加載提示符的設計

線上線下的服務設計很多地方是相通的。

在以服務著稱的海底撈，我們排號等待期間并不會覺得時間特別漫長。首先，海底撈會提供小吃、酸梅湯，甚至美甲、陪客人下棋等服務，讓我們感受到商家已經充分考慮到了排號的痛苦、并為此提供了體貼的關懷。其次（這點不單指海底撈），叫號機頻繁報號也讓我們對「前面還有多少桌」始終心中有數。

線上APP的等待過程也同樣如此。

精心設計的加載過程可以有效緩解等待的壓力。無論是在線型進度條、Spinner上融合品牌特色做出種種新意，還是結合產品調性嘗試更富創意的動效，總比千篇一律的轉菊花或者單調的文字，更能讓用戶感受到我們對加載等待過程的充分考慮和設計上的用心。

例如廚房故事APP在加載中使用的Spinner，就巧妙地結合了LOGO中黃色圓點，設計了一個節奏和靈動感俱佳的Spinner。熊貓直播屏幕中央賣力跳動的小熊貓，配合「賣力加載中」的文案，能博得用戶會心一笑，就為加載多爭取了幾秒安全時間。

其次，認真為等待過程配上準確的文案，告知用戶他所處的具體處境和階段，就像排隊聽到報號一樣，離結果更近一步，就對等待下去多了一份堅定。

例如一個很經典的例子——Yummly的新手引導流程中，經過多次偏好選擇后，會有一個「體驗個性化（Personalizing Your Experience）」的計算過程，加載中，會實時地告訴用戶目前處于8個步驟中的哪一步，icon顏色順時針逐一變化的同時，下方文案會提示用戶這一步具體在做什么，比如「正在檢測你的時區、正在合并賬戶信息」等。這讓用戶感覺到終點并不遙遠，進度在自己的掌控之中，并且對當前步驟對自己的價值心里有數。

編者注：更多優秀案例右戳《讓等待也成為享受！18個讀取進度條的優秀設計案例》

2. 內容秒發

以簡書為例，在內容發布類流程中，傳統的設計是在點擊「發布」后進行模態的發布進度確認，直至監聽到完整發布的事件，再進入發布成功的頁面。

而微信朋友圈的做法是，無論是點贊、評論還是發布一條朋友圈，都在點擊后「瞬間加載」，立刻呈現出假設用戶已經發布成功后的狀態，無需用戶陪同服務器一起等待整個數據傳輸和返回過程。

當然，留心一下可以發現，這種「假完成」狀態下，還沒有真正發布成功的朋友圈是無法評論和點贊的。

這一做法讓用戶很自然地覺得：哇，在朋友圈發東西好流暢！即使這只是一種假象，但就像瀏覽器加載中的進度條一樣，有時用戶正是需要這種假象。

相應的風險很容易想到，就是容易出現用戶誤以為已經發出的內容，實際上沒有發送成功。這就要求在采用這種做法的同時，一定要在超時發送失敗時，用最醒目的方式告知用戶發送失敗。

總結

不可逆流程適合采用模態加載，注意要同時提供取消按鈕。
已有本地數據的IM、郵箱類應用適合采用標題欄加載，而每次打開都要重新請求數據的頁面適用于整屏加載。
Web頁面采用瀏覽器加載，顯示迷你進度條，建議先快后慢，可以讓等待時間“顯得”更短。
除了頁面上所有信息一定要整體顯示否則會導致歧義的情況，多數情況下遞進加載的體驗優于整屏加載。先文后圖，先占位符后圖，先色塊后圖，先模糊后高清，先“骨骼圖”后真實內容……都是可以考慮使用的遞進方式。
內容發布類流程可以通過直接呈現發布成功的狀態，制造極速發布的“秒發”假象，但記得在失敗時醒目地告知用戶。
讓用戶感受到產品用心程度，告知用戶所處的具體階段，都是加載提示符可以貢獻的設計價值。
除非有明確的理由，盡量避免在啟動時的數據請求中使用模態加載。
iOS規范推薦的空白框架加載是一種很棒的啟動加載方式，無論是兩步還是三步。但國內環境下，也許獨立的啟動頁在一段時間內仍然是主流。
一個全屏、品牌辨識度極高且不輕易更換的啟動頁，能最大限度地發揮啟動頁的價值。在啟動體驗和品牌曝光的問題上，折中的效果可能未必理想。

歡迎關注作者的微信公眾號：西市饅頭鋪子

方法+實例！如何做好移動應用中的Loading設計？