體驗提升設計清單：加載、刷新和缺省頁
產品中某些模塊，不用於滿足業務或功能，但因爲觸發場景多、操作高頻、性能相關，是每個產品必須有設計。基本業務需求滿足之後，優化這些模塊，可提升體驗，增加操作效率。以下總結加載、刷新、缺省頁的常用設計模式，亦可作爲自檢清單。
刷新
刷新場景
- 用戶主動試探是否新內容
- 確定有新內容（比如微博頂部提示），按引導操作獲取
- 網絡異常，按引導操作刷新
是否提示內容更新
- 無更新提示：產品打開頻率高，內容會經常更新、不按時間順序瀏覽內容、或不依靠feed流更新推送，比如新聞類產品
- 有更新提示：產品打開頻率低，無法預知是否有新內容、重視feed流更新推送；比如FM類產品
控件觸發位置
- 頁面下拉時頂端觸發
- 空數據頁面點擊按鈕或輕觸屏幕
- hud或浮層提示點擊
- 自動刷新，比如微信朋友圈，先讀取緩存內容，自動請求服務器，左上角七彩轉盤加載動效
不同類型UI，分別適用哪種觸發刷新的方式？刷新控件展示在UI上，UI決定刷新位置，位置決定觸發方式
- 列表、柵格列表、卡片、內容流、瀑布流：下拉或上滑刷新
- 系統插件、地圖應用：因爲沒有排序方向、新內容生成位置不明確，用戶無法憑直覺做出手勢觸發刷新；適合自動刷新
- 個人中心、設置：內容並不經常更新，無需主動操作；自動更新
- 更新頻率高的內容：股票、財經類，最好實時自動更新
- 網絡異常缺省頁：引導用戶主動做出手勢，操作刷新
刷新樣式
- 導航欄：列表存在本地數據、內容頁不爲空，用戶注意力集中在已有內容，無需突出刷新過程，所以loading控件放在頂部導航欄，比如釘釘、微信
- 進度條：頁面包裹H5時刷新，內置瀏覽器標準加載方式
- toast：常見於屏幕中間轉圈，因爲某些頁面有其他操作項，防止繼續操作導致數據丟失，所以使用toast提示，防止誤操作
- 下拉刷新：往往在頂部下拉出的空間加上動效，往往和刷新成功後提示一起使用，保證了用戶保持注意本地數據，也充分感知有新內容加載好
- 整屏動效刷新：整屏爲空，中央加載動效，一般取產品主色爲背景。可以從三個方向考慮UI動效
- 品牌，產品的宗旨或目標或口號
- 引起共鳴佔位圖和文案
- 直接告訴用戶正在發生什麼
加載
和刷新類似的是加載，在此定義爲首次進入某個頁面或觸發控件，請求服務器的狀態。加載樣式有以下幾種：
- 導航欄：同刷新樣式中的導航欄
- 進度條：同刷新樣式中的進度條
- toast：同刷新樣式中的toast
- 整屏動效加載：同刷新樣式的整屏動效
除了和刷新一樣的樣式，加載狀態還有兩種樣式可用：
- Skeleton: 如facebook，先加載出頁面框架，再展示數據內容。
- 有研究發現Skeleton讓人感覺加載速度更快，即使加載時間沒有變化
- 不是每個頁面都要這種效果，如果打開頻度不高，或不請求網絡數據，不需要此加載效果
- Shimmer：翻譯成微光，動效和Skeleton類似，只是整屏閃爍，更重口味
根據不同界面，加載機制和樣式可以不同，比如個人中心頁面可以自動刷新甚至不刷新，列表頁面可以下拉刷新，並且在下拉出的屏幕空間添加佔位圖/動效，有很多發揮空間，以突出品牌形象。
- 無本地框架的頁面，整個頁面需要請求數據：適合整屏動效加載、比如白屏中間轉圈或佔位動畫
- 有本地框架或數據緩存，如個人中心、聊天列表：適合導航欄加載方式，因爲只有部分數據需要請求網絡，所以優先展示框架或本地數據，加載佔位的面積小，退居次要關注點，不覆蓋已有頁面
- 當前整屏數據已加載，新操作請求服務器，但新數據還未覆蓋原有頁面：適合toast加載，讓用戶感知頁面正在切換
同一個頁面，加載和刷新可以用兩種樣式；比如微信聊天列表，加載控件在導航欄，刷新控件是實時自動；簡書加載用Skeleton，刷新用下拉方式。
加載的後臺增強設計。爲了減少等待時間，提升體驗，往往不會一次加載完所有數據才展示
- 分步加載：比如先文字再圖片、先框架/預設圖再框架內數據
- 預加載：先加載最先要看到的內容，再根據用戶行爲習慣預判後續想看內容，提前加載好；比如閱讀App，閱讀當前頁時自動加載後幾頁
- 異步加載：比如某App網絡不好時點贊，本地提示用戶點贊成功，網絡好時再請求到服務器，完成點贊數據交互
加載的最大時間。加載狀態，不管是動效、hud、toast，不宜過久。再好看的動畫也不意味着可以無限等待，應該控制在5-10s以內。加載時後臺重連幾次、每次加載多久timeout，和性能有關，與開發商定一個合適解決方案。
缺省頁
缺省頁有三種，空數據、網絡異常、頁面報錯。後兩者爲異常情況處理。
空數據
空數據頁面，沒太多後續操作，一般是搜索結果列表爲空、無數據交互頁面狀態，可以做以下設計
- 擺放活潑友好的空數據佔位圖和文案
- 展示運營推薦元素，比如推薦商品和文章，引導瀏覽更多
- 留有call to action的入口或按鈕，告訴用戶，你想要這個頁面有數據，該怎麼做
- 頁面有框架，需展示數字時，比如股票、錢包，如果是實際數額爲0，可用 ‘-’ 代替
網絡異常
請求服務器失敗，常見於斷網、網絡不穩定。這個場景若發生，在某些主路徑頁面，提升體驗最好方案是事先預防：預先緩存內容到本地，對於內容不常變化的頁面，寫死UI框架到本地。網絡異常發生時，可採取的補救機制：
頁面有本地緩存，頂部hud提示，不佔據內容空間，可以在瀏覽緩存內容同時，知道網絡異常。從Hud可點擊進入“指導檢查網絡頁面”，該頁面爲靜態頁面，用文案指導如何檢查wifi或移動網絡。另外一種方案爲，從hud點擊直接進入手機“系統設置”頁面，期待熟練用戶自己檢查WIFI或移動網絡。微信、京東用靜態頁面的文案指導檢查網絡，而非直接跳轉系統設置，因爲直接跳轉到系統設置，會讓很多小白茫然無措，加之不同手機系統，可跳轉的權限不同。用靜態頁面指導，是更簡潔通用、覆蓋更多人羣的方案。
頁面無本地緩存，使用網絡異常佔位符，與空數據頁面類似，擺放活潑友好的網絡異常佔位圖和文案。此類頁面又分兩種情況來佈局：
- 頁面有下拉刷新：文案提示用下拉手勢刷新 + 指導檢查網絡狀態入口
- 頁面無下拉刷新：文案提示輕觸屏幕或點擊按鈕刷新 + 刷新按鈕 + 指導檢查網絡狀態入口
另外，還需考慮網絡異常提示的時機。如果網絡狀態經常不穩定，一監聽到斷網就提示異常，反反覆覆太頻繁，可以考慮延時反饋，比如監聽到網絡異常5s之後，給出提示；5s內如果鏈接上了，不提示。
頁面報錯
在PC網頁，瀏覽器提示404、或頁面不存在，可操作瀏覽器刷新按鈕重新請求或返回上一層。在App中，頁面定製化程度更高，加之報錯不是刷新或檢查網絡可以解決，像瀏覽器默認那般提示404之類錯誤碼，不如突出友好活潑的佔位圖，並引導用戶主動反饋或探索更多其他內容。