交互設計師：拒絕純加法、拒絕自我妥協

設計拒絕純加法。

日常工作中，經常針對某個已有的頁面增加一些新功能，或者是將幾個分立的功能設計到同一個頁面當中。比較低級的做法是，強行將這些需求先孤立起來，然後機械地放到一起；而比較高級的做法，就是脫離純粹的業務需求，從用戶體驗和訴求出發，把兩個功能有機地整合到一起。

造個簡單的例子：

某外賣產品，線上已有的功能為用戶消費後可以對訂購外賣的商鋪進行評分，並供其他消費者查看。由於平台業務需要，要求除了對店鋪進行評分外，還需要用戶對派送員打分，幫助內部考核。請在原有的頁面中加入這個派送員評分功能。

簡單的做法是，在用戶支付、收貨流程結束後的評價頁面中，原有的商鋪評價模塊下，插入一個評價派送員的模塊。這種想法非常直觀，而且只是新增了一個流程、一部分數據，並不會對原有的結構造成太大的影響。而且由於模塊化、數據解耦，開發和維護起來也比較容易。

採用簡單做法看起來很好，那麼它的問題在哪裡：

功能來源於平台考核的訴求，但對用戶來說意義是什麼？

用戶是否願意在評價商鋪之後再評價派送員？流程會否太長？

用戶能否區分派送員、店鋪、外賣平台之間的關係？

事實上，機械地累加這一個功能，固然很好地解決了平台訴求，但活生生將用戶的評價流程延長了一倍。更為重要的是，每一次派送員都是系統按規則分配的，對用戶來說則是隨機的，那麼這份評分除了內部考核、服務不佳導致用戶投訴以外，幾乎對其他用戶沒有任何參考價值——他根本無權選擇要哪個派送員來送外賣。

因此，高級的做法應該是，在原有的評分體系中將店鋪外賣質量、派送服務整合到一個評價中。對用戶而言，在你的平台點餐，派送員到底是哪方的根本就不在乎，唯一在乎的就是服務本身。進一步，派送服務可以表達為時效、外賣送達時的狀態、派送員態度等，這些都可以和店鋪評價結合到一起。如時效，可以在系統層面設置備餐時間和派送時間，如果用戶點評時效不佳，則通過系統判別究竟是店鋪準備外賣時間過長，還是派送時間不滿意，進而事實內部管理手段。

儘管第二種高級做法增加了開發、設計、運營成本，但從消費者角度來說卻是體驗最佳的做法。作為交互設計師，考慮到真實的成本、資源限制，最後的方案可能不是最完美的。但最初，必須跳出簡單的機械思路，真正圍繞用戶體驗去做設計。

設計拒絕自我妥協

交互設計師需要在工作中對技術、產品、運營都有所了解，這可以幫助我們平衡各方資源，得到設計、業務和成本上的最優解。日常工作中，每一個需求都會涉及很多開發、運營環節。比較低級的做法是，在開始構思設計方案之前先羅列一大堆技術限制：這種效果可能不好做、這種模式數據結構要改動、這種邏輯可能會導致頁面性能問題......最後你還沒開始做設計，就先給自己的方案砍了一刀又一刀，主動自我妥協。而比較高級的做法是，首先從純粹的用戶體驗出發，構思出最理想的設計方案，然後進一步再和開發、產品同學溝通，面對開發成本等問題儘可能推動解決，實在受限的再適當妥協。

看起來好像只是妥協和設計的順序不一樣而已，而且很多設計師會覺得自己提前考慮開發風險是能力的體現，但這個問題最核心的內容就是你作為交互設計師，到底是站在誰的角度設計——當然是用戶。固然，我們要考慮開發成本、考慮時間限制、考慮各種各樣的因素，但如果最初你就沒有完全從用戶的角度去做設計，那最後的方案必然不是對用戶最友好的。

我記得自己實習轉正時，給自己羅列的一個優勢就是：有技術背景，懂得預判設計風險。然而這次教我不要首先自我妥協的人不是設計師，正是開發同學。很多新人都自以為減少了開發成本，殊不知開發同學的用戶體驗意識都比你強。

開發同學說的話我會一直記得：你不要一上來就考慮我的成本、我的風險，這些是我考慮的事，是我的工作。你要做的，就是搞清楚什麼是對用戶最好的，剩下的就交給我。這種方案我作為用戶也接受不了，你再回去重新考慮一下吧。