使用代码逻辑的思维代替日常性口语进行设计

经常调用的功能可以做成模块化，方便后期进行维护。例如订单中填写信息一步，如果不同类型的订单都单独做填写信息功能，一个是会导致研发非常低效，重复性的体力劳动。另一个是后期如果填写信息中的某项要进行调整，而这项又是出现在很多类型订单中，那么首先要找全这些订单类型，然后一个个的调整过去，也是非常低效。

而做成模块化，订单对模块进行调用，那么只需要对模块进行修改，所有相关的订单都会同步修改。不需要再进行重复性的体力劳动。

3.2 代码语言思维

在设计产品原型时，使用代码逻辑的思维代替日常性口语进行设计。这样研发理解起来会非常轻松，也不容易走偏方向。同时，也可以使自己的逻辑性更加有条理。

例如：下单时需要进行库存判定，对比下单数和库存数，库存不足需要提醒商家。

设计原型时如果写库存不足，需要向商家发送库存增补提醒。默契不足的研发容易误解，库存不足指代库存=0，其实还有一种情况是，下单商品数量＞库存数。

而正确的思维逻辑：判定若下单数≤库存数，则走正常订单流程。若下单数＞库存，则向商家发送库存增补提醒。就不容易误解出错。

四、开关与测试

4.1 做好开关留条退路

如果是已有功能的重构或改版，要视重要程度做好开关，好汉也要给自己留条退路。有问题随时切换回去，以免影响业务运转。

也可以划定小部分群体/商品分类进行试点，成熟后全面覆盖推广。例如只上线上海区域或只上线食品这一分类的商品。

当然无论是做开关还是试点都需要提前和研发讨论敲定。等研发一半了再提出，怕是要被打成小猪佩奇。