ui|产品设计中的几大纠结点，看看你是如何解决的？( 三 )

开发：”没问题，那就按你说的办。“

「可配置」听起来很简单也很方便，颇受大家的欢迎。但是从我过往实际的项目经验来看，「可配置」埋下的坑也挺多的，并不是一把梭，拿来即用就万事大吉。
「可配置」会引发几个问题：

谁来配置；
怎么确定配置成功了；
这么多配置，怎么知道什么配置会起什么作用。

随着业务的越来越复杂，可配置的内容也会越来越多，上面提到的3个问题就很容易引发一些BUG，因为人总是会出错的，尤其是复杂度逐渐变高的情况下。
所以未来当开发问你是「写死」还是「可配置」的时候，应该要留个心眼揣摩一下，有些东西到底会不会很容易变，如果不容易变，是否可以写死；如果容易变，是否一定需要配置化……
五、是展示名称还是编码近期比较纠结的一个问题就是：到底是展示名称还是编码，还是两者都展示。
对于供应链系统而言，很常见的对象有：
一般来说有货主就会有货主代码，有仓库也会有仓库代码，有物流也会有物流代码……
名称具有语义性，可识别性；而代码具有唯一性和准确性，也有保护性。
如果是对于SaaS系统来说，不同的用户有不同的用户习惯，我们很难确保用户填写的数据是符合我们理想的数据格式的。所以我们往往会让用户自定义填写「名称」然后系统自动生成「代码」，或者是让用户自定义输入「名称」和「代码」，但是只校验代码是否重复，而不校验名称是否重复……
于是乎，纠结的问题就出现了，在系统的各处界面中，到底要展示用户填写的名称还是编码，亦或是都展示？

文章插图
截图来源：有赞
有赞对仓库名称做了重复性校验，所以没有展示编码，只展示的仓库名称。这种方案也很常见，不过弊端也是有的，例如当需要批量导入数据的时候，在Excel中，仓库这一栏就需要填写中文名称，然后进行模糊匹配，很容易就会导入错误。当然前提是两个仓库的名字取的很接近，否则也不会很容易出错。

文章插图
以仓库为例
在实际的项目中，我没有采取有赞的这种方案，因为跨境电商海外仓的业务场景有点特殊。需要用到「仓库」这个字段的人不仅仅有国内的人，也有海外的工作人员。
如果只展示名称，而名称又是可以很容易就修改的，一方面会造成大家对这个仓库的理解有偏差；另外一方面海外工作人员不认识汉字，并不能区分「888仓」和「888 仓」的区别，深圳可能「深圳仓」和「香港仓」在他们看来，都是方块字，也不知道到底哪个是深圳，哪个是香港……
所以我们采用了名称+代码的方式来展示，可能初次看有点冗余，但是实际用起来应该是会比只展示名称要好一些的。
六、总结本文是关于「产品设计中的纠结点」的下篇，至此为止一些比较关键的、印象深刻的纠结点我都写完了。其中的一些纠结点我想了很久，纠结了很久，甚至在不同的公司中，在不同的业务系统中，都尝试并思考总结过，所以一边写，脑海中一边浮现之前那种抓耳挠腮的痛苦状……
产品设计有点类似于戴着镣铐跳舞，但凡设计决策必然就会有纠结。我认为纠结不是一件坏事，恰恰相反，纠结过程其实就是思考和沉淀的过程，这也契合了「看山还是山」的道理。
当你在产品设计过程中不再纠结或者少有纠结的时候，可能是你已经到了「看山还是山」的阶段，也有可能你从未思考过这些细节，所以还在「看山是山」的阶段。