系統應該讓用戶時刻清楚當前發生了什麼事情，也就是快速的讓用戶瞭解自己處於何種狀態、對過去發生、當前目標、以及對未來去向有所瞭解，一般的方法是在合適的時間給用戶適當的反饋，防止用戶使用出現錯誤。
我們知道，用戶在和頁面發生交互時會遇到各種狀態，此時需要通過一定的界面反饋將信息反饋給用戶，“反饋”是人機交互最重要的原則，無論是視覺（界面變化）、聽覺（聲音提醒）、觸覺（震動），都可以幫助用戶理解自己所在頁面的狀態及接下來會發生了什麼、怎麼做。
其實討論“狀態可見原則”就是討論如何把“反饋”設計得更合理。下面我從產品常見的幾大異常狀態切入，討論出現異常狀態時對應的解決方案，讓錯誤狀態“可見”。
目前主要整理了以下常見9種異常，以後會不間斷補充：
- 網絡異常
- 空狀態
- 服務器異常
- 流量模式警告
- 版本不兼容
- 操作失敗
- 無權限
- 功能建設狀態
- 內容刪除、違規導致的查看異常
一、網絡異常狀態提示
當設備丟失網絡連接時，導致網頁/APP無法傳輸數據導致的異常狀態。網絡異常通常有兩種觸發場景：
- 自動觸發：斷網後，用戶進入軟件時，程序檢測到無網絡，自動提示
- 被動觸發：斷網時用戶在軟件內操作，系統被動觸發無網絡提醒
在無網絡的情況下打開APP時頁面需要刷新，此時需要提醒用戶網絡問題，常見的提醒方式有如下四種，分別適合於不同的應用場景：
對於這幾種提示類型，除了本篇討論的斷網提示之外，還有很多的其它的應用場景，如操作提示、進度提醒、程序提醒等。我們來看下各種提示形式的特點及應用場景。
1. 缺省頁面提示
在內容更新頻繁的內容型產品（如視頻、帖子動態類）中常用缺省頁的形式表現無網絡狀態，直接明瞭，附有個性化插圖及提示文案，同時帶有【刷新】或者【解決方案】入口，引導用戶點擊查看原因解決問題。
2. tips提示
tips提示常見於頁面頂部或者底部固定，更適用於於信息列表類頁面，如圖示的釘釘及微信等，採用tips的形式，樣式上與列表形式更接近、和諧統一。點擊後可以跳轉系統設置或幫助頁面。
3. toast提示類
toast（不帶交互性）
toast提示的特點是彈出後自動消失（一般至少為1s），視覺層級高，能夠吸引用戶的注意力。消失後用戶可以在軟件中繼續其它點擊動作。但是由於存在時間短，容易被用戶忽視，所以一般不會放置過多文字和重要信息。
此種方式很適合比較用於有不需要聯網即可查看/使用部分功能內容（緩存）的產品中，比如網易雲音樂，無網絡時仍然可以選擇聽本地歌曲。
表現形式上，toast出現的位置以中、上為主，因為它的出現是在動作之後，所以位置不能偏離動作發生位置過多，以免造成視覺的跳躍感。
Snackbars（帶交互性）
Material Design（Android）中有一個與常見Toast類似的提示–Snackbars，是一種針對操作的輕量級反饋機制，一般在頁面下方浮出，在該頁面層級最高，同樣在一定時間後自動消失。
與toast最大的區別是允許用戶交互，用戶可以手動點擊頁面其它地方或手動滑動關閉snackbars，有時也會帶有操作按鈕，提供繼續或撤銷功能。
Snackbars使用原則：
Snackbars演示示例：
有興趣的同學可以去matreia design官網瞭解snackbars https://www.material.io/components/snackbars/#anatomy
4. 模態彈窗（Alert）
模態彈窗打斷用戶的操作，用於提供重要信息或者要求用戶決策。出現時會禁用所有的應用程序功能，並且一直顯示在屏幕上，直到用戶選擇確認、關閉或已採取必要措施為止。但由於會打斷用戶，所以要謹慎使用。
模態彈窗的使用原則：
因此模態彈窗更適用於以下兩種情景：
- 阻止應用正常運行的錯誤
- 需要特定用戶任務，決策或確認的關鍵信息
網絡異常反饋形式總結：
- 對於不同情景下的網絡異常提示，我們需要區別考慮，選用最優的狀態反饋方式，我認為有以下幾點在之後的設計中可以運用：
- 對於一般的列表消息類的APP，採用相對簡單、與整體列表和諧的tips提示，可以加入跳轉邏輯，如引導用戶查看幫助等
- 對於內容類產品，經常需要刷新頁面讀取最新動態內容的產品，採用toast提示，一般存在1-2s，需要注意不要放置過多文字
- toast的延伸類型snackbars可以加入按鈕、拖拽關閉等，比常規toast更具備交互性，可以用於向用戶展示一些比基礎的正確/錯誤反饋稍重要些的提示
- 除非重要信息提醒/緊急情況，慎用/不用模態彈窗
二、空狀態提示
由於空狀態沒有實質性的頁面內容，所以需要反饋給用戶相關信息去添加或重新提交數據請求。
一般來說，我們說的空狀態有兩種觸發場景：
1. 需要用戶主動添加信息的空狀態
此類空狀態一般有時會通過文案提示引導用戶創建內容，如上圖中的“下廚房”APP，利用了俏皮文案加操作指引的方式引導用戶創建菜譜。
設計形式上需要注意：遵循產品整體風格、文案+插圖的形式比較常見美觀。
2. 用戶通過APP內的操作如搜索、刪除等導致的空狀態
這種被動空狀態的情況更需要提示用戶
- 為什麼會出現空狀態的情況
- 怎樣做可以解決空狀態
- 其它可能你需要的功能等
從上圖實例中可以看出，功能系統較為完善的產品中，當有被動空狀態出現時，往往會給用戶其它選擇避免當前的“尷尬”，而不是冷冰冰的空白頁面，不知道的還以為正在搜索或者是卡了呢！
空狀態反饋機制總結：
- 注意區分兩種情境下的空狀態
- 空狀態的文案和插圖可以根據產品風格自由發揮，能幫到用戶當然更好
- 當出現空狀態時，可以提供給用戶其它相似/推薦內容，使部分用戶的體驗更為順滑，而不是斷斷續續的體驗。
三、服務器異常狀態提示
因為網絡或者服務器問題導致的頁面加載失敗問題，同樣需要反饋給用戶，告知用戶當前的狀態問題，如最近因為疫情隔離的原因各種服務器崩潰的軟件。（愛奇藝↑）
服務器異常導致的加載失敗等問題可以採用同上文討論的網絡異常問題的解決方案，但仍然需要針對不同異常場景採用不同的設計方案：
- 如果是簡單的服務器滿員等問題導致頁面加載失敗，可以用toast或缺省頁面的形式提醒用戶。
- 如果有詳細告知用戶服務器的問題的需要（如金融交易相關），為避免造成用戶恐慌，可以採用承載信息更多的模態彈窗提示，吸引用戶的注意力，把情況說明白。
需要注意的是提示的問題類型的文案描述要清晰，畢竟網絡問題和服務器問題是不同的，避免誤導用戶進行無用的修復。如果我知道是因為服務器崩了而不是我網絡的問題，那我可能就去微博看是不是上熱搜了，而不是重啟網絡試試，對吧~
服務器異常反饋機制總結：
- 注意區分不同情境下的異常及嚴重程度採用最簡單直接的提示形式，考慮解釋不清是否會對用戶造成恐慌或更嚴重的後果？
- 文案描述要清晰準確，避免用戶為了解決問題做無用操作
四、流量模式警告狀態提示
當處於流量模式下用戶觀看視頻、下載文件、播放歌曲等會消耗大量流量，此時有必要警告用戶目前處於流量模式，以免應用先消耗大量流量導致欠費問題。
針對該警告的提示形式有以下幾種：
1. 播放區/加載區文字提示
主要適用於視頻播放、直播類軟件，將提示和播放區結合設計的好處是：用戶原先進入播放頁後緊接著就會關注視頻播放區域，所以這種提示很符合應用場景，比較自然和直白，也能直接看到需要消耗多少流量。
2. 簡單toast提示，在切換WiFi之前會繼續消耗流量
常見於抖音等短視頻軟件，這種軟件對用戶的體驗流暢度要求很高，單個短視頻消耗流量並不多，而且在播放下個視頻之前不需要提前緩存。
綜合來看，採用toast的形式既不會過度干擾用戶觀看視頻的體驗，居中顯示的提示也容易被用戶注意到，可以在播放下一個短視頻時可以及時更改流量模式。同時，遇到網絡不穩定的情況，WIFI流量互切時，也不至於打斷用戶觀看視頻。
3. 模態彈窗提醒
現在軟件一般都內置流量模式設置，用戶可以依據自己的情況開啟流量模式下的查看/下載功能，一般默認關閉流量模式下的下載功能。
以騰訊視頻為例可以看到，點擊下載時從開始的提示到設置過程，兩次出現了模態彈窗提示，並輔以詳細的文字說明。可見模態彈窗的形式比較適合在“下載”這種通過用戶主動觸發且流量消耗大的動作情景下使用，減少用戶的錯誤點擊，並且可以提供設置按鈕入口。
4. 貼心的“已WiFi預加載”
在一些用戶體驗良好的產品中，我們還可以看到設計者在一些加載、廣告頁面添加的溫馨提示比如“過程不消耗流量”、“已WiFi預加載”，這也是狀態可見原則更細節貼心的應用。
流量模式警告反饋機制總結：
- 結合應用本身的特點採取合適的反饋形式，如有的不需要強制打斷，有的必須打斷用戶，讓用戶確認。總體設計原則是不過分打擾用戶，體驗良好。
- 挖掘用戶可能會認為消耗流量但並不會消耗流量的細節頁面，比如進度加載、廣告等，通過提示告知用戶。這不僅是產品狀態可見，也是讓用戶心理狀態更“放心”的可見。
五、版本不兼容狀態提示
版本不兼容一般有兩種觸發情景:
1. 消息等內容類顯示不兼容提示
我們使用低版產品收到高版本用戶發來的消息，若此低版本產品不兼容此消息的顯示樣式，則應該觸發該提示，提醒用戶當前版本不兼容或者，一般以在消息旁邊註明版本不兼容，點擊該文字提示，彈出產品升級提示彈窗，引導用戶升級版本。
2. 非消息類內容版本不兼容提示
長時間不更新版本過低，導致產品部分功能無法正常使用，此時提示用戶立即更新版本。常見直接以模態彈窗的方式提醒用戶更新版本比較合適，一是因為該功能已不可用，及時打斷，提醒用戶；二是彈窗內可配置下載更新按鈕，引導用戶前往更新。
六、操作失敗
在操作過程中經常伴隨著操作失敗的情況，此時要及時告知用戶失敗的狀態。一般以toast的形式進行提示。
七、無權限狀態提示
無權限的情況在B端產品及辦公類APP（如釘釘）常見，常見的處理方式有三種：
點擊後給出提示，APP使用toast或者缺省頁面比較合適，B端常用彈窗的形式提示用戶
頁面內直接隱藏無權限的功能或內容，雖然簡單粗暴，但是容易給用戶帶來困擾，因為用戶會相互比較，如果發現比別人少了什麼，難免心裡會打問號甚至誤以為BUG。
用戶無權限點擊的功能置灰，不可點擊。用戶嘗試點擊後可以給toast或者tips提示，告知無權限。
八、功能建設狀態
一般未開發上線的內容不會在頁面內佔位顯示，但有一些用戶期待較高的功能我認為可以配合如何運營的思路，在頁面內相應區域提示用戶“功能建設中，敬請期待哦”，可以增加用戶的期待感和參與感。
九、內容刪除、違規導致的查看異常
1. 內容刪除導致的查看異常
此時想查看內容，頁面需要分為兩種情況考慮：
發佈內容鏈接被轉發後，如果刪除了原鏈接內容，建議在之後轉發出的鏈接中註明被轉發的鏈接內容已刪除，防止用戶點開浪費時間。
A發佈內容，B在信息流中瀏覽過，此時若A刪除，B用戶因為有緩存，仍可以看到該內容，當點擊打開該內容鏈接時，出現刪除提示。
2. 內容違規造成的查看異常
內容違規造成的異常比較特殊，一般在打開前用戶是不知道違規的，所以打開後頁面以缺省頁的形式註明違規即可，同時附帶違規法律及違規詳情。
End…未完待續，下面可能會寫正常狀態相關的“狀態可見”原則的應用總結。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
