產(chǎn)品的極端情況是否需要考慮?
即使我們努力把產(chǎn)品的體驗(yàn)做的再順暢,也難免會(huì)遇到一些意想不到的情況,也就是極端情況,那么極端情況我們到底要不要處理呢?
開頭我先講個(gè)親身經(jīng)歷的小故事:還記得曾經(jīng)在一家公司,當(dāng)我把交互稿輸出給開發(fā)時(shí),其中一位開發(fā)看到我給的“極端情況錯(cuò)誤處理”時(shí),他拋出一個(gè)大大的疑問,為什么這種情況也要考慮?正常人誰會(huì)這樣用啊,如果所有場(chǎng)景都考慮的話,那還有盡頭嗎?我覺得這種不用處理…
我聽了之后雖然講了我的看法,他的確也都聽了,但就是沒那么做,結(jié)果就收到客戶在我提到的場(chǎng)景下使用產(chǎn)品崩掉的反饋…
所以極端情況要不要處理呢?答案是:當(dāng)然要!
一、為什么要考慮極端情況
作為一個(gè)交互設(shè)計(jì)師,時(shí)刻關(guān)注用戶體驗(yàn)是最基本也是最重要的。一個(gè)業(yè)務(wù)邏輯單一的產(chǎn)品涉及的體驗(yàn)點(diǎn)也會(huì)非常龐大,大到業(yè)務(wù)流程、信息架構(gòu),小到按鈕文案、操作提示等,除此之外,還有一些邊角極端情況。
所以不單單是那位開發(fā)同學(xué),相信很多人都會(huì)想:梳理正常的邏輯就已經(jīng)很考驗(yàn)人的思考能力了,也完全可以滿足正常的場(chǎng)景了,為啥還要絞盡腦汁的去考慮極端情況,有必要嗎?
其實(shí)非常有必要。因?yàn)槠鋵?shí)用戶對(duì)于正常順暢的操作體驗(yàn)并不會(huì)有太深刻的感受,除非你的交互體驗(yàn)登峰造極,但是一旦遇到一些極端情況導(dǎo)致產(chǎn)品可用性出了問題,那么用戶很可能會(huì)馬上卸載這款產(chǎn)品,所以極端情況千萬不要漏掉!
二、極端情況實(shí)例
首先呢,我們先看幾個(gè)常見的極端情況:
2.1 文字超長(zhǎng)極限狀態(tài)
眾所周知,文字作為大部分產(chǎn)品中必現(xiàn)的元素,別看它簡(jiǎn)單,可它的邏輯不少,比如首先是否要設(shè)字?jǐn)?shù)限制,其次若設(shè)限,那么某些場(chǎng)景是否要顯示完整,超長(zhǎng)了是折行還是末尾截?cái)嗟取?/p>
解決方案:
現(xiàn)在大部分產(chǎn)品都會(huì)設(shè)置一個(gè)字?jǐn)?shù)上限,即使客戶端沒有展示,服務(wù)端也會(huì)有個(gè)字?jǐn)?shù)限制。
拿人名舉個(gè)例子吧,一般處理是首先設(shè)置個(gè)20字上限,因?yàn)橹饕脩羰菄鴥?nèi)用戶,所以大部分不會(huì)超過4個(gè)漢字,所以盡量讓大部分情況能顯示的下5個(gè)字左右就可以了,超過后就末尾截?cái)啵恢С终坌?,因?yàn)榇蠖鄶?shù)情況下如果折行顯示頁面布局就沒法看了。
反例:列表?xiàng)l目文件名稱顯示做了字?jǐn)?shù)限制,單行顯示,但實(shí)際幾乎沒限制,所以鼠標(biāo)hover顯示完整后就災(zāi)難了。。。
正例:列表?xiàng)l目文件名稱顯示做了字?jǐn)?shù)限制,單行顯示,超長(zhǎng)截?cái)?,鼠?biāo)hover可顯示完整。
2.2 頁面內(nèi)容空值
產(chǎn)品中有些頁面是類似瀑布流的形式,那么就會(huì)涉及初始為空的狀態(tài),這種時(shí)候一定不要放任不管,給用戶一個(gè)空空如也的頁面。
目前看到的產(chǎn)品處理方式大概有三種:
1)空值提示:圖標(biāo)+說明文案,一般應(yīng)用于比較中性無強(qiáng)烈引導(dǎo)操作的頁面,例如消息、通知等
2)空值提示加操作引導(dǎo):圖標(biāo)+說明文案+引導(dǎo)操作,一般用于有引導(dǎo)性的頁面,例如社交、有交互的場(chǎng)景
3)推薦的內(nèi)容:產(chǎn)品推薦一些內(nèi)容供用戶查看,一般用戶內(nèi)容類產(chǎn)品
無任何提示(反例)
具體哪種方式好,不能一概而論,要看產(chǎn)品本身屬性和具體場(chǎng)景,這里不做贅述。
2.3 頁面內(nèi)容過多時(shí)的加載方式
還有一種情況就是頁面內(nèi)容過多的情況,這里我們不考慮頁面展示只考慮進(jìn)入頁面的加載,大家平時(shí)估計(jì)遇到過點(diǎn)開一個(gè)列表頁面,就一直在觀看“菊花轉(zhuǎn)”(頁面內(nèi)容加載狀態(tài)),等的時(shí)間如果超過5秒可能就會(huì)產(chǎn)生焦慮了,再多點(diǎn)時(shí)間直接就和產(chǎn)品說拜拜了,那么這種極端情況一般怎么處理呢?
目前比較多的處理方式有:
1)頁面框架異步加載:先加載比較快的條目框架,具體內(nèi)容再填充,比如先加載文字,后加載圖片
2)內(nèi)容分頁加載:比如先展示返回的20條數(shù)據(jù),再展示接下來的20條,依此類推
3)本地緩存:存儲(chǔ)一些固定的靜態(tài)元素到本地,下次直接獲取
2.4 非正常操作
在使用產(chǎn)品時(shí),有些情況下,用戶進(jìn)行了非正常的操作,這時(shí)候如果不處理輕則造成內(nèi)容的混亂,重則直接程序崩潰不可用,這里的非正常操作一般包含兩種:
- 一種是“極限操作”,比如用戶在移動(dòng)端和PC端都登陸了同一賬號(hào),然后打開一個(gè)頁面同時(shí)操作不同的任務(wù),就可能直接崩掉;
- 另外還有一種是“瘋狂操作”,用戶在一個(gè)頁面中以單身20年的手速點(diǎn)擊一個(gè)操作,這時(shí)候程序也可能“懵逼”的掛掉。
當(dāng)然以上說的情況和代碼本身的健壯性也有關(guān)系,那么在體驗(yàn)角度我們能些什么呢?
可以定義一個(gè)統(tǒng)一的規(guī)則,比如程序檢測(cè)到類似情況就出一個(gè)提示,因?yàn)闃O端操作情況比較少見,所以我們只要保證程序不崩潰,不影響用戶正常使用即可,具體可以根據(jù)實(shí)際場(chǎng)景處理。
2.5 服務(wù)器出錯(cuò)
大家估計(jì)都遇到過一個(gè)頁面:404頁面,那這個(gè)頁面到底什么意思呢?
其實(shí)404頁面是客戶端在瀏覽網(wǎng)頁時(shí),服務(wù)器無法正常提供信息,或是服務(wù)器無法回應(yīng),且不知道原因所返回的頁面,當(dāng)然一般情況不會(huì)見到這個(gè)頁面,所以也是一種相對(duì)極端的情況,那有沒有必要處理呢?
其實(shí)是有必要的,大家可以看下未經(jīng)處理的404報(bào)錯(cuò)頁面:
很明顯,提示語很技術(shù),不夠通俗易懂、直觀明了,那么再給大家看看一些產(chǎn)品的處理案例:
像以上優(yōu)秀案例所示,其實(shí)404頁面能做的東西很多,包括品牌宣傳,引導(dǎo)操作,以詼諧幽默方式安撫用戶情緒等,所以遇到這種服務(wù)器的極端情況還是要處理的。
當(dāng)然,服務(wù)器報(bào)錯(cuò)不止404,其他類型的報(bào)錯(cuò)可根據(jù)發(fā)生的概率酌情處理。
三、總結(jié)
以上僅僅舉了幾個(gè)極端情況的例子,實(shí)際上還會(huì)有很多,若想盡量覆蓋全極端情況,在設(shè)計(jì)時(shí)可以多多思考,將自己切換成“找茬兒模式”,也可以尋求QA同學(xué)的幫助,因?yàn)樗麄冊(cè)趯懹美龝r(shí)會(huì)考慮的更多。即使努力去想可能發(fā)生的極端情況,但是有些極端情況還是可能會(huì)遺漏,到真正遇到了才知道,不過其實(shí)也說明了那些想不到的極端情況可能發(fā)生的概率更小。
總之,有些極端情況一定要處理,盡量做到給用戶一個(gè)好的體驗(yàn),但是有些情況其實(shí)并不需要投入過多精力去思考該如何提升體驗(yàn),因?yàn)楸旧砭筒皇钦5漠a(chǎn)品使用場(chǎng)景,只要在發(fā)生的時(shí)候保證產(chǎn)品可用性即可,因?yàn)檫€有更重要的產(chǎn)品主線體驗(yàn)需要不斷去迭代提升。
你們覺得呢?歡迎一起探討交流。
本文由 @江浦 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Pexels ,基于 CC0 協(xié)議
單身20年的手速??????
感謝分享
謝謝,歡迎一起交流哈 ??
當(dāng)然要,主流程是一方面,異常情況才是體現(xiàn)一個(gè)產(chǎn)品經(jīng)理思考的全面性
是的,異常情況很重要,不僅僅產(chǎn)品,各個(gè)環(huán)節(jié)的同學(xué)都要考慮 ??
感謝分享。
謝謝大佬!
文章部分轉(zhuǎn)載翻譯的吧,最好標(biāo)明出處
只有圖片是網(wǎng)上找了下,文章貌似沒有誒
感謝您的分享~~
謝謝,謝謝您,有想法可以一起交流哈