自互聯(lián)網(wǎng)誕生以來(lái)，我們的網(wǎng)速一直在進(jìn)步，但對(duì)于用戶而言，經(jīng)常會(huì)需要等待系統(tǒng)加載過(guò)程完成，若等待的體驗(yàn)沒有處理好，產(chǎn)品很難迎來(lái)好口碑。本文對(duì)常見的幾個(gè)等待場(chǎng)景，看看如何處理用戶等待這件“小事”。

下圖是從1990年代到未來(lái)6G時(shí)代的一個(gè)網(wǎng)速變化，可以看到，自互聯(lián)網(wǎng)誕生以來(lái)，我們的網(wǎng)速一直在飛速提升。然而，現(xiàn)實(shí)給用戶感受到的網(wǎng)速卻并沒有那么快 —— 用戶經(jīng)常會(huì)需要等待系統(tǒng)加載過(guò)程完成。導(dǎo)致這種情況出現(xiàn)的原因有以下三個(gè)方面：

1. 系統(tǒng)的服務(wù)器對(duì)外帶寬比較?。涸茝S商的帶寬資源是一種稀缺資源，因此帶寬越大費(fèi)用越高。從運(yùn)營(yíng)成本考慮，不會(huì)選擇過(guò)大的帶寬。除了那些視頻類的服務(wù)器之外，大部分業(yè)務(wù)系統(tǒng)，尤其是SaaS系統(tǒng)的服務(wù)器對(duì)外帶寬都不高。
2. 服務(wù)端應(yīng)用處理業(yè)務(wù)的時(shí)間比較久：服務(wù)端需要從數(shù)據(jù)庫(kù)讀取或?qū)懭霐?shù)據(jù)，通常數(shù)據(jù)庫(kù)數(shù)據(jù)量越大，讀取或?qū)懭霐?shù)據(jù)的時(shí)間就越久。
3. 用戶網(wǎng)絡(luò)帶寬不足：用戶端的網(wǎng)絡(luò)帶寬不足同樣會(huì)影響實(shí)際的系統(tǒng)加載快慢。

現(xiàn)在看來(lái)，這種情況還會(huì)持續(xù)很長(zhǎng)時(shí)間。如果等待過(guò)程體驗(yàn)不好，對(duì)于新用戶，很可能會(huì)直接放棄；而老用戶，則會(huì)被每天等待的過(guò)程弄得心煩氣躁，產(chǎn)品自然也很難贏得好的口碑。因此產(chǎn)品設(shè)計(jì)時(shí)就需要考慮如何讓用戶等待的過(guò)程沒那么糟糕，如果能夠帶來(lái)一點(diǎn)愉悅感那就更好了。本篇我們就對(duì)常見的幾個(gè)等待場(chǎng)景，看看如何處理用戶等待這件“小事”。

一、提交過(guò)程

提交表單（包括添加、修改）是SaaS產(chǎn)品用戶頻次最高的操作，我們經(jīng)常會(huì)發(fā)現(xiàn)設(shè)計(jì)得不好的提交過(guò)程會(huì)出現(xiàn)下面這種情況。

用戶點(diǎn)擊提交后沒有提交過(guò)程指示，用戶不知道自己提交了沒有，細(xì)心的用戶會(huì)回列表去看一下確認(rèn)，缺乏耐心的用戶則要不直接再次點(diǎn)擊提交，甚至是多次提交。結(jié)果產(chǎn)生重復(fù)數(shù)據(jù)，用戶不得不進(jìn)行刪除操作。

比如下面的動(dòng)圖里，可以看到，點(diǎn)擊提交按鈕后沒有任何反饋，如果等待時(shí)間稍微長(zhǎng)一點(diǎn)，用戶就會(huì)懷疑自己是不是沒點(diǎn)上，然后就會(huì)重復(fù)點(diǎn)擊提交。

這里其實(shí)就是違反了尼爾森十大交互原則中的“可見性原則”，沒有給用戶的操作及時(shí)有效、看得見的反饋。怎么樣算是一個(gè)比較好的提交過(guò)程體驗(yàn)?zāi)兀覀儊?lái)看下面的例子。

這是我們之前拆解的SageHR的手機(jī)端提交的過(guò)程，他們?cè)诘却倪^(guò)程中，給出了一個(gè)有趣的動(dòng)畫，讓整個(gè)等待過(guò)程更加愉悅。同時(shí)，在操作成功后給出了明確的文案告知用戶操作已經(jīng)完成。這就是一種愉悅的用戶體驗(yàn)。

二、頁(yè)面加載過(guò)程

在體驗(yàn)一些設(shè)計(jì)非常糟糕的產(chǎn)品時(shí)，我們經(jīng)常會(huì)遇到下面兩種情況：

1. 進(jìn)入新頁(yè)面后，整個(gè)平面都是白的，沒有任何提示，也不知道是網(wǎng)絡(luò)問題還是軟件出了故障。
2. 頁(yè)面有圖片時(shí)，在圖片沒有加載出來(lái)前，圖片的位置是一片空白。

