特殊情況下的APP設計(6):交互走查表
本文作者將用交互走查表的形式,對系列文章“特殊情況下的APP設計”進行一個總結。enjoy~
你如果已經在做設計,肯定會遇到這種情況:在開設計評審會的時候,開發或者QA總能找到設計方案中遺漏的點。出現這種問題的原因并不是因為缺少知識,而是因為有時候要考慮的情況太多,難免會遇到遺漏的情況。而建立一個適合自身產品的交互走查表,會盡可能的減少遺漏的情況。
經過前面幾篇“特殊情況下的APP設計”相關文章的介紹,已經把在APP設計中,和主業務不太相關的特殊情況下的APP設計點介紹的差不多,還沒看過的小伙伴,可以系統地看一遍,希望能對你有用。今天,就用交互走查表的形式,對這個系列的文章進行一個總結。
交互走查表
1. 網絡異常
頁面有緩存數據時
頁面有緩存數據時要考慮兩種情況:
- 網絡環境切換時(從WIFI到蜂窩數據;從蜂窩數據到WIFI),解決方案是“暫停播放并dialog提示”。
- 網絡異常時,解決方案有兩種,一是Toast提示;二是常駐list提示。
頁面無緩存數據時
這種情況下,要有點擊頁面重新加載的功能,有些APP是提供重新加載的button,有些是點擊空白頁面任意區域都會觸發重新加載,另外,還有很多APP會提供前往設置WIFI的入口。
2. 缺省頁面
有頁面框架時
顯示頁面框架+占位符;
無頁面框架時
盡量采用情感化設計,同時可以引導用戶去看推薦內容。
3. 加載刷新
頁面有緩存數據時
(1)設計加載loading;
(2)考慮加載失敗的情況,加載失敗可分為網絡原因和其他原因。一般會采用Toast提示。
頁面無緩存數據時
(1)設計加載loading;
(2)考慮加載失敗的情況,加載失敗可分為網絡原因和其他原因。一般會進行情感化設計。
下拉刷新
設計下拉刷新動畫,每次刷新可以給予Toast反饋,例如豆瓣首頁,每次刷新都會提示更新了多少條;如果當前內容已經是最新,可以提示用戶已經是最新內容。
分段加載
因為客戶端不可能一次性加載全部內容,得進行分段加載,規定每次加載多少條,像今日頭條APP,我沒記錯的話應該是每次會加載60條數據。
分布加載
考慮分布加載,先加載文字,后加載圖片,如果頁面有框架,會最先出現頁面框架,再顯示文字和圖片。由于加載圖片時間稍長,所以在加載圖片過程中會用一個默認的占位符來填充圖片位置。
異步加載
為了減少用戶等待時間,可以考慮需不需要采用異步加載。
智能加載
根據產品自身的特性,考慮是否分網絡環境來加載不同內容。例如知乎APP,在設置中可以選擇蜂窩環境下只加載文字不加載圖片,幫助用戶節約流量。
4. 其他情況
- 是否支持游客模式
- APP啟動頁面的設計
- token失效時
- 服務器異常時
不同產品根據自身的特點,需要走查的點是不一樣的,例如:涉及多媒體播放和下載的產品,才需要考慮網絡環境切換時的情況;必須強制登錄的產品就不需要考慮游客模式的設計,等等。
《清單革命》這本書將人類所犯的錯分為兩類,一類是無知之錯;另一類是無能之錯。無知之錯是因為缺少相關的知識所犯的錯誤,而無能之錯并非因為沒有掌握正確的知識,而是因為沒有正確的使用這些知識。而交互走查表(清單)的建立,會減少我們犯無能之錯的概率。
相關閱讀
#專欄作家#
鄒志楠,微信公眾號:鄒志楠,人人都是產品經理專欄作家。用戶體驗設計師,專注于互聯網產品設計。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 攝圖網,基于 CC0 協議
贊!很全面的說明,學習了~~
贊