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

12 評論 11799 瀏覽 93 收藏 11 分鐘

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

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

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

所以極端情況要不要處理呢?答案是:當然要!

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

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

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

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

二、極端情況實例

首先呢,我們先看幾個常見的極端情況:

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 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 單身20年的手速??????

    回復
  2. 感謝分享

    回復
    1. 謝謝,歡迎一起交流哈 ??

      來自浙江 回復
  3. 當然要,主流程是一方面,異常情況才是體現一個產品經理思考的全面性

    回復
    1. 是的,異常情況很重要,不僅僅產品,各個環節的同學都要考慮 ??

      來自浙江 回復
  4. 感謝分享。

    來自上海 回復
    1. 謝謝大佬!

      來自浙江 回復
  5. 文章部分轉載翻譯的吧,最好標明出處

    來自浙江 回復
    1. 只有圖片是網上找了下,文章貌似沒有誒

      來自浙江 回復
    2. 感謝您的分享~~

      來自浙江 回復
    3. 謝謝,謝謝您,有想法可以一起交流哈

      來自浙江 回復