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