当我们聊设计的时候，我们在聊些什么？
原创
背景
在业务系统中，设置查询条件是一个非常常见的场景，设置查询条件，根据查询条件生成sql，对数据进行过滤。
我们从这个简单的场景出发，当我们设计这个场景的时候，会发生什么事情。
简单实现
这是一个最简单的实现，符合我们直观的认识。过滤项和它可输入的参数都已经规定。
不足
1.查询条件以and连接，不支持查询出符合条件A或者条件B的过滤方式。
2.每个条件的过滤方式已经固定，不能在查询时修改。
3.所有查询条件都平铺在界面上，即使我们不需要他也会占用一大部分空间。
可选条件的实现
在简单实现的基础上，我们可以进行一些优化。查询条件和过滤方式均可以选择，只添加要过滤的条件。
同时加入了条件组的概念，组间用or连接，组内用and连接。
这样我们就解决了简单实现的三个不足。
不足
这个实现已经可以满足所有复杂条件的生成。但是并不直观。
考虑我们需要一个
conditionA and ( conditionB or conditionC) 的条件。
这时候我们需要把它转换成
(conditionA and conditionB) or (conditionA and conditionC)
然后才能用上面的界面选出来。
如果我们需要的条件是
conditionA and ( conditionB or (conditionC or (conditionD and conditionE)))
那么我们这个实现就显的不那么友好了(⊙o⊙)？
带分组的实现
带嵌套分组的实现我在常用的ui组件库中没有找到，所以自己简单实现了一个。
支持自定义字段及字段类型。组内的条件优先运算，与括号等效。
现在我们再来选出conditionA and ( conditionB or (conditionC or (conditionD and conditionE))) 这个条件，就显得方便多了。
选出一个更加复杂的条件。幸好准备了SQL生成的功能，从SQL上面看更清爽一些。
github地址：https://github.com/4cos90/condition/tree/master
我们在聊什么
当我写到这里的时候，一切似乎都已经搞定了，有了可选的条件，可以自由的设定条件的关联关系，可以支持嵌套，可以支持和sql相互转换。我们有了一个功能完备的组件。
但是我们日常使用中，还是第一种最简单的最常见。第二种在一些复杂的场景下偶尔会见到。
第三种看起来功能最全，什么情况都考虑到了，但是我没有见到有使用这种设计的。
我们自然会得到一个问题。我们需要这样完备的功能吗？
随着功能的增加，学习成本也会随之增加。使用起来也不再直观，不再好用。
做出选择
设计是做减法。
在完备的功能中，选出我们会使用到的一部分，是整个设计过程中始终要考虑的问题。
选择的依据无外乎两点。我们的用户是谁，我们在什么场景下使用。由此向下推理，用户在这个场景下的行为，用户想要达成的目的。而我们真正选取出来实现的部分，只需要刚好满足让用户达成目的即可。而超出目的本身的其他部分，只是徒增了使用时的学习成本和交互操作时的复杂性。
less is more
我们从最简单的场景出发，逐渐加入新功能弥补不足。加了几回似乎还是最开始最简单的实现更普适。仿佛出发转了一圈又回到了原点。
但我们和出发时已大不相同。
我们最普遍看到的场景往往也是简单的场景，面对的用户也往往是非专业的用户。他们的目标往往是短暂的在页面中停留，快速的得到结果。业务逻辑不复杂，边界也小。我们在这个小边界里固定条件，减少用户的选择范围，是好事。
在逐步考虑复杂场景时，简单设计的不足才会被暴露。这时候我们再谨慎的添加新的功能，满足更复杂的需求。
用户体验
我们坐在这里空想，就已经实现了一个用户并不真正需要的组件。更何况在面对真正的用户提出各自需求时？
唯有时刻记住用户才是实际使用产品的人，不要用自己的视角先入为主地替用户创造需求。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。