編輯導讀：當產品出現異常狀況時，例如網絡異常、用戶無權限等異常狀態下，產品需要在界面對用戶進行異常狀態的反饋和引導，幫助用戶快速獲得幫助。本文作者以B端產品為例，分析其在異常狀態下的產品設計，希望對你有幫助。

近期個人跟進的一個產品被用戶提了意見：每次進入頁面的時候，頁面空白，什么信息都沒有，跟故障了沒有數據一樣。

詳細了解情況后，發現確實是出現了異常。這是一款查詢類工具產品，進入頁面已有基礎的默認查詢條件及相應數據展示，本身需要用戶具有相應的權限才能進行查詢，前述用戶反饋的問題，就是因為賬號沒有相應頁面功能的數據權限導致的。

遺漏了用戶在異常狀態下的設計，會導致用戶在每一次的操作后，產品界面一直沒有任何反饋，業務流程中斷，停滯不前，然后用戶心中會產生疑問：怎么回事？但又無人解答。

一次次地復現后，則會產生相同的結論：這個東西沒法兒用，我的需求，你無法滿足。在一次次的失望，放棄這款產品，不再使用，而這僅僅是因為我們沒有對異常狀態做好一個合理反饋/引導。

正常情況下，產品經理應該定義清楚，在諸如網絡異常、用戶無權限等異常狀態下，產品應該如何提示用戶，幫助用戶恢復正軌。

如上述例子中，可以在界面提示用戶賬號權限不足，請聯系管理員，或給到技術支持電話，通過人工介入的形式，使無助的用戶能快速獲得幫助。

當然這個意見，也暴露出之前團隊只專注于主操作流程、主頁面的不同狀態，卻忽略產品中容易出現的各種異常狀態的問題，這是一個不容忽視的問題。

對于以提升效率為目的的B端產品而言，缺乏對異常狀態的反饋設計，會導致用戶遭遇某種異常情況時，不清楚發生了什么事，長時間停留在原地，無法快速定位到問題，最終導致業務處理的效率低下。如果一直保持現狀，長此以往，就算上線了很多功能，對用戶而言這些功能也是無效的的。

一、什么是異常

異常是正常的相對概念，漢典中，解釋正常是符合一般的情況、規律或習慣。

對于產品而言，正常狀態是指在產品使用過程中，交互反饋結果符合業務流程/交互邏輯/用戶預期的狀態；反之，不符合業務流程/交互邏輯/用戶預期時，是異常狀態。

例如，我們在百度搜索“正?！眱蓚€字，頁面返回的第一個結果是有關“正?！钡陌俣劝倏?，此時是正常狀態；如果頁面一直是空白，或者頁面返回的第一個結果是有關“異?！钡陌俣劝倏?，此時是異常狀態。

異常狀態，是由于在程序運行過程中發生外部問題導致的，在用戶操作-反饋的過程中，可能會被多種外部因素干擾而產生異常。

例如：網絡環境因素中最常見的網絡連接失敗，網絡連接失敗會直接導致導致無法上傳和下載數據，它們會出其不意地發生，并影響任何一個環節。

因為外部因素的產生是不可控的，因此異常狀態的發生也是不可控的。

有些異常我們可以通過技術手段避免，但產品使用時的外部環境因素是我們無法控制的，所以我們始終無法避免異常狀態的發生，那么就應該提前考慮可能發生的異常因素及結果狀態。

結合場景針對性地設計反饋，在前端可感知地告訴給用戶，引導用戶理解自己所在頁面的狀態及可以怎么做，而不是讓用戶怎么操作都沒有反饋，不知道發生了什么問題，業務流程中斷，進一步導致用戶焦慮，最后拋棄產品。

依舊以上文中因權限不足導致的頁面空數據為例，對于這類依賴權限系統配置的因素我們無法控制，所以應該提前考慮在用戶權限不足的情況下，讓用戶意識到當前頁面空數據是因為權限不足導致的，可以去聯系管理員授權，或者返回上一層頁面，讓用戶盡快離開當前功能；

而不是像原有產品設計一樣什么都不反饋，讓用戶以為是系統故障導致的頁面空白，最后憤怒地找到我投訴產品無法使用。

二、異常狀態設計原則

設計的最終目的是讓產品更可用、更易用，針對異常狀態的設計也是如此。

發生異常時，為了避免用戶不明所以，讓用戶更快地知道當前產品處于異常狀態，和產生異常的原因，降低用戶的焦慮感，在異常反饋的設計過程中，可以結合場景參考一些通用的用戶體驗設計原則。

以下是我常用的可以和異常狀態設計關聯的設計原則：

1. 狀態可見原則

狀態可見，指的是通過界面反饋設計讓用戶清晰地知道當前系統的狀態，特別是讓用戶第一時間清楚地知道當前產品處于異常狀態。

正常來說，用戶對異常是沒有概念的，如果不明確地告訴用戶系統處于異常狀態，他們會以為是正常情況并持續等待結果，一直沒有結果可能會焦慮、暴躁，持續重復多次后操作發現還是不知道發生了什么，就可能離開產品了。

