不知道身為「用戶體驗設計師（UX Designer）」的諸位是否也有過和我一樣的困惑：初入行時興沖沖覺得自己就是那個為一切產品用戶體驗問題負責的「真命天子」，積極主動去搜集反饋訪談用戶，可當真正卷起袖子打算為解決這些「體驗問題」大干一場的時候，卻發現有些無從下手。

隨便拉幾個用戶角度吐槽「體驗差」的例子：啟動慢、運行卡、索要一堆奇怪的權限、不知所云的錯誤、通知推送煩人、好多功能用不上……而這些用戶體驗問題，看上去似乎和用戶體驗設計師的本職（交互+視覺）關聯不大，而和技術、產品、運營同學的關系相對更加緊密。

用戶只看最終結果

兩年前在M廠實習期間參與某APP項目設計時，涉及到大量不同類型的內容卡片，而因為上線時間相對較急，沒有時間對每張卡片都進行完整的設計（設計出來開發也沒法都按期實現上線），于是就只做了框架層的設計，而卡片內容部分，則是讓開發直接把其他平臺相關產品的內容拉過來，再縮放處理了事，這一部分未經過交互視覺層的重設計優化（Review時把關也不太嚴），最終上線的體驗自然也好不到哪里去。

項目上線后卡片內容部分的體驗被吐槽，當時我的Manager & Mentor @Yu-Hsiu 也把我叫了過去，質疑這樣的體驗怎么能上線。起初我從趕工期、技術限制等方面進行了解釋，而Mentor的回答大意則是用戶不會知道這些，不會理解各種限制的苦衷，他們只看最終的結果，最終的界面交互體驗不好，他們只會覺得是用戶體驗設計師有問題，而不是什么開發來不及不好實現之類。

表達清楚態度緣由

承上文，有時我們確實不可避免地會遇到一些客觀限制（時間緊、人手不足、技術實現成本高），影響到最終的產品體驗，可偏偏「用戶只看最終結果」怎么辦？除了在溝通中守住合理的體驗標準底線、在后續迭代中及時優化外，其實也可以通過用戶更容易理解接受的方式，來向其表達和說明具體緣由。

比如去年雙11期間淘寶的「秋褲彈幕」，在公司里聽相關負責人分享時，提到項目當時面臨設計資源不足的問題，靈機一動想出了包括文案「設計師跑了」在內的彈幕形式，雖然沒有了高大上的視覺效果，卻多了趣味性，反而得到不少用戶的討論與傳播。

權限問題一直是國產Android App們受詬病的一點，用戶不明白為什么App要索取一大堆看上去和產品核心功能關系不大的權限，進而懷疑對方是否想利用這些權限做什么不好的事情，甚至失去對產品的信任。

其實在請求權限的場景里，我感覺是有很多體驗優化的空間的。比如界面文案上可以更清晰禮貌地告知用戶產品具體需要哪些權限，權限具體用于什么功能場景（而不是逼用戶自己去猜測，進而出現竊取隱私之類的推論）；保留用戶自主選擇的空間（可以選擇不給權限，但是某功能會受到影響，用戶自己決策），而不是硬邦邦地說「需要X權限」或偷偷開啟，而在產品里又找不到任何解釋；請求的時機也需要把握，在確實需要用到的時候再出現。

「出錯場景」是交互設計中經常要考慮到的一點，如果交互考慮得不全面，設計得不周到，則難免出現晦澀難懂的情況，用戶知道產品出錯了，卻不知道為何出錯，如何解決，甚至連錯誤本身也看不懂。錯誤既然已經發生，那就真誠地解釋清楚錯誤，引導用戶進行解決，甚至考慮一些趣味、情感化的手段，減輕用戶因此產生的煩悶情緒，比如Chrome斷網時的小恐龍游戲。

關注真實數據效果，發現用戶情感落差

我之前設計過一個平臺網站首頁，里面有一個模塊是用戶的排行榜單。在視覺評審的時候給前三名（共五人上榜）的用戶增加了1、2、3的排名標記，而我當時也覺得加上這個似乎也問題不大；但發布前驗收的時候卻發現，前三甚至前五用戶的真實排名參照數據之間差距非常微小，還出現了數據完全一致、排名卻分成了第2和第3的情況，這樣顯然第3的用戶會有感到困惑與不公的風險。

于是基于公平激勵用戶的考慮，在確認真實數據差異細微的場景下，我提出了去掉排名標記、所有上榜用戶一視同仁、給予同等激勵的解決方案，避免不公平、部分用戶產生情感落差。這件事也提醒了我真實數據的重要性，在有條件的情況下盡量「基于真實數據做設計」，而不是填一些理想的虛擬數據導致一些潛在問題被掩蓋。

善良比聰明更重要

古人說「文以載道」、「字如其人」，其實用在設計和所有創造性工作中也是一樣，很多優秀的設計多多少少也是作者內心價值觀追求的體現。我們在追求真誠、善良、公平、幽默等美好事物的同時，也可以多想想怎么投射到自己的設計思考與表達中去創造更美好的用戶體驗（而非狹隘的界面可用性提升），而不是耍小聰明避免承擔責任或賺取短期的數據光鮮。