有一句话叫做，“因为你好看，所以看好你”。我们无法停止对表象的热爱，除非我们开始思考一些本质，只有这个时候，本质才能取得语义和热情的双重关注。
聊两件工作中形式和本质有明显差别的情况。
第一件事，在做的过程中讨论，在讨论中推进，是小团队作战的一个优选策略。小团队做的事情常常具有探索性，成员常常十分聪明很有斗志但是明显经验不足，做事速度十分快，这几个方面的原因必然导致的情况是，设计还不全面计划还不充分的情况下就已经开始动工了。好在小团队的沟通路径十分短，所以在工作中的讨论会非常多。比如产品出来的图只是满足功能点的需求，在交互和数据方面留有一些不清楚的地方。这种情况下，前端工程师和数据工程师在写程序的时候会发现问题，于是一起讨论，在这个过程中定下规则，再继续前进。
举个例子，原型图只是列出了功能点。
UI同学会给一个相对规整一点的，如下。
这个时候就会存在一个问题，每一项由checkbox来管，radio有默认选项，第三列为空。就目前的用户使用习惯来说，首先，不能区分c和r，勾选就代表选择？用户会有困扰。第二，先点c然后再点r，一件事有两个步骤。第三，右侧的空，不合适。前端工程师和产品商量后决定，第一，不给默认选项。第二，选择了c才能选r。第三，取消了c就取消了r。这样很好地解决了用户困扰问题。
第二件事，没有不谈及对象的简单，只有照顾到对象的选择。我们常常会说simplicity is beauty，这确实也是一个崇尚简洁美的时代。然而，简洁的背后一定需要有支撑。拿病历模版来说，这里涉及到至少三个主体对象。一个是开发团队，二个是模版使用者，三是模版创建者。为什么开发团队要拿出来？因为在不了解整个产品的设计逻辑的情况下，开发团队就会低估整件事情的难度。
设计者一开始低估了设计逻辑的复杂度，并没有做激励体系的整体考虑。创建者的权限比较好确定，增、删、改、查，当然还有共享，而恰恰就是这个共享，让事情的复杂度升高了一个维度。对于使用者来说，如果收藏了共享的模版，那还能不能编辑？编辑了之后创建者的名字改为谁的？还能继续共享么？这些规则定下来了。但是开发团队对于“收藏”这个名字的理解是只能保存为自己的，如果说可以改的话，就应该是“复制”。发生很大的分歧，开发团队第一次的意见是定为收藏，创建者如果编辑共享的模版也发生变化。这件事明显不尊重使用者，因此开发团队第二次的意见是增加一个提醒给创建者，让创建者决定是否让共享的模版也随之发生变化。最终，开发团队的第三次意见是将“收藏”改为“复制”，这样创建者更新就不会打扰到使用者。
回顾整件事情，开发团队有自己固定的思维，但是最大的问题还是在设计者，没有一个明确的方案。同时在讨论时偏离了方向，由于不认同“收藏”，进而变了激励体系，再进而变了规则，最终还是维持了原来的规则。
当然，要让一个产品成功面世，赢得开发工程师的理解是第一步，而这一步要求逻辑严谨。没有形式上的简单，前提是设计者的思维已经能够驾驭这份简单。与其说简单，不如说清晰。
