这周完成了一个评价管理相关的产品交互设计，有几次自己觉得已经简化得很好了，但再深入一交流一思考就发现之前的方案还是过于复杂，于是继续推进迭代直到满意为止，因为产品未上线不方便截图举例，就总结一些通用的关于简化设计的思路吧。
第一要务：基于产品设计目标梳理优先级
简约不等于简单，对界面和流程的简化应该基于对产品目标、每个模块目标及其优先级的理解，拉开功能模块之间的层次感，让最重要的内容优先呈现。
在完成第一版通用场景下的设计方案后，不要急着去补充各种操作状态和特殊场景，先冷静审视一遍现在的主要模块和布局，和PD沟通验证其层级关系排布是否符合对应的优先级，对实现产品设计目标不够重要的内容是否可以删除或隐藏留入口等，确保对页面上每一个组件都能说清楚它存在的意义、如何有助于达到我们的目标等。
了解真实使用场景，而非主动画蛇添足
拿关注A类内容功能的设计来举例，一开始我参考了比较普遍的一种模式，就是搜索+列表，但是和PD/业务方沟通后，发现我们的用户（商家）并不会去非常长的列表里查找，而是清楚地知道自己希望关注的对象的链接，通过链接就能定位到具体的内容了。那么列表的存在就没那么必要，列表占据了大部分面积却基本不怎么被使用，反而得到不少“第一眼看上去好复杂啊”的反馈。
及时跳出来，不要被原来的方案牵制思维
我们在做设计的时候，经常会遇到一些模块存在一定相似性的情况，有时就会直接复用或在已有的基础上小修小改，美其名曰“一致性”。
但这么做有一个坏处，就是容易被惯性思维束缚，按照惯性去设计，而没有基于模块自身的特性深入思考。比如说关注功能，我在做关注B类内容的一开始习惯性想把关注A类内容的交互方案搬过来，然后脑子里转念一想，不对啊，A类内容的可选列表非常长，每个条目信息量也比较多，不能简单平铺罗列出来所以比较复杂，但B类内容可选的最多就那么十几个吧（然后去沟通验证果然如此），而且是纯文本，那么直接放一排多选项就好了，完全没必要为了套A的交互弄得复杂。
再承前面的例子，因为关注A类内容的设计方案一开始是搜索+列表，内容较多，于是采取了浮层的方式。确定要简化掉列表后，一开始我没太多想，就直接在浮层里删除了对应的组件，OK，界面看上去挺简洁的。再一想，不对啊，既然这样为什么还需要存在浮层呢，就一个搜索框为什么要点击出现浮层再看到呢，直接把搜索框拿到原来的页面就好了啊，又是一个没及时意识到不同跳出来被惯性思维带着走的结果。
真的没有更好的方案了吗
最好的设计很少能一步到位，有时想了几种方案，选了一个相对好的之后，就会有种“这样就可以了”、“也没什么可用性问题了就这样吧”、“好像也想不到更好的了”的感觉。但再多看了几个例子，多请教了几个人后，才发现原来的方案还是太复杂，有不少简化的空间。在保证交付时间的前提下，不妨再多逼迫一下自己，“追求极致”不是说说而已。
