如果您想訂閱本博客內(nèi)容，每天自動(dòng)發(fā)到您的郵箱中， 請(qǐng)點(diǎn)這里
很多設(shè)計(jì)中，我們付出20%的精力就可以應(yīng)付80%的 Normal Case，而剩下20%的 Special Case 卻會(huì)花費(fèi)我們80%的精力。換言之，普通情況誰都會(huì)處理，而為了應(yīng)對(duì)一些少數(shù)派，我們將要付出更多。
Loading 失敗時(shí)的錯(cuò)誤提醒、搜索無少結(jié)果時(shí)的空白頁面、打了車卻沒車接單……除了這正常流程下的失敗反饋以外，最耗時(shí)間的是那些特殊流程或所有情況同時(shí)在一個(gè)頁面堆砌出現(xiàn)的情況。
在設(shè)計(jì)前期，我們就應(yīng)該盡可能地羅列特殊情況，即便它們出現(xiàn)的概率很低，也應(yīng)留足設(shè)計(jì)時(shí)間。而應(yīng)對(duì)非常規(guī) Case 時(shí)，有一條原則幫了我很多次：
確保多數(shù)人體驗(yàn)的前提下，才去解決少數(shù)人的問題。
這不是說要為了多數(shù)人放棄少數(shù)人，還是造例子來說吧。
案例一：重復(fù)利用的物流單號(hào)
如果你在天貓有過退貨經(jīng)驗(yàn)就會(huì)知道，申請(qǐng)退貨并得到商家確認(rèn)后，需要填寫退貨的物流單號(hào)，當(dāng)商家收貨后才會(huì)把錢退給你。這里有個(gè)奇妙的問題，設(shè)計(jì)上是否允許多個(gè)用戶填寫同一個(gè)退貨單號(hào)？
先來看看如果允許，會(huì)出現(xiàn)什么非常規(guī)情況：消費(fèi)者AB兩人各自在同一個(gè)商家C處購買了兩臺(tái)
iPhone，并且商量好分別發(fā)起七天無理由退貨流程，商家C均同意。然后，消費(fèi)者A先將手機(jī)按要求寄出，獲取物流單號(hào)一個(gè)后填寫到退貨系統(tǒng)；同時(shí)，消費(fèi)者B直接使用消費(fèi)者A的退貨單號(hào)填入系統(tǒng)，但不寄送自己的手機(jī)。
極端情況體現(xiàn)在，許多商家的店鋪與倉儲(chǔ)是分開的，當(dāng)倉庫收到A寄來的手機(jī)并確認(rèn)收貨后，店鋪工作人員收到系統(tǒng)通知兩個(gè)退貨流程都已收貨（其實(shí)是同一個(gè)單號(hào)），若不進(jìn)行額外確認(rèn)，就會(huì)把錢都退回去了。
再來看不允許重復(fù)填寫同一個(gè)物流單號(hào)的情況：很簡(jiǎn)單，AB兩個(gè)消費(fèi)者是好人，但希望節(jié)省快遞費(fèi)，就商量好把兩個(gè)手機(jī)放在一個(gè)包裹里寄回。此時(shí)若規(guī)則只允許一個(gè)單號(hào)只能填寫一次，這種做法就無法實(shí)現(xiàn)。
錯(cuò)誤的設(shè)計(jì)方法是這樣的：用戶填寫退貨單號(hào)時(shí)，新增一個(gè)流程詢問用戶該單號(hào)是否只關(guān)聯(lián)了一個(gè)訂單，訂單號(hào)是多少；或者在原有基礎(chǔ)上新增一個(gè)聯(lián)合退貨的功能，讓多個(gè)用戶合伙拼單退貨。
正確的設(shè)計(jì)方法是這樣的：消費(fèi)者端流程全部不變，允許重復(fù)填寫物流單號(hào)，但必須在后臺(tái)記錄一條單號(hào)被使用的次數(shù)。對(duì)于被多次填寫的單號(hào)，在商家端告知商家須額外注意，一定與倉庫確認(rèn)好包裹內(nèi)物品再進(jìn)行退款操作。
錯(cuò)誤方法的錯(cuò)誤原因很簡(jiǎn)單，我們不能為了一些極端情況就去修改主流程，也不能為了少數(shù)人的需求就影響所有正常用戶。
案例二：互相沖突的 Toast 提醒
天貓客戶端的商品詳情頁中，當(dāng)點(diǎn)擊“收藏”按鈕會(huì)有一個(gè) Toast 告訴用戶“收藏成功”，同樣當(dāng)點(diǎn)擊“加入購物車”后，也會(huì)有 Toast
告訴用戶“加入成功”。這樣看好像沒什么問題，但若用戶點(diǎn)完“收藏”后馬上點(diǎn)擊“加入購物車”，就會(huì)出現(xiàn)兩個(gè) Toast
相互沖突的情況——視覺上互相重疊，或后一個(gè) Toast
無法出現(xiàn)。再極端一點(diǎn)，如果出現(xiàn)了一個(gè)腦殘用戶，為了測(cè)試反復(fù)快速點(diǎn)擊兩個(gè)按鈕，甚至?xí)?dǎo)致代碼錯(cuò)誤。
為了追求設(shè)計(jì)和代碼邏輯的嚴(yán)密，我和開發(fā)同學(xué)花費(fèi)了不少時(shí)間討論對(duì)于這種極端情況，要如何設(shè)置 Toast
的出現(xiàn)和沖突機(jī)制。甚至為了應(yīng)對(duì)極端情況，還需要調(diào)整 Toast 出現(xiàn)消失的動(dòng)畫過程與邏輯。但最后，我只設(shè)置了2個(gè) Toast
在極短時(shí)間內(nèi)前后觸發(fā)的交互，也就是新的 Toast 慢慢把舊的推上去，并各自做淡入淡出動(dòng)畫——畢竟兩次短促的操作是比較可能會(huì)發(fā)生的。
什么？你問我那個(gè)腦殘用戶怎么辦？不好意思，為了滿足所有正常用戶的訴求，腦殘用戶的體驗(yàn)就只好先放一放了……
案例三：神出鬼沒的 Loading
我們?cè)诳蛻舳松献隽艘粋€(gè)比較酷的動(dòng)畫，對(duì)一個(gè)模塊長(zhǎng)按后可以彈出一張卡片，并在卡片中閱讀一些詳情（有點(diǎn)像 3D
Touch）。問題在于，彈出卡片中的信息是觸發(fā)卡片后才向服務(wù)器請(qǐng)求數(shù)據(jù)并加載的，正常情況下沒有問題，但是弱網(wǎng)條件下，數(shù)據(jù)加載可能會(huì)花費(fèi)不少時(shí)間。為此，第一版我們?yōu)檫@個(gè)數(shù)據(jù)請(qǐng)求設(shè)計(jì)了一個(gè)
Loading 的小動(dòng)畫（好吧，你就當(dāng)是轉(zhuǎn)菊花）。
這樣做的結(jié)果是，對(duì)于網(wǎng)絡(luò)非常流暢的用戶，他們喚起這張卡片時(shí)，會(huì)看到一個(gè)菊花飛快地閃過，然后才看到數(shù)據(jù)加載——再流暢的網(wǎng)絡(luò)下，數(shù)據(jù)也需要加載時(shí)間，哪怕是1ms，都會(huì)讓菊花快速閃爍。
當(dāng)然，不要 Loading 也明顯不合理。弱網(wǎng)條件下，必須避免用戶盯著空白的卡片發(fā)呆而不知道系統(tǒng)正在干什么。
所以，合理的做法是，為 Loading
動(dòng)畫的出現(xiàn)時(shí)間設(shè)置一個(gè)延遲：在卡片彈出的200ms內(nèi)（卡片不可能突然閃爍出現(xiàn)在用戶面前，必須有一個(gè)進(jìn)場(chǎng)過程），如果數(shù)據(jù)加載完畢，則不顯示
Loading 動(dòng)畫，直接顯示數(shù)據(jù)。如果卡片進(jìn)場(chǎng)完畢（200ms后）數(shù)據(jù)還沒回來，則開始顯示 Loading 動(dòng)畫。
這樣，我們保證了正常用戶的正常體驗(yàn)，避免他們每一次操作都為弱網(wǎng)這一極端情況買單。同時(shí)，也保障了弱網(wǎng)用戶的體驗(yàn)。
最后，再總結(jié)一下我們的設(shè)計(jì)原則：確保多數(shù)人體驗(yàn)的前提下，才去解決少數(shù)人的問題。
藍(lán)藍(lán)設(shè)計(jì)( www.freegoal.net )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)
