產品的極端情況是否需要考慮？

即使我們努力把產品的體驗做的再順暢，也難免會遇到一些意想不到的情況，也就是極端情況，那么極端情況我們到底要不要處理呢？

開頭我先講個親身經歷的小故事：還記得曾經在一家公司，當我把交互稿輸出給開發時，其中一位開發看到我給的“極端情況錯誤處理”時，他拋出一個大大的疑問，為什么這種情況也要考慮？正常人誰會這樣用啊，如果所有場景都考慮的話，那還有盡頭嗎？我覺得這種不用處理…

我聽了之后雖然講了我的看法，他的確也都聽了，但就是沒那么做，結果就收到客戶在我提到的場景下使用產品崩掉的反饋…

所以極端情況要不要處理呢？答案是：當然要！

一、為什么要考慮極端情況

作為一個交互設計師，時刻關注用戶體驗是最基本也是最重要的。一個業務邏輯單一的產品涉及的體驗點也會非常龐大，大到業務流程、信息架構，小到按鈕文案、操作提示等，除此之外，還有一些邊角極端情況。

所以不單單是那位開發同學，相信很多人都會想：梳理正常的邏輯就已經很考驗人的思考能力了，也完全可以滿足正常的場景了，為啥還要絞盡腦汁的去考慮極端情況，有必要嗎？

其實非常有必要。因為其實用戶對于正常順暢的操作體驗并不會有太深刻的感受，除非你的交互體驗登峰造極，但是一旦遇到一些極端情況導致產品可用性出了問題，那么用戶很可能會馬上卸載這款產品，所以極端情況千萬不要漏掉！

二、極端情況實例

首先呢，我們先看幾個常見的極端情況：

2.1 文字超長極限狀態

眾所周知，文字作為大部分產品中必現的元素，別看它簡單，可它的邏輯不少，比如首先是否要設字數限制，其次若設限，那么某些場景是否要顯示完整，超長了是折行還是末尾截斷等。

解決方案：

現在大部分產品都會設置一個字數上限，即使客戶端沒有展示，服務端也會有個字數限制。

拿人名舉個例子吧，一般處理是首先設置個20字上限，因為主要用戶是國內用戶，所以大部分不會超過4個漢字，所以盡量讓大部分情況能顯示的下5個字左右就可以了，超過后就末尾截斷，不支持折行，因為大多數情況下如果折行顯示頁面布局就沒法看了。

反例：列表條目文件名稱顯示做了字數限制，單行顯示，但實際幾乎沒限制，所以鼠標hover顯示完整后就災難了。。。

正例：列表條目文件名稱顯示做了字數限制，單行顯示，超長截斷，鼠標hover可顯示完整。

2.2 頁面內容空值

產品中有些頁面是類似瀑布流的形式，那么就會涉及初始為空的狀態，這種時候一定不要放任不管，給用戶一個空空如也的頁面。

目前看到的產品處理方式大概有三種：

1）空值提示：圖標+說明文案，一般應用于比較中性無強烈引導操作的頁面，例如消息、通知等

2）空值提示加操作引導：圖標+說明文案+引導操作，一般用于有引導性的頁面，例如社交、有交互的場景

3）推薦的內容：產品推薦一些內容供用戶查看，一般用戶內容類產品

無任何提示（反例）

具體哪種方式好，不能一概而論，要看產品本身屬性和具體場景，這里不做贅述。

2.3 頁面內容過多時的加載方式

還有一種情況就是頁面內容過多的情況，這里我們不考慮頁面展示只考慮進入頁面的加載，大家平時估計遇到過點開一個列表頁面，就一直在觀看“菊花轉”（頁面內容加載狀態），等的時間如果超過5秒可能就會產生焦慮了，再多點時間直接就和產品說拜拜了，那么這種極端情況一般怎么處理呢?

目前比較多的處理方式有：

1）頁面框架異步加載：先加載比較快的條目框架，具體內容再填充，比如先加載文字，后加載圖片

2）內容分頁加載：比如先展示返回的20條數據，再展示接下來的20條，依此類推

3）本地緩存：存儲一些固定的靜態元素到本地，下次直接獲取

2.4 非正常操作

在使用產品時，有些情況下，用戶進行了非正常的操作，這時候如果不處理輕則造成內容的混亂，重則直接程序崩潰不可用，這里的非正常操作一般包含兩種：

• 一種是“極限操作”，比如用戶在移動端和PC端都登陸了同一賬號，然后打開一個頁面同時操作不同的任務，就可能直接崩掉；
• 另外還有一種是“瘋狂操作”，用戶在一個頁面中以單身20年的手速點擊一個操作，這時候程序也可能“懵逼”的掛掉。

當然以上說的情況和代碼本身的健壯性也有關系，那么在體驗角度我們能些什么呢？

可以定義一個統一的規則，比如程序檢測到類似情況就出一個提示，因為極端操作情況比較少見，所以我們只要保證程序不崩潰，不影響用戶正常使用即可，具體可以根據實際場景處理。

2.5 服務器出錯

大家估計都遇到過一個頁面：404頁面，那這個頁面到底什么意思呢？

其實404頁面是客戶端在瀏覽網頁時，服務器無法正常提供信息，或是服務器無法回應，且不知道原因所返回的頁面，當然一般情況不會見到這個頁面，所以也是一種相對極端的情況，那有沒有必要處理呢？

其實是有必要的，大家可以看下未經處理的404報錯頁面：

很明顯，提示語很技術，不夠通俗易懂、直觀明了，那么再給大家看看一些產品的處理案例：

像以上優秀案例所示，其實404頁面能做的東西很多，包括品牌宣傳，引導操作，以詼諧幽默方式安撫用戶情緒等，所以遇到這種服務器的極端情況還是要處理的。

當然，服務器報錯不止404，其他類型的報錯可根據發生的概率酌情處理。

三、總結

以上僅僅舉了幾個極端情況的例子，實際上還會有很多，若想盡量覆蓋全極端情況，在設計時可以多多思考，將自己切換成“找茬兒模式”，也可以尋求QA同學的幫助，因為他們在寫用例時會考慮的更多。即使努力去想可能發生的極端情況，但是有些極端情況還是可能會遺漏，到真正遇到了才知道，不過其實也說明了那些想不到的極端情況可能發生的概率更小。

總之，有些極端情況一定要處理，盡量做到給用戶一個好的體驗，但是有些情況其實并不需要投入過多精力去思考該如何提升體驗，因為本身就不是正常的產品使用場景，只要在發生的時候保證產品可用性即可，因為還有更重要的產品主線體驗需要不斷去迭代提升。

你們覺得呢？歡迎一起探討交流。

 

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

題圖來自 Pexels ，基于 CC0 協議