設(shè)計師經(jīng)常犯的一個錯誤就是上帝視角，高估了用戶的理解能力。一頓操作猛如虎，結(jié)果用戶可能根本沒看懂你的設(shè)計。
前段時間個人所得稅app 上線，用戶可以在線辦理個稅專項扣除申報。我自己也嘗試使用了一波，在申請房貸利息抵扣的時候發(fā)現(xiàn)了一個問題。
在房貸信息模塊里需要我輸入證書編號，但是我根本不知道到底要哪個證書編號。輸入提示非常的簡潔，就三個字「請輸入」，到底要輸入什么？這樣的表單在很多產(chǎn)品中都可以看到，讓用戶輸入生日，但沒有告知日期的格式。日期格式真的太多了，用戶到底選擇哪種？
設(shè)計師經(jīng)常犯的一個錯誤就是上帝視角，高估了用戶的理解能力。一頓操作猛如虎，結(jié)果用戶可能根本沒看懂你的設(shè)計。
有的時候用戶并不是看不懂你的設(shè)計，而是沒時間看你的設(shè)計。如果我們做了一個抽獎活動，用戶看了一眼主界面沒有弄明白是怎么玩的，那么這個抽獎大概率是失敗的。你或許會不服，我明明把活動規(guī)則已經(jīng)寫在下方了，可是用戶根本不會看。因為他們真的很「懶」。
所以讓「用戶看懂你的設(shè)計」，首先我們應(yīng)該做到「讓用戶更快的看懂」。我們需要提升信息的傳遞效率。
1. 信息可視化
俗話說「字不如表，表不如圖」。用戶對于具象元素（表格、插畫、icon和圖像等）的感知能力更強(qiáng)，具象元素也更能傳遞情緒。例如：道路兩旁的路標(biāo)多數(shù)是以圖形為主體的。這是因為在車子高速行駛的過程中，司機(jī)沒有足夠的時間閱讀標(biāo)示上的文字。
場均122.4分，30.6個助攻，45.0個籃板……這些數(shù)據(jù)對于我們來說只是冷冰冰的數(shù)字，我們很難理解其背后的含義。雷達(dá)圖對球隊數(shù)據(jù)進(jìn)行了可視化處理，提升了信息的可讀性。因為相較于純文本，大腦處理圖形的速度要快得多。
以谷歌日歷為例，如果我要做瑜伽，那么就會在日程詳情頁配一個瑜伽墊的插畫；如果我要跑步，那么就會配一幅跑鞋插畫。用戶甚至不用看文字，通過插畫上所描繪的場景就可以知道自己接下來的行程。用戶可以更快地看懂。
2. 合適的組件
選擇合適的組件可以降低用戶的學(xué)習(xí)和操作成本。以上面的生日為例，與其通過輸入提示告訴用戶日期格式，還不如直接給用戶提供一個日期組件。
多數(shù)的選擇場景中我們都會使用底部動作欄來承載選項，如選擇優(yōu)惠券/銀行卡。參考了一些產(chǎn)品，發(fā)現(xiàn)他們都在底部加上了關(guān)閉/確定按鈕。我們不妨來思考：動作欄界面底部需不需要提供關(guān)閉/確定按鈕？
決定一個元素的去留，我們需要明白它的作用是否可以被替代。底部的按鈕是供用戶點(diǎn)擊關(guān)閉底部動作欄的，光看「關(guān)閉動作欄」這個動作，底部按鈕并不具備不可替代性。因為點(diǎn)擊上方的空白區(qū)域或者把關(guān)閉按鈕放在右上角都可以關(guān)閉動作欄。
這樣一看，底部的按鈕是可以刪除的。那為什么其他的產(chǎn)品都保留了呢？因為我們忽視了組件的信息屬性，我們沒有考慮如果沒有它是否會對用戶了解系統(tǒng)當(dāng)前的狀態(tài)造成影響。
沒有底部的按鈕，用戶無法確定底部動作欄是否正常加載。用戶不知道我是只有一張銀行卡還是只加載出來一張銀行卡。
前段時間去體檢，發(fā)現(xiàn)排隊顯示屏中有的人前面有咖啡圖標(biāo)，有的人沒有。好奇的我特地找護(hù)士問了一下，發(fā)現(xiàn)咖啡意味著接下來的體檢項目不需要空腹，你可以去吃早飯了。圖標(biāo)的確很簡潔，可是有多少人看到這個咖啡圖標(biāo)會立刻意識到自己可以吃早飯了呢？
過度追求信息傳遞的效率，而忽視了精度，從一個極端走向另一個極端——簡潔易懂的文案是保障信息準(zhǔn)確性的重要措施。
前段時間針對報錯文案做了一個梳理，發(fā)現(xiàn)了一些文案中的共性問題。
1. 沒有提供解決方案
一個合格的報錯文案應(yīng)該由：報錯場景、報錯原因和解決方案共同構(gòu)成。首先告知用戶具體遇到了什么樣的報錯場景并且解釋原因，最后提供解決方案。多數(shù)文案都只做到第一步，只描述了報錯場景，這并不能滿足用戶的需要。
- 如果照片上傳失敗，用戶需要知道是因為格式不對還是圖片太大了。
- 如果因為系統(tǒng)升級，導(dǎo)致服務(wù)暫停，用戶需要知道什么時候可以再次提供服務(wù)。
- 如果把報錯場景看成是一個坑，那么報錯文案應(yīng)該告訴用戶你掉進(jìn)了一個什么樣的坑，為什么掉進(jìn)來以及怎么樣才能爬出去。
2. 擁抱數(shù)字
多數(shù)的文案都不愛提供數(shù)字，用戶能獲取的信息也比較模糊。我們盡量給用戶提供準(zhǔn)確的數(shù)字，包括時間、金額、次數(shù)等，讓用戶對當(dāng)前的狀態(tài)有一個準(zhǔn)確的認(rèn)識。
輸入手勢密碼錯誤是有次數(shù)限制的，可是你并沒有告訴用戶今天還剩幾次機(jī)會。
我們經(jīng)常會遇到資料審核的場景，最常見的方法就是告訴用戶「資料審核中」，非常的省事。但是用戶會疑惑到底要審核多久，給用戶提供一個大致的審核時間，讓用戶有目的的去等待。
如果前面兩個方法都不能解決用戶的疑問，那么我們只好給用戶提供在線客服了。
1. 入口的必要性和統(tǒng)一性
客服的入口一般在首頁或者用戶的個人信息頁，除此之外我們需要在用戶有客服訴求的場景中給用戶提供客服入口。如果不提供入口，用戶遇到問題就要返回到首頁或者我的頁會很繁瑣。如果用戶在一個表單頁中錄入信息，突然對某一項內(nèi)容不確定，返回到首頁找客服咨詢。這樣可能會導(dǎo)致用戶之前填寫的信息丟失，用戶需要重新輸入一遍。
以下圖為例，這是一個借款的表單頁，用戶在這里錄入借款信息。我們會給用戶推薦一款借款人安全險的保險產(chǎn)品，提示文案是「保費(fèi)60元，貸款利息可節(jié)約55.33元」。
但是用戶反饋不知道這個60元的保費(fèi)是一次性扣除還是每月都會收取，并且這個利息節(jié)省是什么意思。因為對收費(fèi)標(biāo)準(zhǔn)不確定，用戶的購買意愿也會受到影響。這里的文案表述不清楚，我們可以給用戶提供一個客服的入口。
因為在線客服是一個共有的模塊，不同的業(yè)務(wù)線都可能會調(diào)用。那么在入口的設(shè)計上，我們需要注意一致性。當(dāng)然我們也不能過于死板的追求一致性，因為不同場景用戶對于客服的訴求是不一樣的。就以支付寶為例，生活繳費(fèi)和螞蟻借唄兩者在線客服的入口是不一樣的。
因為相對來說，用戶對借錢的場景更加敏感，有更多的疑問去確認(rèn)。這筆貸款的利率怎么算的？還款方式是怎么樣的？會不會影響我的個人征信？所以在借唄頁中，用戶對于客服的訴求更高，所以在布局上會放在更加顯眼的位置。
2. 對話式交互
用戶進(jìn)入客服系統(tǒng)不意味著立馬可以跟客服小姐姐聊天。咨詢問題一般會經(jīng)歷以下幾個步驟：
- 提供猜你想問的問題；
- 客服機(jī)器人；
- 真人客服。
以支付寶為例，首先會根據(jù)你的來源給你推薦你可能想問的問題。例如：你從充值中心進(jìn)入客服，首先會給你推薦充值繳費(fèi)相關(guān)的問題。
如果提供的問題列表里沒有用戶想問的，用戶就需要手動去查找問題。這時客服機(jī)器人登場，根據(jù)你輸入的關(guān)鍵詞，給你提供相應(yīng)的解決方案。如果客服機(jī)器人不能解決你的問題，那么可以召喚真人客服來幫你解答。
京東金融與支付寶的客服流程大同小異，其中的一個區(qū)別在于它額外提供搜索框來查找問題，而支付寶是通過對話式交互來查找問題。
對話式交互也是近年來比較熱門的一個話題。對話式交互主要的優(yōu)點(diǎn)在于學(xué)習(xí)成本低，我們現(xiàn)有的交互體系都是建立在人工智能不夠智能的基礎(chǔ)上。如果足夠的智能，未來的產(chǎn)品界面可能就是兩個對話框，你只要打出或者說出你的需求就可以了。
年初一下午我要看韓寒的新電影，幫我預(yù)定一張票。系統(tǒng)根據(jù)你的行程和之前的觀影記錄，猜測出你當(dāng)天觀影的影院和時間順便根據(jù)你的喜好選好座位，生成了一個訂單或者同時生成好幾個訂單供你選擇，你確認(rèn)一下就可以。
當(dāng)然這只是一種設(shè)想，目前的技術(shù)還無法實(shí)現(xiàn)，系統(tǒng)無法真正分析出用戶的真實(shí)意圖并且做出反饋。例如，在現(xiàn)實(shí)人與人的對話中，同樣的一句話，不同的語境下有著不同的意思。
把這個場景帶入客服中，我們輸入「修改」可以發(fā)現(xiàn)有這么多相關(guān)的問題。如果我從白條頁面中進(jìn)入客服，我輸入「修改」，那么應(yīng)該優(yōu)先從白條相關(guān)的問題中篩選出與「修改」相關(guān)的問題。而目前來說，不管從哪個模塊進(jìn)入客服，輸入「修改」給你推薦的問題都是一樣的，沒有考慮語境。在這種不夠智能的情況下，對搜索結(jié)果的展示上傳統(tǒng)的搜索框模式更加合適。
以上是我簡單的分析和總結(jié)，如果你有不同的看法和建議歡迎留言。