设计拒绝纯加法。
日常工作中，经常针对某个已有的页面增加一些新功能，或者是将几个分立的功能设计到同一个页面当中。比较低级的做法是，强行将这些需求先孤立起来，然后机械地放到一起；而比较高级的做法，就是脱离纯粹的业务需求，从用户体验和诉求出发，把两个功能有机地整合到一起。
造个简单的例子：
某外卖产品，线上已有的功能为用户消费后可以对订购外卖的商铺进行评分，并供其他消费者查看。由于平台业务需要，要求除了对店铺进行评分外，还需要用户对派送员打分，帮助内部考核。请在原有的页面中加入这个派送员评分功能。
简单的做法是，在用户支付、收货流程结束后的评价页面中，原有的商铺评价模块下，插入一个评价派送员的模块。这种想法非常直观，而且只是新增了一个流程、一部分数据，并不会对原有的结构造成太大的影响。而且由于模块化、数据解耦，开发和维护起来也比较容易。
采用简单做法看起来很好，那么它的问题在哪里：
功能来源于平台考核的诉求，但对用户来说意义是什么？
用户是否愿意在评价商铺之后再评价派送员？流程会否太长？
用户能否区分派送员、店铺、外卖平台之间的关系？
事实上，机械地累加这一个功能，固然很好地解决了平台诉求，但活生生将用户的评价流程延长了一倍。更为重要的是，每一次派送员都是系统按规则分配的，对用户来说则是随机的，那么这份评分除了内部考核、服务不佳导致用户投诉以外，几乎对其他用户没有任何参考价值——他根本无权选择要哪个派送员来送外卖。
因此，高级的做法应该是，在原有的评分体系中将店铺外卖质量、派送服务整合到一个评价中。对用户而言，在你的平台点餐，派送员到底是哪方的根本就不在乎，唯一在乎的就是服务本身。进一步，派送服务可以表达为时效、外卖送达时的状态、派送员态度等，这些都可以和店铺评价结合到一起。如时效，可以在系统层面设置备餐时间和派送时间，如果用户点评时效不佳，则通过系统判别究竟是店铺准备外卖时间过长，还是派送时间不满意，进而事实内部管理手段。
尽管第二种高级做法增加了开发、设计、运营成本，但从消费者角度来说却是体验最佳的做法。作为交互设计师，考虑到真实的成本、资源限制，最后的方案可能不是最完美的。但最初，必须跳出简单的机械思路，真正围绕用户体验去做设计。
设计拒绝自我妥协
交互设计师需要在工作中对技术、产品、运营都有所了解，这可以帮助我们平衡各方资源，得到设计、业务和成本上的最优解。日常工作中，每一个需求都会涉及很多开发、运营环节。比较低级的做法是，在开始构思设计方案之前先罗列一大堆技术限制：这种效果可能不好做、这种模式数据结构要改动、这种逻辑可能会导致页面性能问题......最后你还没开始做设计，就先给自己的方案砍了一刀又一刀，主动自我妥协。而比较高级的做法是，首先从纯粹的用户体验出发，构思出最理想的设计方案，然后进一步再和开发、产品同学沟通，面对开发成本等问题尽可能推动解决，实在受限的再适当妥协。
看起来好像只是妥协和设计的顺序不一样而已，而且很多设计师会觉得自己提前考虑开发风险是能力的体现，但这个问题最核心的内容就是你作为交互设计师，到底是站在谁的角度设计——当然是用户。固然，我们要考虑开发成本、考虑时间限制、考虑各种各样的因素，但如果最初你就没有完全从用户的角度去做设计，那最后的方案必然不是对用户最友好的。
我记得自己实习转正时，给自己罗列的一个优势就是：有技术背景，懂得预判设计风险。然而这次教我不要首先自我妥协的人不是设计师，正是开发同学。很多新人都自以为减少了开发成本，殊不知开发同学的用户体验意识都比你强。
开发同学说的话我会一直记得：你不要一上来就考虑我的成本、我的风险，这些是我考虑的事，是我的工作。你要做的，就是搞清楚什么是对用户最好的，剩下的就交给我。这种方案我作为用户也接受不了，你再回去重新考虑一下吧。