對(duì)于進(jìn)入新頁(yè)面的加載過(guò)程，最簡(jiǎn)單的提示就是給一個(gè)“加載中”的動(dòng)畫提示，告訴用戶當(dāng)前正在加載。更好的體驗(yàn)是給出有趣的動(dòng)畫加載過(guò)程，比如下面這種，碰到加載慢的時(shí)候，看個(gè)3-5秒也不會(huì)覺得無(wú)聊。

也有一些結(jié)合產(chǎn)品自身特色的加載動(dòng)畫，比如網(wǎng)易云音樂的加載動(dòng)畫用的是一個(gè)播放頻譜振蕩的效果。

對(duì)于有圖片加載的情形，基礎(chǔ)的體驗(yàn)是給出一個(gè)占位圖片，讓用戶能夠在加載前就知道這個(gè)區(qū)域會(huì)是一張圖片。當(dāng)然，用骨架屏的加載指示體驗(yàn)會(huì)更好，用戶一看到骨架屏就知道加載后的界面大致布局。比如從美團(tuán)進(jìn)入到外賣頻道就使用了骨架屏的加載指示方式。

三、下載與導(dǎo)出過(guò)程

在Web端，通常文件的下載都是直接交給瀏覽器處理，也就是下面這種效果。所以PC端文件下載體驗(yàn)基本都是一致的。

對(duì)于移動(dòng)端來(lái)說(shuō)，下載過(guò)程需要自己控制，因此給出下載進(jìn)度指示是非常必要的。通常會(huì)使用進(jìn)度條的方式指示文件的下載進(jìn)度。

實(shí)際上，影響下載體驗(yàn)更多的不是下載過(guò)程，而是我們準(zhǔn)備下載文件的過(guò)程有時(shí)候也會(huì)比較久，典型的就是SaaS產(chǎn)品的導(dǎo)出的過(guò)程。當(dāng)涉及得數(shù)據(jù)比較多的時(shí)候，往往會(huì)需要較長(zhǎng)的時(shí)間。我曾經(jīng)見過(guò)一個(gè)糟糕的設(shè)計(jì)是，用戶點(diǎn)擊下載后，整個(gè)處理數(shù)據(jù)的過(guò)程會(huì)超過(guò)30秒，而且用戶在這個(gè)過(guò)程中不能關(guān)閉當(dāng)前頁(yè)面，一直得等著。即便是一個(gè)耗時(shí)久的操作，如果讓用戶等待超過(guò)了10秒，用戶也是難以忍耐的。然而，有時(shí)候確實(shí)處理數(shù)據(jù)耗時(shí)就是需要很久，怎么辦呢？這個(gè)時(shí)候就要引入異步處理機(jī)制了。

異步處理機(jī)制其實(shí)將導(dǎo)出行為和導(dǎo)出結(jié)果分開，用戶進(jìn)行了導(dǎo)出操作后，不需要等待導(dǎo)出結(jié)果，而是可以先去處理別的工作。然后，隨時(shí)可以到導(dǎo)出結(jié)果處理任務(wù)中查看數(shù)據(jù)是否導(dǎo)出。整個(gè)邏輯如下圖所示。

異步處理過(guò)程，影響體驗(yàn)的一個(gè)關(guān)鍵環(huán)節(jié)是用戶如何知道導(dǎo)出已經(jīng)完成。簡(jiǎn)單的做法是給每個(gè)人一個(gè)導(dǎo)出任務(wù)列表入口，然后用戶自己去查。這種方式的話，用戶可能經(jīng)常需要刷新來(lái)看導(dǎo)出是否完成。

實(shí)際上，這種體驗(yàn)還不夠好，更好的方式是在這個(gè)基礎(chǔ)上，再增加導(dǎo)出操作完成后主動(dòng)通知用戶。比如通過(guò)App推送消息、郵件、釘釘消息、微信模板消息、短信提醒等方式進(jìn)行提醒。具體哪種方式，取決于哪種方式能夠讓用戶更方便及時(shí)地得到反饋。這樣的話，用戶可以自己主動(dòng)去導(dǎo)出任務(wù)列表查看，也可以等待系統(tǒng)的導(dǎo)出成功通知。

總結(jié)

我自己曾經(jīng)遇到過(guò)很多產(chǎn)品，打開第一個(gè)界面就想放棄，原因就是加載的時(shí)候給一個(gè)空白屏幕，碰到網(wǎng)絡(luò)不好干脆一直處于這種狀態(tài)，用戶沒法知道當(dāng)前的狀態(tài)，體驗(yàn)非常糟糕。這種產(chǎn)品往往是產(chǎn)品設(shè)計(jì)時(shí)沒有注重細(xì)節(jié)導(dǎo)致的、或者是他們想當(dāng)然地認(rèn)為大家網(wǎng)絡(luò)都會(huì)像在辦公室里那樣快。

實(shí)際上，加載過(guò)程的交互體驗(yàn)我們只需要和UI/UX、開發(fā)人員約定好我們列舉的這些場(chǎng)景，統(tǒng)一加載過(guò)程的指示就能夠避免這種問題了?！坝脩舻却睂?duì)產(chǎn)品設(shè)計(jì)看似是一件小事，但對(duì)用戶體驗(yàn)來(lái)說(shuō)，卻是一件大事 — 因?yàn)樗麄兠刻於紩?huì)遇到幾十上百次的加載過(guò)程。