因此在前端界面將系統狀態展示出來，不僅能讓用戶快速地了解自己處于何種狀態、對過去發生、當前目標有所了解，還能讓用戶快速判斷下一步該怎么做，避免浪費用戶時間，而不是停留在原地等待，也能有效減少用戶的負面情緒。

例如下面這個案例，同樣是因為網絡緩慢導致的加載異常，在不具備狀態可見的左圖，用戶會持續等待進度條的加載，不知道加載了這么久還沒加載出來的原因，不敢離開頁面因為不知道還要等多久；

但對于狀態可見的右圖，用戶明確知道頁面加載失敗了，雖然界面沒有給到加載失敗的原因，但用戶已經知道現在處于異常狀態，就不會浪費時間等待，會嘗試刷新或者直接離開頁面，也能有效避免用戶負面情緒的積聚。

2. 可退出原則

可退出，指的是在產品處于異常狀態時，給到用戶明確的出口可快速離開當前頁面。

對于諸如服務器異常等原因導致的異常狀態，用戶是無法通過個人的重復操作恢復到業務正常狀態的，讓用戶在無法解決的異常頁面重復嘗試只會讓用戶積聚負面情緒，無法快速找到離開的出口甚至沒有離開頁面的出口，更是會讓用戶的情緒瞬間爆發。

因此，對于用戶自行無法解決的異常情況，與其讓用戶什么都無法操作，或者做無謂的嘗試，還不如直接給到退出出口離開產品，這樣對用戶的情感傷害會更小一些。

例如下面的兩個例子，都是因為服務器異常導致的異常狀態，致使產品無法使用，僅僅通過toast提示用戶異常原因，告知了就結束了，讓用戶停留在原地等待，無法進行其他操作，也沒有其他操作按鈕；

相比之下，明確以對話框的形式告知用戶服務器異常，用戶在了解情況后點擊確認按鈕，即退出產品，這樣的形式信息展示明了，操作快捷，避免了用戶不知道怎么離開當前異常的囧境，和負面情緒的積聚。

3. 指引性原則

指引性原則，指的是針對一些操作可能會導致異常的情況，在用戶操作前，設計指引信息防止這類問題發生，或在用戶可能犯錯時提供提示信息，避免異常的發生。

產品設計過程中，有些正常操作可能會導致異常狀態，如用戶上傳文件時選擇的文件超出了系統限定的大小。

對于這種情況，作為產品設計者，我們不應該眼睜睜地看著用戶走到錯誤的那一步。

因為這樣會讓用戶不明所以，明明都是按照系統要求的步驟流程操作的，為什么操作結果有時候成功有時候失敗，直到成功/失敗多次后，用戶才可能摸索出其中潛在的系統規則——文件大小不能超過xx，讓用戶在試錯中摸索系統規則，對于以提高業務效率的B端產品而言，是尤其不可取的。

所以，我們應該在設計過程中，注意到可能導致異常狀態的操作，并結合業務情況，設計反饋引導，甚至是對用戶的操作進行限制，以避免用戶試錯。

例如，下面的場景是用戶上傳文件時的界面，此處結合業務情況，對上傳文件有兩個要求：excel文件和5MB以內。從指引性原則出發，界面左下方告知用戶系統規則，在用戶選擇文件的過程中，是無法選擇非excel文件的，同時對于文件大小超過5MB的文件，也會以彈窗形式告知操作失敗，這樣能夠有效地避免用戶在正常業務流程進行無謂的試錯，保證業務效率。

4. 容錯原則

容錯原則，指的是當產品已經處于異常狀態時，給到用戶可以自行操作、糾正錯誤的操作功能，讓用戶能自主嘗試恢復回正常的業務軌道上。

在導致異常的因素中，有很多是短暫持續卻經常發生的，例如因網絡波動導致的加載異常，因為這類異常情況，是可以在短期內自動恢復的，重新操作后恢復正常狀態的概率較高，所以我們應該讓用戶自己嘗試解決，而不是建議離開，這樣可以將異常狀態對業務帶來的影響降到最低。在設計用戶的可操作功能時，也應該注意不要讓用戶進行過多的操作，重復異常發生之前的操作既可。

例如下面圖中是下載失敗的異常狀態，此時我們可以明確地告訴用戶上一次操作失敗了，并給到一個重新下載的按鈕，讓用戶不用重新選擇需要下載的文件既可再次嘗試下載操作，這樣就可以讓用戶繼續原有業務了。

以上是個人在實踐過程總結的適用于異常狀態設計的原則，希望這些原則可以在明知道會產生異常狀態但不知道如何設計時幫助到你，給你思路。

三、總結

以上對異常狀態的設計原則進行了總結，相對正常狀態，異常狀態較為少見，容易忽略，但異常也是設計中的一部分。

無論是交互設計師還是視覺設計師都應該結合業務場景，給出異常的表現形式或處理方式，保證產品異常時不至于中斷任務的執行，對異常提供適當的引導，達到產品性能、業務流暢、防錯效果的平衡。

當然也有公司特殊的業務導致存在很特殊的異常狀態，歡迎大家一起溝通交流學習進步。

作者：伯安，公眾號：伯安郡

本文由 @伯安 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議